Gnutella2 Specifications

An anonymous reader writes "After lots of heated debate regarding Gnutella2, (first story and more recent story), the specifications have finally been released. There is a mirror here. Let the debates begin."

Comments

Start of a New Beginning

[Anenga]

This, hopefully, will be the "re-birth" of Gnutella, or at least of a new open free P2P protocol. And the fact that this protocol looks to be, and pretty much is, the most technical, feature rich and advanced protocol currently out is fantastic. I can't wait until someone adds an "Anonymous layer".

No word yet if any of the classic Gnutella clients (such as BearShare, Limewire etc.) will be adopting Gnutella2 at all (although Gnucleus has vowed to in the future). However, there are some that are open source/GPL'd, such as GTK for *NIX, Aquisition for OSX or Limewire in Java.

Incase the specs get /.'d, here is a URI (need Shareaza to download it).

magnet:?xt=urn:bitprint:PMKP57E2TXFI2Z37M3A7CJ2U 3A FICBDU&dn=Gnutella2%20Specs%20Draft.htm

Combine with EMule and Overnet Instead

[Jonah Hex]

While refining the original protocol is all well and good, why not look towards intergration with other open networks now?

I've used em all, as they say, and while no one client is best for all applications I'd say the Emule development is damn close. Since it's Open Source and there are several main "production" versions from different groups plus individual modders putting out even more versions on the cutting edge of development. The best code gets quickly integrated all the way from the edge to the trunk, I've had my eye on their mod forums as well as the latest emule 27a thru 27c releases and things are really moving towards another great milestone release.

With the integration of Overnet support into EMule it now has the best of both worlds, with both public servers and client to client directories. Plus with weblink sites making it easy to find and add known good files to your queue, by batches if needed, it gives the end user the complete experiance of a mature tech.

At least Gnutella is open and may actually end up moving in this direction, I'm disappointed in hearing that the upcomming WinMX will still be closed, both their client and their network really have some good features but in the P2P world closed is death IMHO. As for me, I'll be waiting for the latest 27c EMule as modded by Sivka, my personal favorite at this time.

Jonah Hex

Shareazza/mp concepts

[throwaway18]

1) Shareaza works reasonably well though the lack of a usefull anti leech
mechanism is a drawback. A leaf and hub architecture is a reasonable compromise,
it usually dosn't allow searching of the whole network.
A distributed hash table architecture would allow global search but DHT is
vulnerable to an attacker with modest resources flooding the search space with
junk.

2)I'm interested in the reliable communiaction over UDP part of the protocol.

Two peers, neither of whom accept incoming connections due to connection sharing
or firewalling can't exchange files with any current p2p software.

I'm a bit surprised that no p2p project has tried to do UDP connection splicing
to allow two peers, both behind internet connection sharing (NAT) to talk to
each other. It not be possible but I havn't come across anyone who has tried at all.
It dosn't have to work for everyone to be usfull. Just allowing 10% of
NATed hosts to communicate would be worth the effort.

NAT routers usually allow outgoing UDP connections, normally the remote
machine will be listening on a UDP prt (most common use is port 53 for domain
name lookups. The local computer sends out a packet with a unique local port
number (sequentially or randomly assigned) and a remote port of 53.
When a UDP reply arrives from the internet, it also has a remote port number
of 53 and the chosen local port number. The connection sharing machine
looks at the local port number and compares it to a table of known connections.
If it matches an entry it knows which of the computers behind the NAT
it is intended for and forwards it.

In theory, if two NATed hosts send out UDP packets at the same time, using
the same port numbers the connection will penetrate the NATs. It requires the
help of another machine but in a p2p system you have plenty of machines that
can pass on some small messages.

The only problem I can see is that a NAT may change the local port number.
I hope that cheap cable/dsl routers only change the local port if necessary,
or if they do will use predicatable numbers.

This technique will also be usfull for getting through statefull firewalls.

I need to research this more. Am I missing somthing?
I'm aware that shifting files over UDP requires TCP compatible flow control
so it dosn't hog all the bandwidth.

3)Due to the number of people behind transparent proxys that hijack all outgoing
connections to port 80 and the number of people who set their filesharing
clients to listen on 80, I think is is a pity Mike didn't take the opportunity
to add a faculity to encapsulate traffic with a fake HTTP GET header so it will
go through http-only proxys. Kazaa does somthing like this.