rfc-0_6-draft.html

p2p技术已经是主流

Query messages are usually sent when the user initiates a search. A
servent MAY also create Queries automatically, to find more locations
of a resource for example. If doing so the servent MUST be very 
careful not overload the network. A servent SHOULD not send more than
one automatic query per hour.

Servents SHOULD NOT allow the user to create a large amount of 
queries by repeatedly clicking on a button.

Servents SHOULD watch queries originating from its neighbours
(Hops=0) If those queries are too frequent, are duplicates or 
indicate bad servents behavior in any other way, the servents SHOULD 
drop those queries or even close the connection.

The TTL value of a new query created by a servent SHOULD NOT be 
higher than 7, and MUST NOT be higher than 10. The hops value MUST be
set to 0.


2.2.7.3 When and how to respond with Query Hit messages.

When a servent receives an incoming Query message it SHOULD match 
the Search Criteria of the query against its local shared files. 

The Search Criteria is text, and it has never been specified which 
charset that text was encoded with.  Therefore, servents MUST assume 
it is pure ASCII only.  If any byte with the 7th bit set (high bit) 
is found, then either there is a GGEP extension specifying the 
encoding used, or the servent SHOULD guess the proper encoding.
Most likely, it will be ISO-latin-1 or UTF-8.

Exactly how to interpret the Search Criteria is not specified 
either, but here are some guidelines for interoperability between 
servents:

The Search Criteria is a string of keywords.  A servent SHOULD only 
respond with files that has all the keywords.  It is RECOMMENDED to 
break up the words on any non-alphanumeric characters (anything but 
letters and numbers).  A space is the standard separator between 
words.

Servents MAY also require that all matching terms be present in the 
same number and order as in the query.

Regular expressions are not supported and common regexp "meta-
characters" such as "*" or "." will either stand for themselves or be
ignored. The matching SHOULD be case insensitive.  Empty queries or 
queries containing only 1-letter words SHOULD be ignored.

GGEP extensions MAY be used to provide details on how to parse the 
Search Criteria (such as specifying that regular expressions matching
should be used), but a servent can never be sure other servents will 
understand the GGEP extension.

Servents MAY ignore queries whose Search Criteria is shorter than 
a chosen length. The reason is to ignore too broad searches.

Query messages with TTL=1, hops=0 and Search Criteria="    " (four
spaces) are used to index all files a host is sharing. Servents 
SHOULD reply to such queries with all its shared files. Multiple 
Query Hit messages SHOULD be used if sharing many files. Allowed 
reasons not to respond to index queries include privacy and 
bandwidth. 

Query Hit messages MUST have the same Message ID as the Query message
it is sent in reply to. The TTL SHOULD be set to at least the hops
value of the corresponding query plus 2, to allow the Query Hit to
take a longer route back, if necessary. The TTL value MUST be at
least the hops value of the corresponding query, and the initial
hops value of the Query Hit message MUST (as usual) be set to 0.
Some servents use a TTL of (2 * Query_TTL + 2) in their replies to
be sure that the reply will reach its destination.  Replies with
high TTL level SHOULD be allowed to pass through.


2.2.8 Push (0x40)

A Push message has the following fields:
Bytes:  Description:

0-15    Servent Identifier. The 16-byte string uniquely identifying 
        the servent on the network who is being requested to push the
        file with index File_Index. The servent initiating the push 
        request MUST set this field to the Servent_Identifier 
        returned in the corresponding QueryHit message. This is 
        used to route the Push message to the sender of the Query 
        Hit message.

16-19   File Index. The index uniquely identifying the file to be 
        pushed from the target servent. The servent initiating the 
        push request MUST set this field to the value of one of the 
        File_Index fields from the Result Set in the corresponding 
        QueryHit message.

20-23   IP Address. The IP address of the host to which the file with
        File_Index should be pushed. This field is in big-endian 
        format.

24-25   Port. The port number the receiver of this message should 
        push to.

26-     OPTIONAL GGEP extension block. (see Section 2.3)

A servent may send a Push message if it receives a QueryHit 
message from a servent that doesn't support incoming connections. 
This might occur when the servent sending the QueryHit message is 
behind a firewall.  When a servent receives a Push message, it SHOULD
act upon the push request if and only if the servent_Identifier field
contains the value of its servent identifier.  The Message_Id field
in the Message Header of the Push message SHOULD not contain the same
value as that of the associated QueryHit message, but SHOULD contain 
a new value generated by the servent's Message_Id generation 
algorithm.

Push messages are forwarded back to the originator of the Query Hits 
message using the Servent Identifier value.  This means multiple Push
messages can have the same Servent Identifier.  Push messages MUST 
only be considered as duplicates if the Message ID in the header is 
the same.  Since Push messages are not broadcasted, duplicate 
messages should be very rare.


2.2.9 Bye (0x02)

The Bye message is an OPTIONAL message used to inform the 
servent you are connected to that you are closing the connection. 

Servents supporting the Bye message MUST indicate that by sending 
the following header in the handshaking sequence:

        Bye-Packet: 0.1

Servents MUST NOT send Bye messages to hosts that has not indicated 
support using the above header.  Future versions will be backwards 
compatible, so Bye messages MAY also be sent to hosts providing the 
above header with a later version number.

A Bye packet MUST be sent with TTL=1 (to avoid accidental propagation
by an unaware servent), and hops=0 (of course).

