Developers.Gnutella.Ultrapeer

Leaf Mode and Ultrapeer Mode

Gnutella programs run in one of two roles: Leaf and Ultrapeer. In Ultrapeer mode, a Gnutella program is really on the Gnutella network. It's connecting to other Ultrapeers and routing seach and hit packets. Its Internet connection is so fast it can do this for a bunch of Gnutella programs running in Leaf mode beneath it.

categorizing the nodes on the network as leaves and ultrapeers. A leaf keeps only a small number of connections open, and that is to ultrapeers. An ultrapeer acts as a proxy to the Gnutella network for the leaves connected to it.

The following things seem to be true about ultrapeers:

• A gnutella program can be running in leaf mode, or ultrapeer mode. It can switch from one mode to the other, but it can't be in both modes at the same time.
• Ultrapeers connect to other ultrapeers, and have connections down to leaves beneath them. Leaves connect up to ultrapeers. Leaves never connect to each other.
• An ultrapeers will have a handful of ultrapeer connections, and many of leaf connections. A leaf will have a handful of ultrapeer connections, even though it really only needs one.

Ultrapeers are connected to each other and to "normal" Gnutella hosts (hosts that do not implement the Ultrapeer system).

The ultrapeer system has been around long enough now that we don't really have to worry about running into a Gnutella program that is so old it hasn't implemented it. But, if we did, the legacy Gnutella node would be treated like an ultrapeer. So, this is about creating the new leaf role, and making the network smaller. In the beginning, every Gnutella program was running as an ultrapeer all the time.

An ultrapeer decides what queries to forward to leaf nodes using the Query Routing Protocol, QRP

When a leaf connects to an ultrapeer, it sends information about what it is sharing. The ultrapeer uses this information to only forward searches to leaves that could possibly have hits for them. For instance, a leaf that tells its ultrapeer it's sharing nothing won't get any search packets at all.

It is RECOMMENDED that servents implement the Ultrapeer system, or any future system for decreasing the bandwidth load on modem users.

Even as a leaf, Gnutella never worked well over a modem. Also, even with a broadband connection, most Gnutella programs run as leaves.

X-Ultrapeer X-Ultrapeer-Needed X-Try-Ultrapeers X-Query-Routing

These are the handshake headers specific to the ultrapeer system. If a computer says X-Ultrapeer: True, that means it is an ultrapeer. If it says X-Ultrapeer: False, then it's a leaf. The wiki doesn't have much information about X-Ultrapeer-Needed. I think a computer sets it to true when it's looking for more ultrapeers to connect to. X-Try-Ultrapeers is a list of IP addresses where Gnutella programs running in Ultrapeer mode can be found. X-Query-Routing announces that this computer is able to send and receive QRP tables.

Here is a sample interaction where a leaf connects to an ultrapeer. The leaf is now a shielded node of the ultrapeer. The leaf should drop any non-ultrapeer connections and send a QRP routing table

This is what keeps a program from being half in leaf mode and half in ultrapeer. As soon as a Gnutella program says it's a leaf and connects to an ultrapeer, it shouldn't connect to leaves anymore.

(find where shareaza connects as a leaf to an ultrapeer, and then drops leaf connections)

If a shielded leaf node receives a connection request, it will refuse to accept the connection by returning a 503 error code together with X-Try and X-Try-Ultrapeer headers to redirect to remote host to other addresses.

A leaf connects to several ultrapeers, and uses Gnutella through them. It doesn't accept any incoming connections at all, even from ultrapeers. It's a leaf's job to find and connect to ultrapeers. Ultrapeers don't have to go looking for leaves.

(find where shareaza, running in leaf mode, refuses connection requests with 503 and x-try headers)

Sometimes nodes will be ultrapeer-incapable but unable to find an ultrapeer. In this case, they behave exactly like old, unrouted Gnutella 0.4 connections.

This is complicated. A program decides it is ultrapeer-incapable if it's running on Windows 98 or has a slow Internet connection. Really, it should just find an ultrapeer. It's much more likely that it will find an ultrapeer than a computer in a similar situation.

(does shareaza deal with this situation, or just keep looking for an ultrapeer?)

When two ultrapeers meet, both set X-Ultrapeer: true. If both have leaf nodes, they will remain ultrapeers after the interaction.

This is the start of the rules for how network role can change during a handshake. To be an ultrapeer, you have to have leaves.

Note that no QRP route table is sent between ultrapeers after the connection is established.

QRP is just for leaves and ultrapeers.

Consider the case of an ultrapeer A connecting to an ultrapeer B. If B doesn't have enough leaves, it may direct A to become a leaf node. If A has no leaf connections, it stops fetching new connections, drops any Gnutella 0.4 connections, and sends a QRP table to B. Then B will shield A from all traffic.

I think doesn't have enough leaves should be doesn't have any leaves. This is the handshake interaction that involes x-ultrapeer-needed. The three groups look like this:

X-Ultrapeer: True

X-Ultrapeer: True X-Ultrapeer-Needed: False

X-Ultrapeer: False

The connecting computer says it's an ultrapeer, but how does it say it doesn't have any leaves? How does the computer receiving the connection decide it doesn't need any more ultrapeer connections? I guess once it says that, the first computer has two options: become a leaf, or disconnect.

(find where shareaza goes from ultrapeer to leaf) (find where shareaza uses x-ultrapeer-needed)