Gnutella Protocol Development

Our blue logo

Gnutella Protocol Development

Home :: Developer :: Press :: Research :: Servents

2.7 Querying the network
Source - Latest draft

This chapter describes the use of Query and QueryHits messages.

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.7.2 When and how to send new Query messages

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.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.




 

 

 

Home :: Developer :: Press :: Research :: Servents

SourceForge.net Logo