Date: Thu, 15 Jul 2004 19:58:15 -0700 From: Lev Walkin <vlm@netli.com> To: josh <joshua@fuckmicrosoft.com> Cc: freebsd-net@freebsd.org Subject: Re: Large delays (2 minute) with dummynet Message-ID: <40F74447.9080306@netli.com> In-Reply-To: <opsa7ep9sx2tqf3s@mail.internode.on.net> References: <opsa7ep9sx2tqf3s@mail.internode.on.net>
next in thread | previous in thread | raw e-mail | index | archive | help
josh wrote: > I hope this is the right list to post to. > > I'd like to delay a shoutcast stream by around 2 minutes. This > shoutcast server is used to broadcast commentary on live games and > the delay is needed so teams can't gain an advantage by hearing the > commentary to learn where/what the other team is doing. I've > checked the shoutcast forums and it seems there's nothing I can do > to the shoutcast daemon to get this delay. Shoutcast listens on > tcp/8001 for an input stream, and tcp/8000 for listeners to connect > to. > > With 100 streams each using 48kbps, how practical is it to put them > all through a dummynet pipe with a delay of 120000ms? I figure > that'll require 100 * 48 / 8 * 120 / 1024 = 70MB of buffering in > dummynet. That's heaps! Is that possible? Is that using mbufs? > What would have to be tweaked up? > > I guess it'd be better if I could just add the 2mins of delay to > the input stream so the delay buffer is smaller and fixed, but I > don't know how the shoutcast protocol would like that or how the > different TCP implementations would like it. Would ACKs be coming > back to the shoutcaster 2 minutes late? > > Ideally it'd be best to have all this buffering happen intelligently > in userland, but I can't find anything to do that. Am I barking up > the wrong tree by looking at dummynet? Yes, you most certainly are. The problem with TCP is that using the standard window sizes (~32-64k) on the client side and the RTT of two minutes, the transfer speed will naturally be, literally, couple of hundred bytes per second. You'll not be able to squeeze 48kbps into this pipe. Moreover, as the reaction time is slow, there will be various timeout-related glitches, stopping the transfer periodically and restarting it minutes later. The network-related delays can offer you no more than several seconds delay. The best approach is, indeed, a buffering application-level daemon. -- Lev Walkin vlm@netli.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40F74447.9080306>