[SGVLUG] Anyone want to embrace and extend AOL?

[Mike Fedyk]

Emerson, Tom wrote:
>> -----Original Message-----
>> Behalf Of Mike Fedyk
>>
>> Emerson, Tom wrote:
>>     
>>> Some key concepts I noted as I skimmed the first one
>>>
>>>    -- uses a peer-to-peer model [to "stream" video]
>>>       
>
>   
>> I went to an interview at a content streaming hosting 
>> company, and after 
>> walking out I couldn't help thinking that bittorrent should 
>> be combined with streaming.
>>     
>
> Unfortunately, as I understand how Bittorrent actually works, this wouldn't work.  the [seed] server and client(s) work together to push out the "most rare chunk", so if say 3 people tried to get the file at the same time, the first client would get chunk #1, the second #2, and the third #3; client 1 would be "directed" to seedlet's 2 & 3 for those respective "chunks", and would (very likely) pull chunk #4 from the originating seed server.  Meanwhile #2 (perhaps on a slower DSL) would be directed to the other two servers for chunks 1 & 3, but by the time it gets around to a "totally new chunk", server 3 might have pulled chunk 5 from the primary seed, so it would pull chunk 6 instead.
>
> 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...
>
> There is also no guarantee of the "QOS" of the upstream channel from the "peers" [hint: how to screw with them: put a packet filter on your firewall that severely restricts the outbound packet rate for this "service"]
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.

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.