Slashdot Mirror
P2P in 2001
nihilist_1137 writes: "Zdnet is reporting that P2P is becoming more used in business. "It's now over two years since a few underground song-swapping services put peer-to-peer technology firmly at the forefront of the IT agenda... A look back at some of the more significant P2P stories of 2001 shows that -- although not a new concept -- P2P is starting to assume a very important role in the corporate space, as tech giants scramble to succeed in this new market."" Hard to believe that the Napster battles have been going on for two years now.
So now distributed computing has this neat new "p2p" hax0r acronym, and the fact that you can write distributed applications if you've got networked computers is news.
Well said!
Watch now as the corporate giants wake up and start to co-opt the methodology and recast it as their innovation and file patent suits against any and all they perceive as transgressing their IP.
Watch the partnerships a la Groove Networks foment:0 1/10-10GroovePR.asp
http://www.microsoft.com/presspass/press/2001/oct
and then watch as any work-alike initiatives are crushed in the courtrooms of America.
If you define P2P to include distributed computing, where a central server tells a bunch of nodes what to do (which seems outside of the scope of P2P to me), then wow, P2P has really taken off. Heck, with that definition, Pixar uses P2P render farms for their movies.
On the other hand, if you define peer-to-peer in a more pure sense, where each node is a peer, doing its own thing and maybe using one or more directory servers or repeaters to find others, then Napster looks like the only winner I can think of, and it's clearly dead now that it's gone legit. Most IM apps look like client-server to me, although they have some P2P aspects such as file transfer... they're not any different from IRC + DCC, really.
I interviewed with a couple of local (SF) "P2P" companies (really internet-based distributed computing platform vendors) a year ago, and they were having trouble selling their concept even then. Yes, there are CPU-intensive tasks out there that companies would pay to accomplish, but they tend to operate on a lot of data, and that data tends to be sensitive/confidential. One company was refocusing on internal deployments only - using corporate desktops inside the firewall to run distributed tasks at night. That mostly solves the bandwidth and sensitivity issues, although in a WAN environment you might not be able to use remote LANs if the pipe to the remote LANs are too small for the amount of data being crunched.
It's hard to think of too many true P2P applications. P2P architectures that don't include central directory servers or reflectors tend not to scale - think back to old LAN protocols that didn't scale well a WAN context. It's the same problem but at a higher level. The more scalable protocols use some form of central servers or at least a group of more centralized peers (routers, PDCs, whatever) to find one another. Pure P2P doesn't scale due to network inefficiencies (think Gnutella without repeaters); pure client-server doesn't scale due to node scalability limits. A hybrid such as Napster or the WWW scales very well, though. (The whole web isn't on one big server...)
With appropriate signatures, open-source software distribution might be a good P2P application. Instead of hunting around for a fast mirror, why not grab it from a peer, provided the signature is valid? Only the signature has to come from the main server (or a mirror).
The problem with that is the same as what everybody finds when using Bearshare, Kazaa, etc. - upstream bandwidth from peers is very limited. ADSL, "56K" modems, and cable modems all tend to be asymmetric, limiting a P2P network run over them to the collective upstream bandwidth. Imagine 10 people with DSL, trying to swap 10 files - no matter how you slice it, everybody might as well be downloading from one guy. A P2P file sharing program called eDonkey2000 tried to avoid the single-source problem Napster and Gnutella face by using hashes to request files by hash rather than filename, so multiple peers can send you slices of the file even if the name differs, and even if some of them drop out over time. It's nice for big files because you will eventually get all the parts from somebody, but it's still slow.
I think that perhaps multicasting is the only solution for this. P2P plus multicasting would eliminate the problem of popular servers being swamped by requests.