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
