From owner-freebsd-net@FreeBSD.ORG Fri Jul 16 00:09:34 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDEBC16A4CE for ; Fri, 16 Jul 2004 00:09:34 +0000 (GMT) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by mx1.FreeBSD.org (Postfix) with ESMTP id 374CC43D5D for ; Fri, 16 Jul 2004 00:09:34 +0000 (GMT) (envelope-from joshua@fuckmicrosoft.com) Received: from mail.internode.on.net (ppp235-177.lns1.bne3.internode.on.net [203.122.235.177])i6G09W4Y014224 for ; Fri, 16 Jul 2004 09:39:32 +0930 (CST) Date: Fri, 16 Jul 2004 10:09:35 +1000 To: freebsd-net@freebsd.org From: josh Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: User-Agent: Opera M2/7.50 (Win32, build 3778) Subject: Large delays (2 minute) with dummynet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2004 00:09:34 -0000 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? Cheers, Josh