Gnutella Traffic Shaping

Our blue logo

Gnutella Protocol Development

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

3.4 Pong caching
Source - Latest draft

3.4.1 Requirements for a pong cache implementation

There are different systems for handling Ping and Pong messages, 
but what they have in common is:

    * When a Ping message is received (TTL>1 and it was at least one 
      second since another Ping was received on that connection), a 
      servent MUST, if possible, respond with a number of Pong 
      Messages. These pongs MUST have the same message ID as the 
      incoming ping, and a TTL no lower than the hops value of the 
      ping. The number of pongs returned may vary, but 10 is a 
      reasonable number. Servents that are able to accept incoming 
      Gnutella SHOULD reply to these Ping messages.

    * The pongs sent SHOULD have a good quality. That includes
      high probability that they are connectable and a good spread 
      of hosts from across the network

    * The bandwidth used by Ping and Pong messages SHOULD be 
      minimized. Servents MUST never output very high quantities of 
      Ping and Pong messages.

    * An incoming Ping message with TTL = 1 and Hops = 0 or 1 is 
      used to probe the remote host of a connection, and MUST 
      always be replied to with a pong having information about the 
      host who received the ping.

    * An incoming Ping message with TTL = 2 and Hops = 0 is a 
      "Crawler Ping" used to scan the network. It and SHOULD be 
      replied to with pongs containing information about the host 
      receiving the ping and all other hosts it is connected to. The
      information about neighbour nodes can be provided either by 
      creating pongs on their behalf, or by forwarding the ping to 
      them, and forward the pongs returned to the crawler.

Servents fulfilling these requirements MUST provide a the header
"Pong-Caching: 0.1" (or a higher number if a later version is used) 
during the handshake. That allows other nodes to know if pong 
caching in any form is supported. Note that this applies to servents 
do not really cache pong messages as well, as long as the rules above
applies. Servents are strongly RECOMMENDED to follow the rules above,
and provide the Pong-Caching header.

When storing or forwarding Pong messages, any GGEP payload SHOULD be
included. When sending a Ping message, one cannot know if it will 
reach only the neighbour host, or many hosts on the network. It 
depends on what system for handling Ping and Pong messages other 
servents are using. Servents MUST NOT make assumptions of how far 
a Ping message (and its payload) will reach.


3.4.2 A simple pong caching scheme

This is one system for handling Ping and Pong messages. There are 
others available (see 3.4.3), and any system that abides to 
the rules in sect. 3.4.1 is ok.

For each connection an array of Pong Messages are stored. 10 may 
be a good number. When a pong comes in, it overwrites the oldest 
stored pong in array of he connection the pong came from. The 
information that must be stored for each pong is:

 * IP Address
 * 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.


3.4.3 Other pong caching schemes

A slightly more advanced scheme for pong caching was proposed by LimeWire :
LimeWire's Pong Caching
http://rfc-gnutella.sourceforge.net/src/pong-caching.html

A different, but compatible scheme for ping reduction has been written by Mike Green:
ping reduction
http://rfc-gnutella.sourceforge.net/src/pingreduce.html

Another scheme was derived from the last one: 
another ping reduction scheme
http://rfc-gnutella.sourceforge.net/src/pingreduce2.html

Other schemes might have been created after this was written.


 

 

 

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

SourceForge.net Logo