rfc-0_6-draft.html

p2p技术已经是主流

 * Port number
 * Number of files shared
 * Number of kilobytes shared
 * GGEP extension block (if present)
 * Hops value, i.e. how far away on the network the host using the 
   stored address is

When a Ping message, called P, is received over connection C, and
it has been at least one second since last time a ping was received 
over C, the servent will return a number of pongs (10 for example)
from its stored pongs. The pongs will be pick from all connections
except from C, since it would be no good sending pongs back where 
they came from. A servent should also return a pong with information 
about itself, if it can accept incoming connections.

The outgoing pong will have the same message ID as P, not the message
ID it had when the pong was received. The Hops is set to the stored 
hops value + 1, and TTL so that TTL+Hops=7. If the TTL is less than 
P's Hops value, the current stored pong will not be sent. This also 
means that pongs whose Hops value already is 7 will not be propagated
any further.

Exactly how to select which of the stored pongs to send in response 
to an incoming ping is up to each servent. A good idea is to pick 
pongs from different connections and with varying stored Hops values.

To keep the cache fresh, a ping (TTL=7, Hops=0) is sent over all 
connections at small interval (like every 3 seconds). This look like
very often, but remember that the neighbour servents will just 
respond with pongs from its own cache. The short time ensures that 
pongs are always fresh. To neighbour hosts who has not indicated 
that they support pong caching (using the Pong-Caching handshaking 
header), one ping per minute might be a better number.

Incoming pings with TTL=1 and Hops=0 or 1 (see above section 2.2.4) 
is replied to with a single pong containing information about the 
local host. Pings with TTL=2 and Hops=0 are replied to with one pong 
about the local host, and one about each other host the local host is
connected to. Information about the neighbour hosts is retrieved when
a new connection is started by sending a TTL=1, Hops=0 ping and 
storing the pong returned. This can be done using handshaking headers
instead.

The bandwidth used by this scheme is very limited. Assuming a ping is
sent every 3 seconds and that 10 pongs are returned to every ping. 
Since a (without extensions) is 23 bytes and a pong (without 
extensions) is 37 bytes, the amount of bandwidth used per connection 
is (23+10*37)/3 = 131 bytes/sec/connection. If extensions are used in
ping and/or pong messages, the bandwidth usage will increase, but 
will still be kept on an acceptable level. If the bandwidth usage 
must re decreased further, the interval between update pings could be
increased.


2.2.4.2 Other pong caching schemes

A slightly more advanced scheme for pong caching is available at
http://www.limewire.com/index.jsp/pingpong

A different, but compatible scheme can be found at
http://groups.yahoo.com/group/the_gdf/files/Proposals/PONG/Variants/
        pingreduce.txt

Other schemes might have been created after this was written.


2.2.5 Query (0x80)

Since Query messages are broadcasted to many nodes, the total size 
of the message SHOULD not be larger than 256 bytes. Servents MAY drop
Query messages larger that 256 bytes, and SHOULD drop Query messages 
larger than 4 kB.

A Query message has the following fields:

Bytes:  Description:
0-1     Minimum Speed. The minimum speed (in kb/second) of servents
        that should respond to this message. A servent receiving a 
        Query message with a Minimum Speed field of n kb/s SHOULD 
        only respond with a Query Hit if it is able to communicate at
        a speed >= n kb/s.
        
2-      Search Criteria. This field is terminated by a NUL (0x00).

        See section 2.2.7.3 for rules and information on how to 
        interpret the Search Criteria
        
Rest    OPTIONAL extensions block. The rest of the query message is
        used for extensions to the original query format. The allowed
        extension types are GGEP, HUGE and XML (see Section 2.3 and 
        Appendixes 1 and 2).
        
        If two or more of these extension types exist together, 
        they are separated by a 0x1C (file separator) byte. Since 
        GGEP blocks can contain 0x1C bytes, the GGEP block, if 
        present, MUST be located after any HUGE and XML blocks.
        
        The type of each block can be determined by looking for the 
        prefixes "urn:" for a HUGE block, "<" or "{" for XML and 0xC3 for
        GGEP.

        The extension block SHOULD NOT be followed by a null (0x00) 
        byte, but some servents wrongly do that.


2.2.6 Query Hit

Query Hit messages has the following fields:

Bytes:  Description:
0       Number of Hits. The number of query hits in the result set 
        (see below).
        
1-2     Port. The port number on which the responding host can accept
        incoming HTTP file requests. This is usually the same port as
        is used for Gnutella network traffic, but any port MAY be 
        used.
        
3-6     IP Address. The IP address of the responding host. 
        Note: This field is in big-endian format.

7-10    Speed The speed (in kb/second) of the responding host.
        
11-     Result Set. A set of responses to the corresponding Query. 
        This set contains Number_of_Hits elements, each with the 
        following structure:
        
        Bytes:  Description:
        0-3     File Index. A number, assigned by the responding 
                host, which is used to uniquely identify the file 
                matching the corresponding query.

        4-7     File Size. The size (in bytes) of the file whose 
                index is File_Index.

        8-      File Name. The name of the file whose index is 
                File_Index. Terminated by a null (i.e. 0x00) 

        x       Extensions block. Allowed extension types are HUGE, 
                GGEP and plain text metadata. This field is 
                terminated by a null (0x00), even if there are no 
                extensions (resulting in a double null). Also, the
                extensions block itself MUST NOT contain any null 
                bytes.
        
                If two or more of these extension types exist 
                together, they are separated by a 0x1C (file 
                separator) byte. Since GGEP blocks can contain 0x1C 
                bytes, the GGEP block, if present, MUST be located 
                after any HUGE and plan text blocks.
                
                The type of each block can be determined by looking 
                for the prefixes "urn:" for a HUGE block, 0xC3 for 
                GGEP and anything else is probably plain text 
                metadata.
        
                Plain text metadata is intended to be displayed 
                directly to the user. It was first invented by 
                Gnotella (a now discontinued Gnutella servent) to tag
                MP3 files. Examples:
                "192 kbps 44 kHz 3:23"
                "120 kbps(VBR) 44kHz 3:55" (variable bitrate)
                Other plan text formats MAY be used.
        
