it is an obvious observation that a p2p client relying on a central server for various features is asking for trouble. we know the scalability of bittorrent communities has been crippled in having to rely on apache for key features -- see torrentse.cx (where else could you get 300k/s downloading a file that from a server that takes 45 seconds to generate the index page...)
many bad things have been said about this centralized nature, some that _must_ be fixed in bittorrent (one file one port??), some that just make life easier (really, if you wanted 'search' and better scalability, dump the torrent files on gnutella not apache...) that said, there are some cases where that centralization is necessary... if it weren't for the fact that the torrent files are static, and the fragment download ordering is relatively random, the typical torrent's sustained 100k/s would be more than ideal for streaming video.
given that bittorrent's strength has been shown to be the case where large numbers of users want exactly the same data at the same time, have you ever seriously considered implementing a streaming varient of bittorrent?
are there any quirks inherent in either streaming media formats or the bittorrent protocol that preclude the clients uploading streams to each other to distribute the bandwidth in the fashion we've come to love in our torrents? (aside from needing a _really_ big local buffer, and _no_ lag in the tracker)
Slashdot Mirror
it is an obvious observation that a p2p client relying on a central server for various features is asking for trouble. we know the scalability of bittorrent communities has been crippled in having to rely on apache for key features -- see torrentse.cx (where else could you get 300k/s downloading a file that from a server that takes 45 seconds to generate the index page...)
many bad things have been said about this centralized nature, some that _must_ be fixed in bittorrent (one file one port??), some that just make life easier (really, if you wanted 'search' and better scalability, dump the torrent files on gnutella not apache...) that said, there are some cases where that centralization is necessary... if it weren't for the fact that the torrent files are static, and the fragment download ordering is relatively random, the typical torrent's sustained 100k/s would be more than ideal for streaming video.
given that bittorrent's strength has been shown to be the case where large numbers of users want exactly the same data at the same time, have you ever seriously considered implementing a streaming varient of bittorrent?
are there any quirks inherent in either streaming media formats or the bittorrent protocol that preclude the clients uploading streams to each other to distribute the bandwidth in the fashion we've come to love in our torrents? (aside from needing a _really_ big local buffer, and _no_ lag in the tracker)