Slashdot Mirror
Gnutella2?
Anenga writes "A Windows (and somewhat WINE compatible) Gnutella client, Shareaza, has released a public preview of its next version which includes a re-designed Gnutella protocol they call "Gnutella2".
Gnutella2 (or "G2") dumps the Gnutella broadcast model and uses a new global searching method with UDP connections. It also features compression to limit hub-to-hub (G2 Ultrapeers) bandwidth, Tiger Tree Hashing etc. Shareaza has released a small description of the revised protocol here, but plans to release a full spec to the GDF after the release of v1.7 Final. Gnutella2, which is really a revised Gnutella protocol, will also be free and open for anyone to use in their clients. Shareaza and G2 may give Gnutella - an open and free P2P protocol which has been
struggling to keep up with the times against
Kazaa, eDonkey and other P2P
spin-offs - the stability and power it needs to attract the closed and
commercial FastTrack Network users when or if the network folds."
I've tried the beta release and G2 hubs operate faster than the G1 hubs. I was able to get faster and larger searches. If only the other clients included supportf for G2 in the future. Better not be Coke II!
I've been working with the JXTA project for a bit now, and they seem to be taking a very nice approach to designing a p2p network that is implementation independant (can be implemented on different platforms, devices, etc.). Besides gnutella (and g2), and JXTA, are there other open P2P networks out there? And if there are, what's the best project?
"What we have here, is a failure to communicate." - Cool Hand Luke
Does anyone actually use P2P networks for legal uses?!?!?!?!?!? e.g. not mp3/porn..
If so, can you list what you use it for?
I wonder how this client will perform for people behind firewalls? Many firewalls are setup to deny UDP traffic because most Internet activity is TCP and having UDP open has been unnecessary up to this point.
I wonder if this will halt the spread of Gnutella2? With P2P, it's all about getting as many people online as possible.
is OpenFT from the giFT project.. as people may recall, giFT was originally an open implmentation of parts of the FastTrack protocol, used by Kazaa, et al. This was an year ago, and KaZaA was not at all happy about this, so they updated a few times to break giFT (see KaZaA version 1.33).
So, some of giFT's developers decided to abandon fasttrack, and make their own protocol, OpenFT. giFT went from "giFT is not FastTrack" to "giFT: Internet File Transfer". This protocol, primarily written by jasta of gnapster fame, has been development for the last ~8 months. A publically released version of giFT with OpenFT is not available yet, but right now, the CVS version works quite well.. even in some ways better than FastTrack does.
There are also some great advantages to giFT. First of all, it enforces a seperation between the client and the network code. giFT is a daemon that handles most of the interaction with the outside world. There are also a multitude of giFT frontends, which are very easy to write, as no network code has to be created. giFT is also modular.. you can put in bridges or even full support to other protocols and networks.
Seconding Susheel's comments, "Gnutella 2" appears to be primarily a marketting gimmick. Gnutella 2 is really just a collection of protocols, most of which have been in use on Gnutella for some time. The one apparently new protocol is a version of the Gnutella UDP Extension for Scalable Searches (GUESS) open standard, that was proposed by LimeWire some time ago, as Susheel mentioned, and that is in experimental stages. That said, perhaps "Gnutella 2" makes some sense as a name, as the computing community seems to be out of touch with how rapidly developments are happening on Gnutella. The collection of protocols used on Gnutella today make it a vastly different network than what people typically think of as Gnutella. If Gnutella 2 changes that perception, then it's great. Just keep in mind that "Gnutella 2" has little to nothing to do with Shareaza -- they primarily contributed the name. The new protocols in use on Gnutella are the result of countless hours of work from many Gnutella developers around the world.
Adam Fisk
The (solvable) problems with Gnutella:
Bandwidth Usage (for searches)
Search results. You only get about 4-7 hops. Assuming 4 hops & 4 non-redundant connections per node, that means you are only searching about 256 nodes. Being able to search everyone would make Gnutella for more useful for less-common files.
Fifo queuing. You may have been requesting a file for the past 24 hours, but someone that just requested a file may get lucky, and take what should have been your spot.
Messages. We need messages to tell people that slow nodes downloading from our node gets disconnected, that you are 2nd in the queue, etc.
Upload settings. Each node should be disconnected after a set period of time to prevent slow nodes from causing bottlenecks, or RIAA employees from abusing the limited open slots.
Bandwith Min/Max for Uploads/Downloads. A limit on the min/max speed for each file download/uploaded, and a min/max for the TOTAL of all downloads/uploads.
Dynamic determination of REAL IP (if behind NAT with dynamic globally valid IP).
Solution to the 'PUSH' fiasco. Is there a way that 2 firewalled nodes can connect to a third (non-firewalled) party to open the connection, then tranfer data directly? I don't think so, but worth including here.
Any more?
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
I think you're right -- our toes were stepped on a little =) -- ours and everyone else's in the Gnutella world who put in most of the work to come up with "Gnutella 2," many of them open source programmers who donated their time to the effort.
Mike has done a hell of a job on his client and is a very nice guy, but he simply is not the originator of the vast majority of the standards being branded as "Gnutella 2."
The key word in your last paragraph is "unfortunately." Yes, it was unfortunate that IE created it's own standards and bypassed the w3c. Are you truly advocating proprietary standards over open standards? Am I misinterpretting you?
Adam Fisk
The whole point of a p2p network is not to share files but to not get caught sharing files.
Last February I got a bigfoot letter from my ISP, Rogers, who had been contacted by the Canadian equivalent to the MIAA, whatever it's called.
I was sharing tons of stuff, 8,000 mp3s, on DalNet and they wanted me to stop. What bothers me is they never contacted ME, they went straight to my ISP and tried to get me kicked off the Internet.
The letter from Rogers said you're in violation etc, stop now etc, or else etc.
So, I stopped.
This close call ruined my career on Dalnet where I had built quite a rep, and trashed my source of free music.
And not popular music either - ancient stuff you cant get anymore, like Robert Crumb and his Cheap Suit Serenaders. Buy THAT at your local CD shop...
Since then the point has been made moot by the fact that my cable modem has been capped at about a FIFTH of it's previous speed. (I am investigating DSL)
However - the crux of the whole matter is this - the record companies hired people to go on the internet and score music for them. Then these people, who, and this is crucial, have the IP of the music source, use that IP to run down the source down and then use legal means to try and get that person kicked off the internet.
IT DOESN'T MATTER HOW FANCY YOUR PROTOCOL IS OR HOW GOOD YOUR CRYPTOGRAPHY IS, IF THEY CAN GET YOUR IP YOUR SCREWED.
I have NEVER seen a p2p system address this issue.
It's Christmas everyday with BitTorrent.
no leeching is far better than Kazaa
I seriously doubt that. Any current "no leeching" mechanisms I've seen are severely flawed and rely on trusted remote code.
People who whine and bitch that people are bypassing them are ignoring the fact that the design is fundamentally wrong. You cannot trust code on another computer. Period. It *will* be broken.
It is possible to build a trust web (where you have metered trust, instead of just a binary "trusted" or "not trusted" a la PGP). Have each user generate a public/private key pair. Have each person maintain a list of trusted users. These users are identified by their public keys. "Trust values" are assigned to each user in the list-holding user's trust list. The scale is arbitrary -- maybe "100" means trust a lot and "1" means trust a little, and "0" means no trust. Trust is generally positive (more on that later).
When you want to determine "absolute trust" of a user, you run out and download the trust lists of all the users from them in your trust list (this spans only two hops out on the web of trust...you could go further, though I think this is sufficient). Person can grant absolute trust to person B as following: (points of trust A gives B in A's local trust list)/(total points of trust A gives A's local trust list)* (points of trust A has in our local trust list).
Then, attackers like the RIAA will be excluded from the network of trust, having low or no trust values, as they hand out corrupted files.
Trust lists can be redownloaded whenever. Cache 'em for weeks if you want.
Clients could automatically add a point of trust per data unit downloaded succesfully from a remote client...then, if it's a bad download, the local user could strip all trust away.
Trust could be used for ranking priorities to let people download from you, determining which copy of a file is "authentic" and which is bogus, etc.
Other possibilities: the reason we don't allow negative trust or blacklists -- only whitelists -- is because it's usually fairly easy to regenerate a new IP, and this results in bloating attacks against users maintaing blacklists. If a user can present something that "costs" them something to obtain, like a VeriSign cert or other "expensive" (i.e. can't regenerate on your computer easily) proof of identity (doesn't have to be your RL name -- could be a signed cert endorsing a 'nym from Zero Knowledge), then give them automatically a certain number of points of trust (client configurable). Why? Because it's much less likely that they're running out and buying a new Verisign cert for each attack. They're opening themselves up to blacklisting.
You could purge year-old entries from your local trust list to stay up to date...oh, there's tons of possible tweaks.
The trust network simply sits on top of another P2P network. It does not require that users not download from users with zero trust -- it simply provides some extremely useful information which is essential to implementing strong antileech/anti network attack protections, or what have you. It is also very difficult to attack. PGP is much more vulnerable, since you just need one stupid person in your web of trust to okay someone, their binary trust bit flips to 1, and they're in your web. If you don't trust someone much, and they give someone else a little tiny bit of trust...that person is only very slightly trusted.
Drawbacks:
My analysis of this approach has found only two drawbacks. First, there is some disk and memory overhead to store cached trust information locally. Gnutella clients already store IPs for much of the network, so it shouldn't be prohibitive, though -- we don't have to handle the whole network, just *trusted* users.
The second one is that letting people download your trust list -- crucial to the functioning of the system -- can leak some information. It means that you "trust" some user on the network. If that user provides nothing but, say, child porn, anyone on the trust network has circumstantial evidence that you have downloaded child porn. Of course, you could have granted the person trust for any number of other reasons, but it is a small amount of information leakage, and worth mentioning.
I welcome comments.
May we never see th