[SGVLUG] Anyone want to embrace and extend AOL?

[Michael Proctor-Smith]

On 11/21/05, Emerson, Tom <Tom.Emerson at wbconsultant.com> wrote:
> > -----Original Message-----
> > Behalf Of Mike Fedyk
> > Emerson, Tom wrote:
> > >
> [...]
> > > Now, having said that, I suppose if you could /guarantee/
> > that a "client" would receive packets (chunks) within the
> > next "buffer" during the playback time of the first buffer's
> > worth of data, you could get away with this, but it still
> > seems to be a nightmare to implement...
> > >
> > Sure that is with the "most rare" policy in bittorrent.  With torrent
> > streaming (whoo I just coined a new term!) you would have a sliding
> > window of chunks in front of the cursor (your position in the media
> > stream).  This way, you only request the data for X number of seconds
> > before the current location of the cursor.
>
> which is what I thought I just said :) ["...guarantee clients gets packets for the next buffer's worth of playback", in so many words...]
>
> However, I still see a few problems with this (specifically, using Bittorrent or something highly similar)
>
> > This idea assumes a streaming provider with a big pipe with and the
> > streaming torrent to reduce the bill.  Reliably streaming
> > without a big pipe is a secondary consideration.  It is a first step that
> > can improved upon.
>
> BT relies on people who download a file leaving their outbound connection "active" for some period of time [preferrably equivalent to the time it took to download in the first place] so as to provide content to other requestors.  Granted that the AOL plug-in would ensure this to a degree (such as silently NOT unloading when people "quit" the media player), it won't help if the end-user physically powers down their machine.  (or panic seeing the "activity light" flashing on their modem when they *KNOW* they aren't downloading anything and, well, "do something rash..." ;) )
>
> It also won't help if people "jump around" in the file (though that's pretty rare) or if they are the "only recipient" of a given stream (which is far more probable).  It will probably help if several people "start" a stream at relatively the same time (because the server will kick out a "buffer's worth" of data ONCE [or twice] and all the clients will talk back-and-forth for the missing parts) and in theory would help when "stragglers" start up later (because the server "knows" there are several "seedlets" still watching the movie which will ALL have the "first part" of the movie) but when the movie ends (and as I inferred above, everyone "shuts off" their PC that was watching) the server gets a huge hit as now it has to service (many/most/all) the (oldest) stragglers who are more than a "buffer's worth" of data apart in the overall stream [newer stragglers will be serviced by the older stragglers, but eventually that dwindles out too...]
>
> But, of course, I'm *sure* the folks at AOL have already thought out these points [hey, I can't dis them all that much since I effectively work for them now ;) ] so as to how effectively they've addressed these issues simply "remains to be seen" once this goes "live"...

You are missing the point, the media is streaming because you can not
skip around in the stream and must download the entire time you are
watching(and have the whole stream so far available for upload). They
are supporting this service with commercials if you could skip the
commercials they would have not support. Also they may hide the last
show(or parts of it) you watched on your computer, so that even if you
can't upload the show you are currently watching you can upload parts
of other shows you have watched in the past.

By having the central server tell the clients where to find parts and
give out the check sums they protect the clients from corrupted
data(viruses that are a problem with other p2p) but have most of the
bits come from the users.