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."
← Back to Stories (view on slashdot.org)
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".
/.'d, here is a URI (need Shareaza to download it).
U 3A FICBDU&dn=Gnutella2%20Specs%20Draft.htm
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
magnet:?xt=urn:bitprint:PMKP57E2TXFI2Z37M3A7CJ2
For instance pretend for a second that Linus did not have the copyright for the Linux name and a coder or better yet Michael Robertson registered the domain name Linux3.com and marketed a new kernel as an official version of the Linux kernel by Linus and pushed it as the latest and greatest version of Linux.
GNUTELLA CONNECT/0.6
Listen-IP: 1.2.3.4:6346
Remote-IP: 6.7.8.9
User-Agent: Shareaza 1.8.2.0
Accept: application/x-gnutella2
X-Ultrapeer: False
The Remote-IP header contains the IP address from which the remote host is connecting. This allows a remote host operating through some kind of network address translation system to learn its effective external address.
The Local-IP header contains the IP address and port number that the local host is listening for inbound TCP connections on. It should be listening for UDP datagrams on the same port. The format of this header is "IP:PORT", eg "1.2.3.4:6346".
Can you say DDoS? Would be fun and easy to get an entire network of gnutella clients to respond to one ip.
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
Horror & SciFi Erotic Nudes
Sorry, I'm new to this Gnutella2/Gnutella battle.
If Mike really did use the Gnutella name without permission, why doesn't someone sue him? These "products" are far too similar to be called by such similar names. For example, I'd get my ass sued if I made a new operating system and called it 'Linux2'. Unholster the IANAL's and tell me why. Or even better, get a real lawyer to tell me why.
Otherwise, stop bitching about the fact he's using the name if you aren't going to do anything about it.
----- rL
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.
The people who created Gnutella abandoned the project. No one owns the name, and anyone can call anything 'Gnutella2'.
There can never be a 'legitimate' Gnutella2 because there is no 'legitimizer' to bestow legitimacy upon it.
People should allow their protocols to grow on their own, rather then trying to take advantage of a dead name.
autopr0n is like, down and stuff.