A servent receiving a Bye message MUST close he connection 
immediately. The servent that sent the packet MUST wait a few 
seconds for the remote host to close the connection before closing 
it.  Other data MUST NOT be sent after the Bye message.  Make sure 
any send queues are cleared. 

The servent that sent by Bye message MAY also call shutdown() with 
'how' set to 1 after sending the Bye message, partially closing the 
connection.  Doing a full close() immediately after sending the Bye 
messages would prevent the remote host from possibly seeing the Bye 
message.

After sending the Bye message, and during the "grace period" when
we don't immediately close the connection, the servent MUST read
all incoming messages, and drop them unless they are Query Hits
or Push, which MAY still be forwarded (it would be nice to the
network).  The connection will be closed as soon as the servent
gets an EOF condition when reading, or when the "grace period"
expires.

A Bye message has the following fields:
Bytes:  Description:

0-1     Code. The presence of the Code allows for automated processing
        of the message, and the regular SMTP classification of error 
        code ranges should apply. Of particular interests are the 
        200..299, 400..499 and 500..599 ranges.
        Here is the general classification ("User" here refers to the 
        remote node that we are disconnecting from):

        2xx     The User did nothing wrong, but the servent chose to 
                close the connection: it is either exiting normally 
                (200), or the local manager of the servent requested 
                an explicit close of the connection (201).

        4xx     The User did something wrong, as far as the servent is
                concerned. It can send packets deemed too big (400), 
                too many duplicate messages (401), relay improper 
                queries (402), relay messages deemed excessively long-
                lived [hop+TTL > max] (403), send too many unknown 
                messages (404), the node reached its inactivity 
                timeout (405), it failed to reply to a ping with TTL=1
                (406), or it is not sharing enough (407).

        5xx     The servent noticed an error, but it is an "internal" 
                one. It can be an I/O error or other bad error (500), 
                a protocol desynchronization (501), the send queue 
                became full (502).

2-      NULL-terminated Description String. The format of the String 
        is the following (<cr> refers to "\r" and <lf> to "\n"):

                Error message, as descriptive as possible

        or optionally, something more qualified, with HTTP-like 
        headers giving out more information:

                Error message, as descriptive as possible<cr><lf>
                Server: some server/version<cr><lf>
                X-Gnutella-XXX: some specific Gnutella header<cr><lf>
                for instance telling the host about alternate<cr><lf>
                nodes it could connect to<cr><lf>
                <cr><lf>

        The presence of a <cr><lf> at the end of message indicates 
        that HTTP-like headers are present.  The absence of any 
        <cr><lf> indicates that the short error message form was used.

        Unless circumstances making that impossible (urgent 
        disconnection due to a memory fault), the HTTP-like headers 
        version SHOULD be used, with at least a Server: header, 
        allowing better tracing and debugging.

For further information about the Bye message, please refer to the
original documentation located at:
http://groups.yahoo.com/group/the_gdf/files/Proposals/BYE/


2.3 GGEP Extension blocks

The Gnutella Generic Extension Protocol (GGEP) allows arbitary 
extensions in Gnutella messages. A GGEP block is a framework for 
other extensions. If you wish to implement a new extension to a 
packet, you MUST do so inside GGEP. Some extensions that were 
invented before GGEP (XML metadata for example) are allowed to 
existoutside GGEP. 

Servents are RECOMMENDED to implement GGEP.  However, all servents 
MUST pass on GGEP extension blocks inside Gnutella messages. servents
that have support the forwarding of all packets that contain GGEP 
extensions (whether or not they can process them), MUST include a new
header in the Gnutella 0.6 connection handshake indicating this 
support.  This will allow other servents to know what types of 
packets this servent can accept.  The format of this header is 

GGEP : majorversion.minorversion

As the current version of GGEP is 0.5 when this was written the 
header would be

GGEP: 0.5

Servents SHOULD remove any GGEP blocks from Ping, Pong and Push 
messages before sending those messages to hosts that have not 
indicated GGEP support.

For the original GGEP documentation see
http://groups.yahoo.com/group/the_gdf/files/Proposals/GGEP/


2.3.1 GGEP Format

A GGEP block always starts with a magic byte used to help distinguish
GGEP extensions from legacy data which may exist.  It must be set to 
the value 0xC3.

When a GGEP block is used between the nulls in a result in a Query 
Hits message, it is not allowed to contain any null bytes. This 
requires some special tricks in the field format.

The magic byte is followed by any number of extensions. They SHOULD 
be processed in the order in which they appear. The following is the 
format of each extension:

Bytes used:     Field Name:
1               Flags
1-15            ID
1-3             Data Length
x               Extension Data

Flags:          These are options which describe the encoding of the 
                extension header and data.

                Bit    Name             
                7      Last Extension.  When set, this is the last 
                       extension in the GGEP block.

                6      Encoding.  The value contained in this field 
                       dictates the type of encoding which should be 
                       applied to the extension data (after possible 
                       compression).

                       0 = There is no encoding on the data. 
                       1 = The data is encoded using the COBS scheme.

                       Details about the COBS encoding scheme can be 
                       found at http://www.acm.org/sigcomm/sigcomm97/
                                    papers/p062.pdf  

                5      Compression.  The value contained in this 
                       field dictates the type of compression that 
                       should be applied to the extension data. 

                       0 = The extension data has not been compressed.
                       1 = The extension data should be decompressed 
                           using the deflate algorithm. 

                       One should only compress data if doing so will
                       make a material difference in the resulting 
                       packet size.