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

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:The problems with Gnutella 1

[chrohrs]

What may not be clear to many Slashdot readers is that the Gnutella protocol has been steadily improving over the last few months. Let me correct the previous poster on a few points:

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.

Your math is way off here. Try 7 hops with 6 connections, plus an extra factor of 100 or so from ultrapeers. That said, we are always looking for ways to improve searching. Ultrapeers were one step along that path.

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.

Many clients (e.g., LimeWire, BearShare, Shareaza, Gtk-Gnutella) have supported this for some time now. They all interoperate too.

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.

All decent client have features like this. But note that this is an implementation issue, not a protocol issue.

Search by hash

This has been supported for many months, thanks to Gordon Mohr's HUGE proposal.

Metadata

LimeWire has had XML-based metadata for over a year. I believe Shareaza uses the same scheme.

As these examples show, the GDF has been quite successful at driving innovation on the Gnutella network. But caution is sometimes in order; it can be hard to predict the result of thousands of clients running a new protocol. It would be good for Shareaza to submit its new extensions for peer review before rolling out thousands of clients. It is easy to build a client that gets more search results; it is harder to do that without hurting the entire network.

Christopher Rohrs
LimeWire