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