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.