Slashdot Mirror

http://www.darkridge.com/~jpr5/src/icopy.pl

Specify a search pattern and it will copy from the iPod to a specified destination any song whose Title, Album, or Artist matches the search string.

--jordan

Hey, everyone knows that Gnutella doesn't scale.

When you say p2p with brains, to me it means somebody has come up with a elegant balance between centralization and search speeds.

Ditto, Holmes. The real question is the scalability issue, and I'm not convinced that the traffic cop features implemented by Gnutella front-ends have really sorted this out.

When that's the case, that will be some p2p with brains. Right now, the networks only seem to be hanging on because the critical mass of crash-inducing traffic hasn't hit the super-peers yet; at least not on the permanent basis.

What would really make my evening interesting is if someone would be kind enough to contradict me.

The article you're probably refering to (posted on /. here) was originally written in Feb 2001. I don't have any exact figures, but I'm quite certain the gnutella network has only grown since then, and it's still going strong. And napster (the p2p network the articles author was involved in creating), well, isn't. I think it's clear which network is stronger, both from a technical viewpoint and a legal one.

In layman's terms. If you are a node in one of his example networks, and you're sitting on a DSL connection, does the available bandwidth you contribute to the net change whether you have 20 outbound TCP connections or 2? No. It is constant. The author incorrectly computes the "bandwidth" of these different network topologies like you are stringing a separate DSL to each person you open a TCP connection to.

Available network bandwidth in a peer network like Gnutella is related only to the physical interconnect of the nodes. (i.e. whether they are on an SBC DSL line or sitting a North American OC-3)

The only useful analysis is that which determines the amount of data-transfer required between each node (and all nodes) for common operations when using different topologies. When performing this study, you are looking for the topology which will transfer the smallest amount of data over the smallest number of nodes when performing searches. For a great analysis, see the Gnutella Performance Paper by Ritter, referenced by the above paper.

Careful analysis will tell you the same thing that common sense does -- that the best architecture involves centralized dedicated servers (supernodes), located on machines with the largest physical bandwidth available. (i.e. eactly what Napster did. )

In order to create an efficient peer network which scales, Gnutella 'merely' needs to 1) order the network by physical topology, 2) identify the nodes with the best combination of physical bandwidth, longevity, and CPU/disk resources, and 3) fully utilize those machines as supernodes.

Good luck. :)

They skipped gnutella because, as far as peer to peer systems go, it sucks. Research papers such as Free Riding on Gnutella and Why Gnutella Can't Scale, No, Really articulate this much better than I can. The success rate of pirating music via Gnutella is much less than those of napster, aimster, and community-based hotline servers.

The RIAA admitted this, if you remember :)

...too many P2P implementors are either ignorant or disdainful of related work...

...there's still way too much fad-following in the P2P community and not enough solid science or engineering.

I have to concur. I know a little about networking, but mostly my experience is in high-performance computing. In parallel programming, avoiding unnecessary communication is a way of life. Once I looked at the P2P query problem, I hit upon an interesting approach to remove the broadcast requirement by using an approximate query routing scheme. This has the potential to fix P2P network scaling problems at a fundamental level. So I wrote up a paper outlining the approach. I politely sent off email to the Clip2, OpenP2P, etc. briefly explaining the idea, directing them to the paper, and asking for comments. I've got nothing. Now, maybe it is not much of an idea. I am an outsider in that community, but I really wonder if anyone bothered to read it.

In particular, everyone seems so focused on the "super-peer" concept with Reflector that they ignore underlying scaling problem that will still be there with super-peers. As a network becomes larger, it will not be able to tolerate broadcast queries...even with super-peers. Here is a nice explanation why.