Streaming server

cpghost cpghost at
Tue May 26 08:20:06 UTC 2009

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.


Cordula's Web.

More information about the freebsd-questions mailing list