Slashdot Mirror
Peer-to-Peer Overview
An anonymous submitter sent in: "New Scientist has an interesting feature on peer to peer systems, taking a less copyright orientated approach, and going into some technical detail about how the various P2P systems work and compare to each other."
The claim that P2P would be great if only the systems would interoperate really doesn't bear much scrutiny, TCP/IP is often the full extent of what these systems have in common. This isn't a flaw, it is a simple fact.
--
It starts with a breirf history of P2P systems (focusing on the modern music sharing ones).
It then goes on to talk about Gnutellas technological downfalls. The main part of the artical is taken up with the method that by which freenet works
Its a good articale that talks quite a bit about the technologys and only breifly touches on copyright issues.
callum
How to make the successor to Napster
Most people don't realize that what made Napster successful was not its network protocol or its technical sophistication. Ease of use made Napster, and ease of use will make or break every P2P system. For a P2P system to work and be useful, it has to be simple, easy to find, easy to install, easy to use, and easy to upgrade. Why upgrade? Because upgrades will be necessary to combat "blocking" technologies instituted by ISPs.
The way to accomplish this is not to write yet another Gnutella or OpenNap or Freenet or Blocks client. There are enough of these today. The solution is not necessarily to create new protocols--too many protocols, and your average Joe won't know what to use or why. Furthermore, you open yourself to liability if you do so, as described in this excellent white paper from the EFF.
The solution is to write a generic P2P interface. Make it extensible via protocol plugins. Users should be able to type in one search query, and have it search OpenNap, Gnutella, and Freenet simultaneously, and display all the results in one window. Plugins should concern themselves only with the P2P protocol, and with comforming to some standard interface.
Do not write both the plugins and the interface yourself. Obviously, a GUI that does nothing by itself is not an infringing device. Better to compartmentalize things and make it harder for people to be hit with absurd lawsuits. Furthermore, the programmers who tend to be good at network protocols are generally not so hot at GUI design, and vice versa.
Try to keep the plugin architecture very cross-platform. Ideally, plugins would be totally portable code requiring only a recompile (even when going from Windows to MacOS, for instance), or--better yet--would just be a bunch of specs in XML format.
Set up a mechanism that allows updates to be distributed via the P2P network. Obviously, some sort of signing/verification will be required to reduce the risk of trojans. Still, the goal should be to make it almost transparent for novice users to add support for new protocols. If it becomes easy to implement, distribute, and adopt a new protocol every month, it will be impossible to stop P2P. Updating the GUI is less important--it's the protocols that have to change.
Conclusion: What this will do is create a highly adaptable, fault-tolerant, lawsuit-resistant network that is easy to use. Why have I placed so much emphasis on ease of use? Without a large userbase, you're nothing. A P2P network is only as good as the libraries of its users. Why is this network so adaptable? Suppose one or two protocols get shut down or blocked or whatever. Someone creates a new protocol, writes a plugin, distributes it by one of the remaining channels, and we're back in business. Finally, the system also encourages modularity and code reuse, which is A Good Thing.
By the way, if you can't figure out why I'm anonymous, you haven't been paying attention.
19021312
None of them are as fast, easy to use, or reach 1/10th the number of people that napster does. I believe the solution, at least for the short term is not to create new protocols from scatch, but rather to make the napster protocol itself more distributed.
Rather than having centralized napster servers which can easily be shut down, it would be ideal to have linked servers that not only can share the load, but will propogate the index of the other servers. Then we need some way to make the napster client aware of the servers and find one at random, possibly through a webpage with an index of registered servers, or by contacting other clients on the network similar to gnutellas node catcher.
The client would also need to automatically jump from one server to another if the server goes down because of connectivity or tragic law suits.
The server could even be built into the client so that you can check a box and start operating as a server which would publish your ip to others on the network. Once there are suffcient numbers of napster client/servers out there and changing every hour it will be very very difficult to shut down, and for the average user, they can just download the new client and it will work as it always did.
Napster should abandon their filtering direction and release this type of distributed, fail-over, server as open source along with the matching client. Once its in the wild they can shut down their own servers and just host the napster webpage. They can still enjoy millions of hits to their site, with no libability of running the napster servers.
I suspect even the RIAA won't be able to get a restraining order against a software company to make them stop creating software. Other wise netscape/ms/apache and any other software that allows computers to communicate is next.
So please, before we abandon the well known napster protocol, let's slightly change it to be more resistive to attack. Opennap may be headed in this direction but until i can visit their page and see 10,000 opennap servers all listed and linked together, they're just inviting themselves to another lawsuit.
And if you are looking for a good p2p don't forget to check the resources page. Thankyou.