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/ _______________________________________________ firstname.lastname@example.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"