[ponker]

Huh, thanks, I think I’m starting to get it. Is it that the connection-based model needs the data “copied” into each user’s stream on the server-side while the “stash the files in a bin” stateless model allows the networking hardware to cache this data somewhere in memory and just copy it on the fly onto different network links?

[sudhirj]

Stashing files–let's say that each file is one second long and is just numbered with the unix timestamp – makes things cost effective because now the server is just dropping files no 1,2,3,4... into a directory, and everyone is pulling them out in sequence the way an other file would be downloaded. This also allows exploiting the HTTP architecture – if you set the Cache-Control: public headers on the files (which you can do happily because they'll never change) they'll be cached at lots of places along the way, like CDNs, the local ISP, the office network, etc. HTTPS blew out most of these caching benefits, but at least the CDNs can cache the files at edges all over the world.

[donavanm]

Its not just that it can be cached, but that it can use very standard existing infrastructure like HTTP CDNs, mobile browsers, etc. The limitation is that the audio/video is encoded as segments, each a few seconds long. Because of this it looks kind of like serial batch processing with latency constraints based on the batch size (segment duration). This is in contrast to say webrtc or rtmp thats a lot closer to a multiplexed stream of data.