Ultrapeers and routing

An attempt to reduce the network overhead caused by the initial version of the Gnutella protocol is the introduction of higher level nodes called called ultrapeers. An ultrapeer is a powerful node that maintains many connection to non-ultrapeer nodes, from now on called leaf nodes, and a small number of connections to other ultrapeers.

Ultrapeers shield leaf nodes from almost all Ping and Query traffic. Mainly two suggested approaches of managing ultrapeers and leaf nodes have been proposed.

Indexing

means that ultrapeers periodically send an indexing query to each leaf node and the leaf nodes respond with a message naming all shared files. The ultrapeer uses these to build an index of the leaf nodes, which is then checked when a query arrives.

Bit vector matching

means that each leaf node constructs an array based hash table from words that causes matches for a certain shared resource. Stored in the hash table is simply a flag (or bit) indicating ``present''.

The bit vector is then sent to the ultrapeer. The ultrapeer can then check the words of an incoming query, by running them through the same hash function, and forward the query if the bit vector indicates that matching resources are present in the leaf node. This method is commonly referred to as DHT-based routing, of which two variants is discussed in [HHH$^+$02] and [Pin01].

Some of the benefits of bit vector matching is that the bit vector can be compressed and has better support for incremental updates. It is easier to implement the hash check then to efficiently check an index.

Ultrapeers communicate with other ultrapeers using the broadcast scheme initially presented by Gnutella. It is also possible to have ultrapeers perform additional levels of bit vector passing, creating several layers of ultrapeers, but this has not been implemented.

A problem with ultrapeers is that the risk of receiving false answers to a query increases. Since an ultrapeer 15#15 answers a query by saying that servent 5#5 has a certain list of hits the node issuing the query relies on the behaviour of 15#15 and that 5#5 has not disconnected or changed its set of shared files without notifying 15#15.