On Nov 19, 2007 3:16 PM, Wes Felter <[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? 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. DistribuStream's protocol design has clients check the validity of individual hashes whenever a chunk transfer completes. This allows hashes to be calculated lazily, and also means the resource length can continue to grow even as it's being transferred. This isn't supported by the current implementation, but can be easily added in the future. 2. The PDTP spec is missing the client state machine and server > connection state machine. > Yes, those are noticeable omissions. The state machine diagrams actually aren't available anywhere right now. I'll be sure to get them documented both in the protocol spec and elsewhere on the site soon. > 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 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? > The client / server protocol is rather lightweight (check out a wire dump on slide 11 of this: http://distribustream.org/presentations/distribustream-brg-presentation.pdf) 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. 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. This can be stored persistently by the server as well, much in the same way private BitTorrent trackers do today. However, rather than requiring registration on a web site, this can all be done ad hoc, so long as the client provides the same ID every time it connects to the server. -- Tony Arcieri ClickCaster, Inc. [EMAIL PROTECTED]
_______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
