Hi, Tony. I did some experiments with streaming using BitTorrent. I wrote btfs (at http://btslave.sf.net), which lets me mount a torrent as a FUSE file system, and then access only what I need. In short, the results are excellent if there are generous high-bandwidth seeds and few leaches, and sucks if otherwise. I wrote btfs it after wanting only 1 file from a 10 gig torrent. I had to download all 10 gig to access a few KB. I also suffered delays with BT downloading a hot Fedora release. With many downloaders, few seeds, and total upload == total download, BT on DSL can suck big time, and in particular, this issue can kill video streaming performance.
To get around these issues, I added a "friends" protocol to BT (implemented and tested in btslave). It gets around the upload == download problem for hot releases, and should make BT good enough for high-bandwidth streaming of high-demand video in near-real time (up to 5 minute delay). However, it overly complicates BT. I've wanted to write a simpler, new protocol than btslave for a while, but just recently, when BitTorrent went close-sourced, I've felt motivated. I'm probably 2/3rds to an alpha for the NetFS protocol (http://netfs.sourceforge.net). Based on my experience with the btslave "friends" protocol, I'm fairly confident it will provide high bandwidth in crunch situations, and be much better suited to live video streaming than BT. In any case, DistrubuStream looks very cool to me, and I'd be interested in discussions of protocol details. Does this protocol have the same problem as BT where only those interested in the actual content are active in data transfers? In other words, do only peers who actually watch the stream participate, or is there motivation for peers to stay on-line and help others? This is the crux of the "friends" protocol extension. This extension makes it possible to obtain reliable high bandwidth transfers without needing a smart server to compute the most efficient way to do it. Regards, Bill On Mon, 2007-11-19 at 18:51 -0700, Tony Arcieri wrote: > On Nov 19, 2007 6:21 PM, Ivan Krstić > <[EMAIL PROTECTED]> wrote: > That would make a list or explanation of what you're _trying_ > or > hoping to accomplish all the more useful. > > The end goals (above and beyond the existing capability for > progressive segmented download) are: > > - High QoS > - Low latency > - As close to optimal utilization of upstream bandwidth as possible > - Live streaming capability > > -- > Tony Arcieri > ClickCaster, Inc. > [EMAIL PROTECTED] > _______________________________________________ > p2p-hackers mailing list > [email protected] > http://lists.zooko.com/mailman/listinfo/p2p-hackers _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
