Gnutella Protocol Development

Our blue logo

Gnutella Protocol Development

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

2.1 Bootstrapping 
In the early stages of the Gnutella protocol, there were several known
permanent hosts whose purpose was to provide a list of Gnutella hosts 
to any Gnutella servent connecting to them. These were often called 
"hostcaches". However hostcaches are not used anymore. 

In order to connect to the Gnutella network, the servent needs to find 
and store hosts addresses. There are four ways by which a servent may 
get hosts addresses : 
   1. Calling a GWebCache
   2. Storing hosts addresses read from X-Try and X-Try-Ultrapeers 
      headers during handshakes (whether the handshake was successfull 
      or not).
   3. Storing hosts addresses in pong messages (after at least one 
      connection is established with the GNet).
   4. Storing hosts addresses read from QueryHit messages (after two
      connections at least are established with the GNet). This 
      assumes that the remote servent uses the same port for upload
      slots than for GNet slots (which is the case with most servents).

The GWebCache protocol allows to get hosts addresses by sending an HTTP
request to a GWebCache server (see (3.2) The WebCache System). But great
care should be taken to not hammer the web caches with too many 
requests. In most cases, it is not needed to call a GWebCache 
more than once per session. This means, notably, that if the user got 
disconnected for some reason, and then connects again, the servent 
SHOULD NOT call a GWebCache.

Instead, a servent SHOULD implement a host cache (see 
(3.1) The Local Hostcache) to store the hosts found
by any of the four ways described aboved, and use it in conjunction 
with the WebCache System.

Below is a suggested bootstrapping algorithm which should ensure
that the mean count of GWebCache calls per session is near 
(slightly above) one :

   * Launch the client and load the host cache.
   * Try to connect to the GNet, using the host cache.
   * If after X seconds, there's no connection to the GNet, choose 
     randomly a GWebCache and send a request.
   * Wait for at least Y seconds before sending a request to 
     another GWC (it may happen that the first choosen GWC is down,
     or very slow to answer).
   * After Y seconds, if no results have been received from the
     first GWC call, call a new GWC each Z seconds, until a response 
     is received from one of them.
   * Once results have been received from (at least) one GWC, NEVER 
     send a new request during the next session, unless the hosts 
     list is empty (which should never happen theoritically, if a 
     starting hosts list is provided with the software, assuming 
     there's no option allowing the user to clear it).
	 
Suggested values in seconds for X, Y and Z are respectively 5, 10, 2.
This should ensure that the servent will connect quickly to the GNet,
while keeping the count of GWebCache calls very low.

The bootstrapping routine SHOULD also ensure that the servent does
not try to connect too often to a remote host. Less than once per
minute is a reasonable threshold. To make this possible, one solution 
is to ensure that the hosts list has always enough hosts, so that it 
takes at least one minute to try each of them.

Every servent SHOULD send an X-Try header during the handshake. This 
header gives a list of hosts that the remote servent can
try to connect to, allowing it to get new host addresses without using
the GWebCache. Example:

   X-Try:  1.2.3.4:1234, 1.2.3.5:6346, 1.2.3.6:6347

A servent SHOULD send a reasonable number of hosts, common values are 
between 10 and 20. However, the hosts sent
with X-Try headers should have a good quality. Therefore, a servent 
SHOULD only include in these headers the remote hosts that were known 
to be still active recently (no more than a few minutes ago). If there
are less than 10 hosts recently seen as active, then send less. Hosts
found in Pong replies are supposed to have free slots if the servent
implements a pong-caching scheme. This is not the case for hosts
obtained by monitoring the queryHits. Thus, hosts found in Pong replies
are good candidates to take place in X-Try headers, while hosts found 
in QueryHits are not. 


 

 

 

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

SourceForge.net Logo