On Nov 19, 2007 5:02 PM, Wes Felter <[EMAIL PROTECTED]> wrote: I prefer to treat a live stream as a (RTP-like) sequence of frames with > timestamps rather than a sequence of bytes, so it would need a > significantly different protocol anyway. >
I'll admit I haven't looked at how other peer-to-peer systems are handling live data (e.g. Zattoo, LiveStation) Introduction of a segmented downloading mechanism is quite likely to preclude the use of many RTP features. Users will likely need to select an appropriately encoded stream for their available bandwidth before transferring the file, however mechanisms like Similarity Enhanced Transfer could allow users to share segments with those transferring a video at a different bitrate. Are any of these features implemented or documented? > Nope, the codebase is at a fairly early state implementation wise. Right now the traffic routing is fairly naive. All of these features are potential benefits of a server-oriented design. > But other protocols require zero datagrams. Now I am concerned about > server CPU; a 10Gbps swarm with 1MB chunks will create 6250 > messages/sec. Can Ruby handle that? > Ruby itself is unlikely to be the bottleneck. The Ruby/EventMachine framework handles the underlying IO multiplexing, and supports system calls like epoll which provide excellent scalability across multiple connections. A quick benchmark of the JSON asynchronous messaging implementation in DistribuStream shows ~8400 messages per second on a 2GHz Core 2 Duo system (albeit on localhost, and with a single connection) The real scalability issues I foresee are algorithmic ones in the traffic routing algorithm. This is an area of concern, but these algorithms should be easy to parallelize and distribute among multiple systems. I'll rephrase the question: How does PDTP saturate upstream links, given > that it doesn't know their bandwidth? The server can estimate bandwidth based on transfer history. I'm in the middle of implementing this, but it should be available in trunk soon. The approach is to keep a moving window of the transfer history, and calculate an estimate of a peer's bandwidth at the endpoint of each transfer when all active concurrent transfers at that timestamp are known to be complete. There's several ways to analyze the reliability of this figure statistically, such as examining the number of samples and their standard deviation. The clients will keep two of these estimators, one for their upstream and one for their downstream. > Summary: You have a marketing problem; your benefits are undocumented > but your flaws are documented. > The flaws are numerous, but to be fair the initial public release was about a month ago. Unfortunately most of the benefits are hypothetical at this point, or undergoing implementation. -- Tony Arcieri ClickCaster, Inc. [EMAIL PROTECTED]
_______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
