Managing GNet connections

From Gnutella Developers

<< The Query Routing Protocol | Gnutella Generic Extension Protocol >> | Main Page


When to open or accept new Gnutella connections

Source - [Latest draft. (http://rfc-gnutella.sourceforge.net/src/rfc-0_6-draft.html)]

The number of Gnutella connections that is suitable depends on the speed the internet connection. Many servents selects a fixed number of connections based on the connection speed selected by the user. A better way would be to automatically regulate the number of connections to make sure a suitable amount of bandwidth is used on the Gnutella network traffic.

A common technique is to open new outgoing connections until 2 or 3 connections are running, and then wait for incoming connections to fill the remaining slots. If the host cannot accept incoming connections for some reason, the servent will have to open new connections until it has enough.

When opening a new connection a servents must select which address to connect to. They SHOULD prefer hosts from Pong messages that are new (since it is more probable that the host can still accept incoming connections) and from Pong with a high Hops count (since it will reduce the amount of cycles on the network.

Servents MAY prefer other servents from the same vendor, or servents that have certain features, but MUST always make sure that network is not fragmented. It MUST always be possible for servents that follow this protocol to search and download files form each other. If a servents is not full on connections it SHOULD NOT deny an incoming connection request unless the remote host is missing a very important feature.


3.9.2 Dropping Connections

In order to preserve a good connectivity and stability of the GNet, a servent SHOULD avoid dropping too many connections.

3.9.2.1 Flow control

A connection can be controled either locally, or remotely. In the case of a locally flow controled connection, there are two potential reasons : either the servent has too many connections, or some connections have a bandwidth which is too small to receive all the messages going through the local servant. In both cases, the connection with the higher rate of messages dropped by flow control SHOULD be dropped after a reasonable amount of time of continual flow control. A suggested value is 5 minutes [IS THIS CORRECT ?].

In the case of a remotely flow controled connection, the Gnutella protocol doesn't allow the servent to be informed. Some vendors (GTK-Gnutella) use the Hops flow vendor message for this purpose, but this should not be considered as a standard Gnutella feature.

3.9.2.2 Duplicates

If there are too many duplicated messages from a connection, this means that there is a small cycle between two connections, close from the local servent. The connection having the more duplicate messages is the one with the longer delay (the message went through another connection before this one). If the rate of duplicate messages is too high, the connection should be dropped. A suggested value is 30 % [IS THIS CORRECT ?].

3.9.2.3 Bad connections

A bad connnection is a connection which sends many wrong messages, either because of a desynchronisation, or because there is no route in the case of a routed message. Such connections are most probably created by servents under development. In the case of a message desynchronisation, the connection SHOULD be dropped immediately as this indicates most probably a bogus remote servent. For less harmful issues like unroutable messages, the connection MAY be dropped after a reasonable amount of time (about a few minutes) if the rate of errors is not negligible.

<< The Query Routing Protocol | Gnutella Generic Extension Protocol | Main Page