Slashdot Mirror
Stanford P2P Group Releases Software and Analysis
Bert690 writes "Apropos of yesterday's Slashdot story on BitTorrent: Some folks at Stanford have released a paper on P2P "bucket brigade"-like streaming that contains *an actual analysis* and a downloadable implementation."
Could this be considered actual research on the subject of p2p networks and
scalability?
Read it here
You can get several versions of this from this page, including a pdf version or a plain text version.
The high bandwidth required by live streaming video greatly limits the number of clients that can be served by a source. In this work, we discuss and evaluate an architecture, called SpreadIt, for streaming live media over a network of clients, using the resources of the clients themselves. Using SpreadIt, we can distribute bandwidth requirements over the network. The key challenge is to allow an application level multicast tree to be easily maintained over a network of transient peers, while ensuring that quality of service does not degrade. We propose a basic peering infrastructure layer for streaming applications, which uses a redirect primitive to meet the challenge successfully. Through empirical and simulation studies, we show that SpreadIt provides a good quality of service, which degrades gracefully with increasing number of clients. Perhaps more significantly, existing applications can be made to work with SpreadIt, without any change to their code base.
P2P research by well known research institutions is far from unheard of. MIT has Chord which is a project to produce robust scalable distributed systems using peer to peer ideas. They have an efficient hash lookup algorithm that could form the basis of many p2p systems and they have code available for download.
ProDOS is still alive and kicking. Time to dust off the old Apple IIe...
There is lots of P2P Research going on.
Check this out:
http://www.cs.rice.edu/Conferences/IPTPS02/
This happened this month at MIT.
I bet the only reason they did this research is they didn't have enough time between sutdying and partying to mess around with multiple p2p progs. They gotta get their fill of divx movies somehow!
Abstract
The high bandwidth required by live streaming video greatly limits the number of clients that can be served by a source. In this work, we discuss and evaluate an architecture, called SpreadIt, for streaming live media over a network of clients, using the resources of the clients themselves. Using SpreadIt, we can distribute bandwidth requirements over the network. The key challenge is to allow an application level multicast tree to be easily maintained over a network of transient peers, while ensuring that quality of service does not degrade. We propose a basic peering infrastructure layer for streaming applications, which uses a redirect primitive to meet the challenge successfully. Through empirical and simulation studies, we show that SpreadIt provides a good quality of service, which degrades gracefully with increasing number of clients. Perhaps more significantly, existing applications can be made to work with SpreadIt, without any change to their code base. The paper is more about solving the problems with streaming multicasts. That is, it is prohibitively expensive for small time providers to stream to more than a few users.
I work for an unlicensed college radio station, and since our broadcast radius is so small, we stream everything with RealAudio (not my choice) once we hit about 20 online listeners or so, things start crapping out.
We're upgrading our server, but that won't change things dramatically. This paper suggests a way that high bandwidth listeners could relay the stream and reduce the server's load. It uses P2P software, but the focus is streaming.
In Capitalist America, bank robs you!
PPP
that could hurt Dell's public image.
After reading the paper I have a few questions. (Yeah, I know this is just research).
If this is implemented in the real world, are each user supposed to use his/her outgoing bandwidth for this? What about people unfortunate enough to have a monthly limit?
What if the same connection is used by more than one person/client? With 4 PeerCast nodes, or maybe just 1 PeerCast node on the same connection as a web-server, will PeerCast detect that there suddenly is a lot less bandwith available than just two minutes ago (maybe because of slashdotting :).
I suppose that would depend on your definition of "Actual Research". It sure seems like it to me.
Another p2p project at berkeley: http://www.cs.berkeley.edu/~ravenben/tapestry/
0 01/
I agree with the others that p2p research is nothing new, although it's just starting to get "hot". In fact, there are several conferences devoted to p2p research papers, e.g.:
http://www.ida.liu.se/conferences/p2p/p2p2
actually the full abstract
PDF and ASCII
-Jon
this is my sig.
Academic institutions have done plenty of P2P research. The paper titled Overcast certainly resembles this one, but it's a year old. As mentioned above, Chord was a great paper. Pastry, done in cooperation with Microsoft Research, falls into the same category. Peer to Peer research is highly active at universities; I should know, as I'm doing some myself right now at Duke.
The reason to have a tree structure rather than a mesh structure is, quite simply, that a mesh structure is a lot harder to implement.
BitTorrent, which I'm the author of, does a mesh properly. It also has real-world deployment experience - it held up against slashdotting quite well. Thanks go out to everyone who's downloaded using it.
I'm a bit skeptical of their claims of robustness and QoS. I have real experience with the way real machines behave on the net, and trying to get real-time streaming working before you've even got file transfer going seems like putting the cart way before the horse.
There's also the issue of interrupts when peers higher up in the tree drop out or become slow, and then there's leeching problems...
As for doing simulations, I'd love to have a way of doing simulations which was at all useful, but my experience has been that real-world net churn and congestion behavior is just so funky that back-of-the-envelope calculations are as good as you're gonna get.
I don't like that idea. If your station doesn't have enough bandwidth to serve its listeners, I don't see using my bandwidth to serve some of them as a legitimate solution.
Same goes with the game companies who want to use this method to save bandwidth costs on game demo downloads. I see no reason that they should be able to use my bandwidth to serve their content to other people.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10