Leaf Mode and Ultrapeer Mode
From Gnutella Specification
<< Handshaking | Standard Message Architecture >> | GDF
Source - Ultrapeer Proposal v1.0.
Originally, all Gnutella nodes were connected to each other randomly. It worked fine for users with broadband connections, but not for users with slow modems. That problem can be alleviated by organizing the network in a more structured form.
Ultrapeer system
[TODO: Describe ultrapeer system here. Handshaking etc. Reference to QRP when used]
[TODO: Ultrapeer marked pongs: size field = power of 2]
The Ultrapeer system has been found effective for this purpose. It is a scheme to have a hierarchical Gnutella network by 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. This has an effect of making the Gnutella network scale, by reducing the number of nodes on the network involved in message handling and routing, as well as reducing the actual traffic among them.
An ultrapeer only forwards a query to a leaf if it believes the leaf can answer it, and leaves never relay queries between ultrapeers. Ultrapeers are connected to each other and to "normal" Gnutella hosts (hosts that do not implement the Ultrapeer system).
An ultrapeer decides what queries to forward to leaf nodes using The Query Routing Protocol, QRP. If both an ultrapeer and a leaf node supports another protocol for deciding which queries are forwarded that MAY be used instead. QRP routing is not used between ultrapeers/normal hosts.
It is RECOMMENDED that servents implement the Ultrapeer system, or any future system for decreasing the bandwidth load on modem users.
Ultrapeer election is self-organized. Details on the rules to choose between leaf mode and ultrapeer mode are provided in 3.7 Ultrapeer Election Principles.
For more information please read the original specification.
Ultrapeer Handshaking
Ultrapeer capatibilities and information is exchanged during the handshaking sequence when trying to establishing a new Gnutella connection (see Handshaking). The following new headers are used:
- X-Ultrapeer: "True" signals that node is an ultrapeer, "False"
signals that the node wants to be a shielded leaf node.
- X-Ultrapeer-Needed: Used to balance the number of ultrapeers.
[TODO: Write more about this one]
- X-Try-Ultrapeers: Like X-Try (see Bootstrapping), but contains only addresses of ultrapeers.
- X-Query-Routing: Signals support for The Query Routing Protocol. The header value is the QRP version (currently 0.1).
It is important to note that headers can be sent in any order. Also, case is ignored in "True" and "False".
Here is a sample interaction where a leaf connects to an ultrapeer.
Leaf Ultrapeer
-----------------------------------------------------------
GNUTELLA CONNECT/0.6
User-Agent: LimeWire/1.0
X-Ultrapeer: False
X-Query-Routing: 0.1
GNUTELLA/0.6 200 OK
User-Agent: LimeWire/1.0
X-Ultrapeer: True
X-Ultrapeer-Needed: False
X-Query-Routing: 0.1
X-Try: 24.37.144:6346,
193.205.63.22:6346
X-Try-Ultrapeers: 23.35.1.7:6346,
18.207.63.25:6347
GNUTELLA/0.6 200 OK
[binary messages] [binary messages]
The leaf is now a shielded node of the ultrapeer. The leaf should drop any non-ultrapeer connections and send a QRP routing table (assuming QRP is used).
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. For example, when a leaf tries to connect to another leaf it may look like this. Non-essential headers have been removed in this and the following examples.
Leaf1 Leaf2
-----------------------------------------------------------
GNUTELLA CONNECT/0.6
X-Ultrapeer: False
GNUTELLA/0.6 503 I am a leaf
X-Ultrapeer: False
X-Try: 24.37.144:6346
X-Try-Ultrapeers: 23.35.1.7:6346
[Terminates connection]
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.
Leaf1 Leaf2
-----------------------------------------------------------
GNUTELLA CONNECT/0.6
X-Ultrapeer: False
GNUTELLA/0.6 200 OK
X-Ultrapeer: False
GNUTELLA/0.6 200 OK
[binary messages] [binary messages]
When two ultrapeers meet, both set X-Ultrapeer: true. If both have leaf nodes, they will remain ultrapeers after the interaction. Note that no QRP route table is sent between ultrapeers after the connection is established. Example handshake:
UltrapeerA UltrapeerB
-----------------------------------------------------------
GNUTELLA CONNECT/0.6
X-Ultrapeer: True
GNUTELLA/0.6 200 OK
X-Ultrapeer: True
GNUTELLA/0.6 200 OK
[binary messages] [binary messages]
Sometimes there will be too many ultrapeer-capable nodes on the network. 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. If A has leaf c onnections, it ignores the guidance, as in the above case.
UltrapeerA UltrapeerB
-----------------------------------------------------------
GNUTELLA CONNECT/0.6
X-Ultrapeer: True
GNUTELLA/0.6 200 OK
X-Ultrapeer: True
X-Ultrapeer-Needed: False
GNUTELLA/0.6 200 OK
X-Ultrapeer: False
<< Handshaking | Standard Message Architecture >> | GDF
