From owner-freebsd-questions@FreeBSD.ORG Tue May 26 08:20:05 2009 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A782A1065676 for ; Tue, 26 May 2009 08:20:05 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from fw.farid-hajji.net (fw.farid-hajji.net [213.146.115.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0CC7D8FC1F for ; Tue, 26 May 2009 08:20:04 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from phenom.cordula.ws (phenom [192.168.254.60]) by fw.farid-hajji.net (Postfix) with ESMTP id 04E8934E95; Tue, 26 May 2009 10:20:01 +0200 (CEST) Date: Tue, 26 May 2009 10:20:01 +0200 From: cpghost To: Wojciech Puchar Message-ID: <20090526082001.GA1136@phenom.cordula.ws> References: <4A1A9FF0.40609@webrz.net> <4ad871310905251225y6da0f41bl7718e9a3290dfa19@mail.gmail.com> <20090525210657.GA12424@phenom.cordula.ws> <20090525214621.GB12424@phenom.cordula.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: FreeBSD Questions Subject: Re: Streaming server X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2009 08:20:06 -0000 On Tue, May 26, 2009 at 12:31:54AM +0200, Wojciech Puchar wrote: > > Sorry, mistake: > > s/file streaming/file download/ > > when you play file directly from HTTP/FTP source it's streaming too. > just much more simple, portable, and cachable by squid/other proxies Yes, you're right. For "static" content, buffering a TCP connection is certainly "good enough." But for live streams and video conferencing, buffering adds latency (and the bigger the buffer, the higher the latency). The effect is then similar to what you observe if you talked on a geostationary satellite network, doing multiple uplink-downlink hops (many times 1/3 of a second). That's quite noticeable and pretty annoying. Some people prefer a couple of lost frames to this latency, and that's why protocols like RTP do have their uses (even if we ignored multicasting). And for a real-world example: just look at the way the GSM network deals with lost frames in the traffic channels (TCH) of the Um interface (radio link between BTS and MS): they're not requested again, but simply compensated for with error correction codes, or even dropped. A TCP-like link there would be non-sensical. This may not apply to the control channels, where latency is not so important, as opposed to data integrity, but for the voice traffic itself, it makes perfect sense. Regards, -cpghost. -- Cordula's Web. http://www.cordula.ws/