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.