Gnutella Protocol Development

Our blue logo

Gnutella Protocol Development

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

3.9 Managing GNetConnections

3.9.1 When to open or accept new Gnutella connections
Source - Latest draft

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 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 much 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, either some
connections have a bandwidth which is too small to receive all the
messages going through the local servant. in both case, 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 duplicates messages from a connection, this means
that there is a small cycle betweent 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 servent under developpment. They should be dropped after
a reasonable amount of time (never more than a few minutes).


 

 

 

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

SourceForge.net Logo