x       RECOMMENDED extra block. This block is not required, but 
        strongly recommended. It is sometimes called EQHD, or 
        (incorrectly) just QHD. It has the following format:
        
        Bytes:
        0-3     Vendor Code. Four case-insensitive characters 
                representing a vendor code. For example "LIME" for 
                LimeWire. See registered codes and register yours at
                http://groups.yahoo.com/group/the_gdf/database?
                        method=reportRows&tbl=6 
                        (Requires GDF membership)

        4       Open Data Size. Contains the length (in bytes) of the
                Open Data field. Set to 2 in most current 
                implementations, and 4 in those that support XML 
                metadata outside GGEP (see Section 2.3 and Appendix 2). 
                The Open Data area MAY be larger to allow future 
                extensions.
        
        x       Open Data. Contains two 1-byte flags fields with the 
                following layout and in the specified order:
                
                bit:    Description:
                7,6     Reserved for future use
                5       flagGGEP
                4       flagUploadSpeed
                3       flagHaveUploaded
                2       flagBusy
                1       Reserved for future use
                0       flagPush

                The first flag byte can be viewed as an "enabler" for
                the flags in the second byte, the "setter".  Only
                those bits that were enabled must be considered by
                the servent as being valid.  This logic is reversed
                for flagPush, which is set in the first byte and
                enabled in the second.  The enabling byte allows
                you to know which flags are supported by a given
                servent.

                Bits 5,4,3,2 in the first byte MUST be set if and 
                only if the corresponding flag in the second byte is 
                meaningful.

                Bit 0 in the second byte MUST be set if and only 
                if the corresponding flag in the second byte is 
                meaningful. Yes, the order is reversed for this flag.

                flagGGEP is set is set if and only if the private
                data block (see below) contains a GGEP block.

                flagUploadSpeed is set if and only if the Speed field
                of the QueryHit message contains the highest 
                average transfer rate (in kbps) of the last 10 
                uploads. Otherwise Speed field contains the hosts 
                total upload speed as set by the user, and therefore 
                less reliable.

                flagHaveUploaded is set if and only if the servent 
                has successfully uploaded at least one file.

                flagBusy is set if and only if the all of the 
                servent's upload slots are currently full.

                flagPush is set if and only if the servent is 
                firewalled or cannot accept incoming TCP connections 
                for any other reason.

                The reserved flags MUST not be set, unless they are 
                used for a future extension.

                If XML metadata (Appendix 2) is included in the 
                current Query Hit message, the following 2 bytes of
                Open Data area will contain the size of the XML 
                block. The XML block itself is placed in the private 
                area (see below).

x       Private Data. Undocumented vendor-specific data. This field 
        continues till the servent Identifier, which uses the last 16
        bytes of the message.

        If the flagGGEP in the open data block is set, this block
        contains a GGEP (see Section 2.3) extension block. The GGEP 
        block starts with a 0xC3 byte. Any data before or after the 
        GGEP block is vendor-specific data, and MUST be ignored, if 
        not recognized.

        Servents are NOT RECOMMENDED to use the private data area for
        vendor specific data. Servents SHOULD use GGEP extensions 
        instead.

        If the Open Data area indicates an XML block is will also be 
        placed in the private area (see Appendix 2). Assuming that 
        the two bytes in the Open Data area specifies an XML block of
        m bytes, that block can be found by extracting the last m 
        bytes of the private area. Both GGEP and XML can exist in the
        same Private Data area, but XML SHOULD be implemented inside 
        GGEP.
        [TODO: How about the nul after the XMP block? What is it good for?]

Last 16 Servent Identifier. A 16-byte string uniquely identifying the
        responding servent on the network. This SHOULD be constant 
        for all Query Hit messages emitted by a servent and is 
        typically some function of the servent's network address. The
        servent Identifier is mainly used for routing the Push 
        Message (see below).


2.2.7 Use of Query and Query Hit

2.2.7.1 Forwarding and routing of Query and Query Hit messages

A servent SHOULD forward incoming Query messages to all of its 
directly connected servents, except the one that delivered the 
incoming Query. Servents using Flow control or Ultrapeers (sections 
3.1 and 3.2) will not always forward every Query over every 
connection.

A servent MUST decrement a message header's TTL field, and 
increment its Hops field, before it forwards the message to any 
directly connected servent. If, after decrementing the header's TTL 
field, the TTL field is found to be zero, the message MUST NOT 
be forwarded along any connection.

A servent receiving a message with the same Payload Message and 
Message ID as one it has received before, MUST discard the 
message. It means the message has already been seen.

QueryHit messages MUST only be sent along the same path that 
carried the incoming Query message. This ensures that only those 
servents that routed the Query message will see the QueryHit 
message in response. A servent that receives a QueryHit message
with  Message ID = n, but has not seen a Query message with 
Message ID = n SHOULD remove the QueryHit message from the 
network.


2.2.7.2 When and how to send new Query messages.