GNUTELLA Agreement Chinese Edition
Translator: Liang Hongn CHINAP2P@163.com
GNUTELLA2 is an agreement on the release of the retrieval. Although the Gnutella protocol also supports the traditional client / center server search specification, the GNUTELLA protocol is more important to support point-to-point, no central retrieval. In this model, all clients are also a server, and the same is also vice versa. These so-called GNUTELLA clients perform the tasks of the contact server and the client under normal circumstances. They provide client-side interface enables users to issue query requests and see search results. Colleagues also receive requests from other clients, check the parts that match them their own, return the available results. Because of natural distribution, a network that performs a GNUTELLA protocol is highly fault tolerant, such as a part of the client offline, network service will not be interrupted.
Agreement definition
GNUTELLA protocol defines the way the client communicates over the network. These include some rules that define a description symbol set and internal clients interact with each other through a client data communication. The following is the defined content:
Description definition
instruction
Description
Ping instruction
Used to activate the client on the network. A client receives a Ping descriptor indicates that you want to respond to one or more PONG descriptors.
PONG instruction
Used to respond to ping. Includes an address of the connected Gnutella client and the information he can provide for sharing.
Query instruction
The primary distributed network retrieval mechanism. After a client receives a Query descriptor, if a matching data will respond to a queryhit in its own data set.
QueryHit Directive
Used to respond to Query. This descriptor provides sufficient information to acquire data that matches Query request.
Push instruction
A mechanism for allowing clients in the firewall to provide file-based data files to the network.
A gnutella client is connected to the network by establishing a connection with another client currently in the network. Getting the address of another client is not in the definition of this protocol, which will not be described here (client address buffer saving is the way to automatically get a GNUTELLA client address with a forced manner).
Once the address of another client on the network is acquired, a TCP / IP connection with the client will be created, the following GNUTELLA connection request string (ASCII encoding) will be sent:
Gnutella Connect /
Note:
1. This file represents the standard GNUTELA0.4 protocol of the facts, however, some protocols extends the descriptor of the constituent protocol and add additional rules when transmitting a descriptor on the GNUTELL network. The known protocol extension is listed in the appendix at the end of this document, but may have some variables that appear in practical applications not in the file.
2. GNUTELLA pronunciation is new-tella
One client is willing to accept the connection, you must respond
GNUTELLA OK / N / N
Any other response indicates that the client is not willing to accept the connection. A client refused to connect may have the following reasons - a client's connection buffer pool is full, or he does not support the same version of the protocol to act as a response client. This example is only this.
Once a client is successfully connected to the network, he communicates with other clients by sending and receiving a Gnutella protocol description word. Each descriptor has a description of the following byte structure, as shown below:
Note: 1. All characters in all structures below are later in low, unless otherwise stated.
2. All addresses are IP4 formats
E.g:
The IP address represented is: 208.17.50.4
Descriptor Header
DescriptorID Network Descriptor: 16 bytes of strings uniquely launched a descriptor symbol. PayLoad Descriptor load descriptor: 0x00 = ping0x01 = pong0x40 = push0x80 = query0x81 = queryhitttl Living period: Description Character The number of times forwarded forward in the GNUTELLA network before deleting. Each client will reduce TTL before passing the package forward. When TTL is equal to 0, the descriptor will no longer be passed forward.
The number of HOPS descriptors is transmitted forward: As a descriptor forward, the TTL and HOPS words of the head must meet the following conditions:
TTL (0) = TTL (I) HOPS (i)
PayLoad Length load length: Indicates the length of the descriptor part behind the head. The number of PayLoad Length bytes from the header after the next descriptor is not intervals or reserved in the data stream of Gnutella.
TTL is the only mechanism in the network. The client should carefully check the TTL area of the received descriptor and reduce its value if necessary. Abuse The TTL area will result in unnecessary network obstruction and difference network performance.
The PayLoad Length area is the only reliable way of the client finds the next descriptor in the input stream. The GNUTELLA protocol does not provide a "monitor" string or any other descriptor synchronization. Therefore, the client should strictly ensure the validity of the PayLoad Length region of each received descriptor (at least a descriptor of the fixed length). If a client cannot synchronize with the input stream, it should break away from the sender's client from the sender, whether it is an invalid client that generates this stream or forward this stream. The descriptive head is followed by a descriptor containing one of the following:
Ping (0x00)
The PING descriptor is not related to the relevant payload and data length of 0. A ping simply has a description header expression, its valid loading area is 0x00 and the loading length zone is 0x00000000.
Ping descriptor PONG (0x01) with a client
Port
Port: Agree to the port of the client that responds
IP Address: The address of the response client (this data area is after the high byte)
Number of Files Shared: Number of this machine shared file
Number of kilobytes Shared: All the space size of all the shared files, in K
Query (0x80)
Byte offset 0 1 2 ...
Minimum speed: Minimum response speed, the speed of the response must be above this speed (in k / second)
Search Criteria: Query keywords, a string of zero end. The maximum length of this string is specified by the PayLoad Length load length of the description head.
Queryhit (0x81)
Number of Hits: Number of results in line with search criteria
Port: The port of the client can accept the client
IP Address: Responding to the address of the client (after the high byte of this data area is behind)
Speed: Responding to the connection speed of the client (in k / second)
Result set: Respond to the result set of queries. It contains a part of Number_OF_HITS, each of which contains the following structure.
File Index: A number, specified by the response client, the result of the only indicator response
File size: Size of files with File Index
FILE NAME: The name of the file with the file that is consistent with File Index
The length of the Result set is specified by the PayLoad Length load length of the description head.
SERVENT IDENTIFIER: A 16-bit string is used to uniquely launched a client on the network. Function is used to indicate the network address of the client. Use it on the PUSH instruction. The QueryHit command is only sent after receiving a Query instruction. A client only responds to a Query instruction when it is strictly in line with the Query key.
Push (0x40)
SERVENT IDENTIFIER: A 16-bit string is used to uniquely launched a client on the network, the client requests to download a file with file_index. File INDEX: Download unique identifiers for the file of the target client, the initialized client should set it according to the flags of the file_index returned QueryHit instruction.
IP address: Download the address of the client with file_index file (after the high byte of this data area is behind)
Port: Download ports of clients with file_index
Descriptor routing
The point-to-point nature of the GNUTELL network requires clients to properly routing networks (including queries, query responses, push file requests, etc.). A good client should rout the protocol descriptor according to the following rule:
1. The Pong descriptor should only send the path of the entrant Ping descriptor. This ensures that only the PONG descriptor that only the route Ping descriptor will be returned as a response. If a client receives a PONG descriptor with a descriptor ID = N, but does not see a PING descriptor with a descriptor ID = N, the PONG descriptor should be removed from the network.
2. The queryhit descriptor should only send the path of the entry Query descriptor. This ensures that only the PONG descriptor that the Query descriptor will be returned to the Pong descriptor as a response. If a client receives a queryhit descriptor with a descriptor ID = N, but did not see a Query descriptor with a descriptor ID = N, the PONG descriptor should be removed from the network.
3. The PUSH descriptor should only be sent along the path to the entry Query descriptor. This ensures that only the PONG descriptor that the QueryHit descriptor will be returned as a response. If a client receives a PUSH descriptor with a descriptor ID = N, but does not see a queryhit descriptor with a descriptor ID = N, the PUSH descriptor should be removed from the network. If a client receives a PUSH descriptor with client ID = N, but did not see a QueryHit descriptor with client ID = n, the PUSH descriptor should be removed from the network. The PUSH descriptor is routed through the client ID, not by the descriptor ID.
4. A client will reach all clients directly connected to it through the Ping and Query descriptors, except for those clients that are directly connected to it, except for those clients that are responsible for passing ping and query.
5. A client will reduce the TTL area of a descriptor before it is forwarded to the client that is directly connected to it, and increases the HOPS area. If, after reducing the TTL area of the head, the value in the TTL is equal to 0, and the descriptor will no longer be transferred forward to any connection.
6. A client receives a descriptor with the same valid descriptor and descriptor ID before it has the same valid descriptor ID, and should avoid re-transfer this descriptor to other connections. It has received such a descriptor, and then pass it out and only wasts the bandwidth.
file download
Once a client receives a queryhit descriptor, it will initialize a file that directly downloads the result set of descriptors. The file will not download through the network of GNUTELLA, one source client and target client directly establishes the connection to data transmission. Document data will never be transmitted via the GNUTELLA network.
The file download protocol is an HTTP protocol. Initializing the downloaded client sends a request string to the target client, the format is as follows:
Get / Get /
File Index
2468
FILE SIZE
4356789
FILE NAME
FOOBAR.MP3 / X00 / X00
Then a description request for downloading this file through this entry should be as follows:
Get/2468/foobar.mp3/ http / 1.0 / r / nConnection: Keep-alive / r / nrange: bytes = 0- / r / nuser-agent: GNUTELLA / R / N server receives the download request will respond to HTTP1.0 is compatible with head, for example:
HTTP 200 OK / R / Nserver: GNUTELLA / R / NCONTENT-TYPLICATION / BINARY / R / NCONTENT-LENGTH: 4356789 / R / N / R / N
The file data will then be read, including the number of bytes described in the gontent-length provided in the HTTP response.
The GNUTELLA protocol provides support for parameters in the HTTP specification, so the download of an interrupt can be reinable according to the interrupt position.
Revenue after firewall
Not always after initializing a file download, you can establish a direct connection with the GNUTELLA client. The client may not allow access to its GNUTELL port after the firewall. If a direct connection cannot be established, the client wants to download the file may request a shared file to replace it with the "push" mode. A client can be implemented by sending a PUSH file push request to a client that sends QueryHIT requests. A client as a PUSH request target (marked a PUSH descriptor in the client logo) should receive a PUSH descriptor, attempting to create a new TCP / IP connection to the request client (indicated in the PUSH descriptor with IP address and port). If the direct connection cannot be established, it is possible to initiate a client that Push request is also behind the firewall. This situation, file transmission will not be possible.
If a direct connection can establish a client launched a client from the firewall to a client initiated a PUSH request, the client after the firewall should immediately send the following:
GIV
Here's
Get / Get /
Allowable users - proxy strings are defined by the HTTP standard. Client developers cannot do their own assumptions for values used here. The value "gnutella" is only used to present example.
Appendix 1: GNUTELLA protocol expansion
Extended Query Hit (Description Update 03/15/2001) First use Bearshare V1.3.0 as an example, the extended queryhit descriptor is placed between the original GNUTELLA QueryHit descriptor's servent ID identifier and the file name of the double NULL end Additional data is expanded. An extended queryhit descriptor will have the following structure: queryhit (0x81)
The institutions of the Baarshare's Trailer area are as follows:
Trailer
Vendor Code
Four case sensitive letters represent a supplier code. The code that has been confirmed is as follows:
Open Data Size
Contains length of the Open Data domain (by byte)
Open data
Contains two single-byte markers, with the following data distribution and order
Flags
FlaguploadSpeed = 1 When and only when Flaguploadspeed flags in Flags2 make sense
FlaghaveUploaded = 1 When and only when the FlaghaveUploaded flag in Flags2 is meaningful
Flagbusy = 1 When and only when the Flagbusy flag in Flags2 is meaningful
Flagpush = 1 When and only when the client is in a firewall or does not accept the entry connection
R = reserved word, future use
Flags2
FlaguploadSpeed = 1 When and only when the queryhit descriptor is included in the highest average rate of 10 uploads
FlaghaveUploaded = 1 When and only when the client successfully uploads at least one file
Flagbusy = 1 When and only when the client's upload slot is full
Flagpush = 1 When and only when the Flagpush flag in the Flags is meaningful
R = reserved word, future use
Private Data
The data length of this area can be decided according to the following decisions
Query Hit Descriptor PayLoad Size- (Open Data Size 4 1)
Developers handle extension
(1) aware of the enabled QueryHit may or may not contain additional data, after the result drops, and before the server identifier. No Complete Description Fit is the number of bytes that may be present, or their content.
Using the load length field and calculate bytes, when they are read from this stream to determine whether the byte is present.
(2) If they are, they read data from the input stream that excludes the 16-byte Server identifier.
(3) Treat queryhit like usually
GNotella
The version of the GNotella client software is placed at an extra data at 0.73 (released from July 30, 2000).
The queryhit descriptor. According to GNUTELA 0.4 protocol, each queryhit descriptor
The result set is ended with a double NUL. GNotella can place additional data between two NULs. although
Its precise data format is unknown, but these data represent the bit rate, sampling rate, and the play of MP3 files.
Time, described by the entrance to the result set. If the result set entrance is not an MP3 file
If no data is placed between NULs.
In the absence of unfavorable results, some clients extends by simply abandoning data between NULs.
GNotella's queryhit descriptor. Additional clients may, due to data in the results
Did not end as expected, you cannot read the descriptor correctly. Once you read the wrong, it causes a series of
Mistakement, and its connection may be disconnected.
