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."

Comments

Muahahaha.. Slashdot? With a sense of humor???

[Bowie J. Poag]

Anyone here find it just a wee bit ironic that a postabout BMG and their so-called "copy protection" (*chuckle*) is followed immediately by a rather technical article on a new, faster, better, low-density P2P client?

Hell, they haven't even managed to shut the _first_ version down!

Cheers,

It Would Be a Real Shame....

[CatWrangler]

if people tested out this network by trading only BMG files at first. Have to beta test and all though I suppose.

The Gnutella innovation I like

[Anonymous Coward]

Is the Gnutella Web Caching System. It allows clients to find other gnutella peers without any sort of central gnutella server.

Kazaa vs. eDonkey

[T-Kir]

Ever since I've been using Broadband (Optimum Online yeah baby!), eDonkey has won me over vs. Kazaa(lite).

Alhough eDonkey needs a little more work than Kazaa to operate, the file hashing/segmented downloads/no leeching is far better than Kazaa, plus the amount of file corruptions I get using Kazaa is way too much (especially with very large files). I've also started trying Overnet, but still have loads of downloads I'm clearing through the Donkey (Yes I have tried using the donkey downloads for Overnet, but only half register in the download tab).

I've tried using Gnutella/Gnucleus on numerous occasions, bit given up due to a lack of being able to do anything with it compared to the other P2P programs... I just hope Gnutella2 will become a viable option for me to use it.

Re:Kazaa vs. eDonkey

[Arker]

If you have a *nix box (even an apple if it's OS X) you can use mldonkey which is a very nice client. You can operate it remotely from another box, it uses both edonkey and overnet protocols simultaneously, it's partially open source (there is a key component kept secret for security reasons, the one flaw in thes protocols is that they require trusted clients unfortunately) and it really gives you the best of edonkey and overnet both, as well as supporting the move to overnet since anything you're downloading from edonkey or sharing out will also be shared to overnet.

Re:Other OS P2P technologies

[iofire]

I'm surprised that no one has mentioned it, but giFT is a very nice open protocal modeled after the fasttrack network. (originally it used the actual fasttrack network, but now they use an open protocol called OpenFT)
Check it out at http://gift.sourceforge.net
The ncurses based frontend giFTcurs is very nice, but there also are graphical and even web-based frontends to it.
I use it under linux and have been very happy with it.

Gnutella2 - The real story!

[smd4985]

I'm a engineer at Lime Wire LLC so I can debunk much of this submission. Shareaza's Gnutella2 isn't so much the second iteration of Gnutella - instead, think of it as a improved Gnutella . In fact, the improvements were actually proposed by Lime Wire LLC (consult the GDF and look for messages about 'GUESS'). The GUESS protocol is a UDP based protocol we developed to allow for Gnutella network crawls/walks. We introduced it for public comment on the GDF *before* releasing it because we understand that Gnutella, as a open protocol, needs support from all Gnutella developers. I'm not sure what exactly Shareaza has implemented (because they HAVE NOT released the specs yet), but it sounds a lot like GUESS.

So this isn't so much Gnutella2 as a improved Gnutella. Perhaps one day it will evolve into Gnutella2 more formally, but at the moment this talk of Gnutella2 is premature.

Re:Gnutella2 - The real story!

[Adam Fisk]

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.

Re:Gnutella2 - The real story!

[Adam Fisk]

On the spyware topic, we originally started bundling software purely out of the need to survive -- we needed to bring in money, or we would have closed down. Since then, we came out with LimeWire Pro and now only bundle TopMoxie with LimeWire, and it's an optional install. TopMoxie really is not spyware in the way people typically use that word. It basically does one thing -- it has affiliate programs with multiple web sites, and when you visit those sites, it pops up a really innocuous window (that times out and disappears) asking you if you would like your purchase to support LimeWire. If you click yes, we get the affiliate revenue. If you ignore it or don't notice it, nothing happens. TopMoxie is primarily used by schools and charities to raise money for them.

So, the short answer is that we would prefer not to bundle anything. As a result, we now only bundle one program that we feel is really innocuous to the user and that they have the option not to install. On all operating systems other than Windows, LimeWire has no bundled software.

Re:It's pretty fast...

[iofire]

Did anyone else notice that on the beta download page (visit the "next version" link at the top of the page) that there is a button to download it via gnutella? It's nice to see someone make use of this as a way to download software.

UDP and firewalls

[elliotj]

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.

Re:UDP and firewalls

[Adam Fisk]

Firewalls block most incoming UDP traffic in the same way that they block incoming TCP traffic -- there's really no difference. Incoming traffic is generally denied except for specific ports.
So, with both UDP and TCP, only outgoing data will not be blocked as a general rule. With TCP, this poses less of a challenge because once you've established a connection, data can be passed both ways. With UDP, you cannot establish a connection in the same way. That said, most firewally will allow incoming UDP from a specific endpoint if you've sent outgoing data to that endpoit "recently." In this way, a quasi-connection can be established.
All that aside, though, the short answer is that non-firewalled hosts, and specifically "Ultrapeers" on Gnutella, act as proxies for firewalled hosts, allowing firewalled hosts to behave on the network almost exactly like hosts without firewalls.

Re:Hopefully downloads are better with G2...

[bpd1069]

I even got my girlfriend, boss, and brother using Bearshare.

You got a girlfriend, boss and Brother from a P2P applications! Wow what search are you using?!

Re:Hopefully downloads are better with G2...

[fault0]

> I even got my girlfriend, boss, and brother using Bearshare.

Congratulations, you made them install quite a bit of spyware too.

I would recommend something like XoloX, which has absolutely no spyware.

The problems with Gnutella 1

[evilviper]

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?

Gnucleus & GnucDNA

[DeadBugs]

Gnucleus has been a solid Gnutella client for me.

They are also working on GnucDNA a component for building your own P2P applications.

Re:Crossing fingers

[0x0d0a]

Yup. Raphael Manfreti (of gtk-gnutella fame) and the Limewire team (also major GDF developers), get no credit, and these "Sharezilla" wankers get a Slashdot link.

Well, *here* is credit where credit's due:

GTK-gnutella

LimeWire

Gnutella started out as an "interesting project". It is now one of the most heavily developed an analyzed projects -- somewhat less centralized than the Freenet project, but far more skill (and variety of clients) on this than, say, FastTrack and the much-lauded Kazaa.

A *real* anti-leech/anti attacker system proposal

[0x0d0a]

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.