On Tue, 9 Jul 2002, Stephen Sprunk wrote:
Even worse, multicast is truly only suitable for live applications; on-demand content can't be realistically mcasted, and users will not settle for "the movie starts every 15 minutes" when they've been used to live VOD with unicast. The only saving grace may be things like TiVo, where an intelligent agent slurps up live mcasts in hopes that the user may want to watch it "live" later.
I remember seeing a presentation about 3-4 years ago for techniques for doing on-demand stream sending. They assume multicast, sufficient buffer capacity on clients to hold the entire stream, and that clients have enough bandwidth to recieve, say, 1.2-3.5 streams at once. There are many techniques, but the basic idea is to 'merge' streams together... Say, for example, you have two multicast streams *.1 and *.2 *.1 is free and unused. *.2 is 2 minutes into a movie. A client makes a request at T=0, and subscribes to *.1 and *.2. *.1 sends the first 2 minutes of the movie then closes. The clients buffers *.2 during those 2 minutes to get minutes 2-4 of the movie. The client drops *.1 which is now free. Now, at T=2, the client is listening on *.2 giving it minutes 4-120 of the movie, and minutes 2-4 are buffered on its hard drive. Now, stream *.1 is free, and two clients are on stream *.2. Thats the idea, and it can be scaled up.. I think the presentation I saw claimed that where clients listen to at most 2 streams, and servers send out at most 8 streams, then the delay before starting a 2 hour movie can be <12 seconds, instead of <15 minutes. Some googling finds: http://www.cs.washington.edu/homes/zahorjan/homepage/ Which can be read or mined for references. Scott