Hi, David. Thanks for the insightful reply. I agree completely. HAVE messages are significant, but not dominant, and unloading the server is a key design requirement. I've updated my NetFS spec at http://netfs.sf.net. If you've got time to kill, I'd be very interested in your opinion. Given the depth of knowledge shown in your various posts, I don't suspect you have a lot of free time :-)
Bill On Mon, 2007-12-03 at 12:04 -0800, David Barrett wrote: ... > Furthermore, all the strategies you'd use to reduce the pain you feel on the > server would apply equally to reducing pain on the client. > > Thus so far as I can tell, as much a fan I am of centralized designs, > anything that keeps realtime bandwidth off of the server seems like a win, > HAVE vectors included. > > -david > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:p2p-hackers- > > [EMAIL PROTECTED] On Behalf Of Bill Cox > > Sent: Monday, December 03, 2007 6:04 AM > > To: theory and practice of decentralized computer networks > > Subject: Re: [p2p-hackers] DistribuStream > > > > Hi, Tony. > > > > Just read the DistribuStream specification. Very nice, IMO. Some > > specific feedback: > > > > Pros: > > - Very simple - hard to overstate the importance of this > > - Server optimized transfers could enable faster, more reliable > > streaming, and faster downloading in general > > - Peer communication is super-simple: just HTTP GET/PUT requests. > > - No HAVE messages need to be sent to connected peers, dramatically > > reducing peer communication overhead, improving scalability. > > - Peers do not need to compute anything, or remember who has what, > > dramatically reducing peer complexity and run-time overhead. > > - No INFO blob, bencoded dictionaries, or other crud to complicate file > > transfers. > > - Since server directs all transfers, he knows how many downloads there > > are, and who did the downloading. This is very attractive to companies. > > > > Cons: > > - Server communication is heavy - a decent sized swarm could choke a > > server. Scalability is potentially compromised. > > - This protocol suffers from the same upload == download bandwidth > > limitation of BitTorrent, potentially reducing the quality of video that > > could be supported. > > > > I'd much rather implement a client for this protocol than BitTorrent. > > There's no bencoded dictionaries, info blobs, and such, and I wouldn't > > have to reverse-engineer the damned protocol with ethereal. That said, > > the limitations seem severe. My initial version of the NetFS protocol > > looked a lot like this, with a tree of publishers and their mirrors > > providing file transfer smarts. You could similarly get around the > > scaling problem with a way for peers to become mirrors. It works for > > Gnutella (supernodes). > > > > I like how your application streams to stdout, so you can pipe into > > players. I took a different path, integrating a FUSE based virtual file > > system. This lets me open a player and open a file just like I would if > > it were already resident on my machine. The downside with my approach > > is increased complexity and difficulty porting. It also made me want to > > support incremental file system updates, which led to having some > > version control messages in the protocol. > > > > I like how your protocol minimizes HAVE and file bitfield traffic, which > > always bothered me in BitTorrent. I'm thinking of modifying my NetFS > > protocol to make these client/server specific messages, as in your > > protocol, but it will need some work. > > > > Anyway, DistrbuStream looks like fun stuff. > > > > Regards, > > Bill > > > > On Wed, 2007-10-31 at 15:08 -0600, Tony Arcieri wrote: > > > DistribuStream is an open source (GPL) implementation of the Peer > > > Distributed Transfer Protocol, an open peer-to-peer communications > > > protocol which facilitates streaming progressive downloads. You can > > > read about it here: > > > > > > http://distribustream.org/ > > > > > > It was developed as a collaboration between ClickCaster, Inc. and the > > > University of Colorado Computer Science Program. > > > > > > PDTP has been registered with the IANA and received a port assignment > > > of 6086. > > > > > > The protocol philosophically different from other P2P protocols which > > > rely on emergent, swarm-like behavior for traffic scheduling. All > > > client/server and peer-to-peer communications can be modeled as simple > > > state machines. The onus of traffic scheduling is placed entirely on > > > the server. > > > > > > Client/server communication is accomplished with a lightweight JSON > > > asynchronous messaging format (presently running over TCP). > > > Peer-to-peer communication is accomplished with HTTP/1.1. The entire > > > protocol behaves as an ad hoc HTTP caching proxy network. > > > > > > The main feature is its facilitation of progressive streaming > > > downloads, making it comparable to proprietary protocols like Joost. > > > > > > The present implementation is early beta quality, but I'd love to > > > begin getting feedback, particularly on the feasibility of the > > > approach. > > > > > > -- > > > 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 > > _______________________________________________ > 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
