Developers.GnutellaHandshakeHeaders: Difference between revisions
(Importing page from Tikiwiki) |
m (1 revision) |
Latest revision as of 20:09, 20 June 2009
Handshake Headers
These are the Gnutella handshake headers that Shareaza uses. See the complete list at: [1]
First Line
The computer that makes the connection sends
GNUTELLA CONNECT/0.6
to tell the receiving computer that it wants to communicate with Gnutella. This begins the handshake. The remote computer responds with the line
GNUTELLA/0.6 200 OK
to connect, or
GNUTELLA/0.6 503 Need an Ultrapeer
to say that it can't connect. The only two status codes in use are 200 for OK and 503 for refused. Text after the 503 describes why the remote computer can't connect, and can be anything.
User Agent
User-Agent: Shareaza 2.1.0.97
Each computer tells the other the name and version number of the Gnutella software it is running.
Internet Addresses
Listen-IP: 67.176.34.172:6346 Remote-IP: 81.103.192.245
If we sent these two headers, Listen-IP is our IP address and port number. In place of Listen-IP, some clients use X-My-Address or Node. We have a socket listening for new connections on that port. We tell the remote computer what IP address it seems to have from here with the Remote-IP header.
X-Try-Ultrapeers: 24.98.97.155:6348 2004-12-18T23:47Z,
This header lists IP addresess and port numbers of more computers running Gnutella. Like a Web cache of Gnutella computers, this lets us try more addresses until we find a few that are online. Commas separate each record, and the date and time at the end of each is the last time we connected to that computer.
Compression
All popular Gnutella programs support compression, and Gnutella connections are almost always compressed. To setup compression, the initiating computer says
Accept-Encoding: deflate
to say we can accept compressed data. The receiving computer responds with
Accept-Encoding: deflate Content-Encoding: deflate
which means it also accepts compressed data, and will be sending compressed data right after this handshake is over. The initiating computer confirms compression with
Content-Encoding: deflate
which means it also will be sending compressed data.
Gnutella2 Packets
Setting up Gnutella2 communication in place of regular Gnutella packets is similar to setting up compression. The computer that made the connection says
Accept: application/x-gnutella2
to advertise it accepts Gnutella2 packets. If the contacted computer can speak Gnutella2, it responds with
Accept: application/x-gnutella2 Content-Type: application/x-gnutella2
meaning it can also accept Gnutella2 packets, and will be sending them. The first computer then says
Content-Type: application/x-gnutella2
to annonce it also will be sending Gnutella2 packets. Some clients use x-shareaza in place of x-gnutella2 in these headers, and Shareaza can understand both.
Ultrapeers
In Gnutella and Gnutella2, there are two roles for a computer on the network. Gnutella calls them ultrapeer and leaf, while Gnutella2 calls them hub and leaf. In the handshake, each computer tells the other what role it is currently playing.
X-Ultrapeer: True
or
X-Ultrapeer: False
Computers also express whether they need more ultrapeer or hub connections with the header
X-Ultrapeer-Needed: True
or
X-Ultrapeer-Needed: False
Some clients use Hub in place of Ultrapeer in these headers, and Shareaza can understand both.
Gnutella Features
These headers advertise that the computer that sends them is capable of advanced Gnutella features.
GGEP: 0.5 Pong-Caching: 0.1 Vendor-Message: 0.1 X-Query-Routing: 0.1