Tony Arcieri wrote: > On Nov 19, 2007 3:16 PM, Wes Felter <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > 1. You can do progressive downloading with BitTorrent using a > sliding-window rarest-first policy. Thus I'm not convinced that a new > protocol is a good idea. > > Any data as to how well this works in practice?
No; I guess BT implementors are lazy/superstitious. > That said, BitTorrent's metafile dependence precludes any sort of true > streaming video (i.e. live multicast/peercast). The size of the > broadcast and checksums are hardcoded into the metafile, which precludes > the size of the resource changing as data is streamed to the server. 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. > 3a. What is the rationale for the server-oriented PDTP design? > > There's several reasons... it depends what network properties you > consider desirable: > > - QoS via server prediction of network behavior > - Enforced uniformity of client behavior > - Central organization for dealing with nasty issues like cross-AS > traffic routing Are any of these features implemented or documented? > 3b. What is the server bandwidth usage? Intuitively, it will be higher > than other protocols. If so, PDTP must provide some benefit that > compensates -- what is it? > > Each chunk transfer requires only 5 datagrams exchanged between the > peers and the server, the longest of which will top out at around 300 > bytes. 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? > 4. How is upstream bandwidth managed? > > Servers may opt to throttle clients which aren't contributing to the > network by not initiating new chunk transfers unless they maintain a > certain ratio or rate of throughput, if that's what you mean. I'll rephrase the question: How does PDTP saturate upstream links, given that it doesn't know their bandwidth? For example, if peer A has 1Mbps upsteam and peer B has 100Mbps upstream, the server needs to initiate a different number of transfers per second for each peer. Summary: You have a marketing problem; your benefits are undocumented but your flaws are documented. Wes Felter - [EMAIL PROTECTED] _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
