Gnutella Protocol Development

Our blue logo

Gnutella Protocol Development

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

3.1 The local hostcache

In order to help the bootstrap process (see 2.1 Bootstrapping), 
a servent SHOULD implement a hosts cache (also sometimes called a 
hosts list), keeping a few hundreds hosts on the disc. The 
probability that at least one of them is running is very high, even
when the list is several weeks old.

The hosts list has two purposes : 
   1. Make connection times to the GNet shorter
   2. Make as less GWebCache calls per session as possible (ideally, 
      only one).

The list of hosts is loaded when the servent is launched. It is filled 
with hosts grabbed from GWebCache calls, from X-Try and X-Try headers,
from pongs, and optionally from queryHits. And it is saved (the whole
list, or just a subset) when the user exits the application. A 
starting hosts list SHOULD be distributed with the client, filled 
with known servents having a regular activity on the GNet, so that
even the very first time the servent is launched, it will be able to 
use the host cache. The list of hosts SHOULD NOT be hard coded, notably
to avoid sending too many connections requests to the same small 
subset of the GNet.

Many enhancements to this scheme are possible. There are a lot of
possibilities with keeping a big hosts list in RAM, but 
saving only a subset of it, based on some evaluation function. 
Hence, a client could store only hosts with which a "strong" 
GNet connection has been made, a connection being marked as strong 
after a few tenths of seconds, for instance one minute. 
A true evaluation function can also be computed, based on various
parameters : 
  * remote servent uptime.
  * remote servent shared files size and count
  * last time the remote servent was seen
  * whether a connection has been made with it
  * max uptime if a Gnet connection has been made.


 

 

 

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

SourceForge.net Logo