On Monday, September 3, 2001, at 12:21 PM, Graham Leggett wrote:
Chuck Murcko wrote:
Right, but consider delivering streaming content through a proxy, as opposed to just being an HTTP-cpmpliant proxy. That expands the problem and the solution a bit.
What is the difference between a "proxy" and an "HTTP compliant proxy"? I only know about HTTP compliant proxies.
I think that caching streaming content is outside the realm of the HTTP spec.
One of the ways is to buffer some determinate (configurable) amount of the stream, as long as at least one client is accessing it. This solves the general case of what I think the original question was about, the scaling problem.
A stream by it's nature is exactly that - a stream. It cannot be cached because different requests for the same stream will result in different content each time.
Consider a caching proxy designed to handle streaming media (it need only know that streaming data differs from other data). Let's say we can also specify a maximum size (to circular buffer) of this streaming data, and that we can refer to a connection pool to know we're already connected to the origin server for it, if that's the case.
First client connects through the proxy to the streaming server. The circular buffer is created and starts filling, and the client gets fed immediately starting from first data in the cache (the circular buffer, in effect). If he's got a fast enough connection, he keeps up with the cache head. If not, he's getting data from somewhere between the head of the cache and the tail (since it's circular). If he's falling behind continuously, his connection won't support the streaming media itself, and he'll see lots of problems that have nothing to do with the proxy, but which also can't just continue to consume system resources past the cache limit.
Meanwhile, some other client shows up to access the streaming media from the same origin server as the first (while that guy's still connected). We know that, since we're pooling at least these these types of origin server connections. His connection gets attached to the tail of our circular cache entry, so our already buffered bit of the stream is in front of his client buffer. He starts getting the stream on a time delay based on our buffer length. His connection load is attached to the proxy, not the origin server.
Additional proxy clients behave the same way as the second. If all client connections go away, the cache entry and the connection pool entry go away too (reference counts). It's all temporary, unlike regular cached HTTP data.
You don't *need* a real cache to do this, but you do need something like connection pooling. The cache just helps integrate out network glitches (at the expense of adding delay to the stream gotten by the client). Either way you offload the origin server by using the proxy as a connection expander.
Regards, Chuck
Chuck Murcko Topsail Group http://www.topsail.org/
