Re: [discuss] questions about Ultrapeers and Leafnodes

From: "=E5=B0=B9=E4=BD=90=E5=AE=81" <[email protected]> To: "discuss" <d=
[email protected]>
> I still have some questions about the Leaf mode and ultrapeer mode in=20
> Gnutella. I notice in the rfc of Gnutella, it says "leaves never relay=20
> queries between ultrapeers". if a situation is set like this:
> 1) an ultrapeer A received a query
> 2) A knows one of its leaves, named B might answer the query,then A=20
> forwards the query to B
> 3) B has 3 ultrapeer connections, they are A, C and D respectively.

> will B forwards the query to ultrapeer C and D?

NO, absolutely NO. It's up to C and D to receive the query from another w=
ay,=20
exactly like when A received its copy of the query.

> or "leaves never relay queries between ultrapeers" means that B won't=20
> forward the query to C and D.
> and are leaves the stop points of all queries?

That's exactly the meaning of the sentence. Leaf nodes like B must NEVER=20
reroute the queries they receive from any one, even if they have a=20
connection with other ultrapeers than A, and even if C and D have not sen=
t=20
to leaf B their own copy of the same query.

The main interest of the leaf/ultrapeer architecture is exactly based on=20
this fundamental statement, that leaf nodes never relay any broadcasted=20
message. The broadcast search neatwork only operates within the set of=20
ultrapeers (and of old legacy 0.4-like servents).

(old legacy 0.4 servents are those that do not implement the leaf=20
requirements, and are now highly deprecated; some modern servents acting =
as=20
Ultrapeers may still accept connections from those non-leaf non-ultrapeer=
=20
nodes, but will severely limit their capacity to reroute any message by=20
forcing all broadcast messages like searches they send to them with a TTL=
=3D1,=20
so that these messages will stop its route immediately once received by t=
his=20
old node.)

In addition, leaf nodes normally don't accept any incoming Gnutella=20
connection from leaf nodes, unless they are upgrading their operating mod=
e=20
to Ultrapeer mode after the election process.

> Anyone  who can answer this for me will be highly appreciated!!

These requirements for leaf nodes is what makes that broadcasts will only=
=20
occur within a much smaller network of ultrapeers only, and leaf nodes ar=
e=20
left outside of this undirected random network. This allows expanding=20
considerably the total searchable network diameter, because UltraPeers ar=
e=20
shielding leaf nodes and are filtering most non matching queries.

An Ultrapeer needs to be able to support at least 30 parallel connections=
=20
with leaf nodes, and will typically maintain at least 3 routes with other=
=20
Ultrapeers. Ultrapeers route messages between each other in a much smalle=
r=20
network, so random broadcasts still exist in this network. Typically, the=
=20
number of leaf nodes connected to an ultrapeer will rapidly reach about 2=
0,=20
and will them slowly grow up to nearly 30 (sometimes more if the Ultrapee=
r=20
can handle more connections). The average leaf nodes per UP is then about=
=20
30, meaning that there should be only about 3% ultrapeers and 96% of leaf=
=20
nodes in Gnutella.

But Gnutella has now a third level of Ultrapeers: those (such as LimeWire=
)=20
that implement the UP-to-UP QRP algorithm. This allows those ultrapeers t=
o=20
shield themselve each other (for the last hop only), instead of just rely=
ing=20
on the random broadcast algorithm. This also increases the visible networ=
k=20
diameter. Those Ultrapeers should have at least 3 connections to other=20
UP-to-UP capable ultrapeers, and can keep at least one connection availab=
le=20
for other non UP-to-UP capable ultrapeers, in addition to the 30 connecti=
ons=20
they allow from incoming leaf nodes.

There are other protocol specifications that allow reducing considerably =
the=20
bad effect of search broadcasts. Notably dynamic querying.=20


_______________________________________________
discuss mailing list
[email protected]
http://www.limewire.org/mailman/listinfo/discuss