RE: Re: Ultrapper to Ultrapper Protocol

Ne thing should be noted: when an Ultrapeer initiates a request to the
network, not acting as a proxy for its connected leaf, it behaves much like
in the old legacy Gnutella protocol, when there was no lyering distinction
between Ultrapeers and Leaves.
In other words, they have much more freedom for talking the way they want.
The requirement for Ultrapeers is to offer a shielding for the leaves it
accepts to serve, by implementing at least the QRP protocol between the
leaves and itself.

Implementing the QRP protocol between two ultrapeers has some other
requirements, because it must combine/merge its own QRP table with the QRP
tables coming from its locally incoming leaves. This is the tricky part, but
QRP routing is optional between Ultrapeers (it is mandatory for routing the
incoming search requests to the Leaves, by filtering these requests
according to the QRP table for each connected leaf), although it is now
highly recommended.

But beside this, the protocol is exactly the same, as well as the usage
policy. The policy is more complex to compute in ultrapeers because it will
have more connections to manage (about 30 to 60 incoming leaf nodes, and 3
to 5 incoming or outgoing connections to other Ultrapeers).

Note that an Ultrapeer cannot normally perform a connection request directly
to a remote peer acting as a Leaf node. When an Ultrapeer connects to
another peer, it does not know immediately that it is another Ultrapeer, but
if the connection succeeds, the remote is not a Leaf node (because by
definition, a peer acting as a Leaf node will not accept and will reject all
directly incoming connections but will guide the Ultrapeer to other possible
Ultrapeers).

There are however some tricky cases: even if a leaf node is not accepting
incomoing connections, it may still accept to honir incoming requests coming
from other foreign peers than just the few Ultrapeers with which the leaf
already has an established outgoing connection. This is the case for example
for requests routed via UDP without being proxied by Ultrapeers, and this
will work if the leaf node is not firewalled, or its firewall supports
dynamic routing of UDP messages through port punching (by the firewalled
Leaf node, that are maintaining some minimum traffic).

This allows for example the FW2FW protocol (that allows bypassing some
firewall limitations, in hosts that are NOT protected by true firewall but
only by routers implementing NAT+PAT for connection sharing within a private
locale network) to work directly between two leaf nodes, even though a leaf
node cannot normally connect directly to another leaf node without the help
of its already connected Ultrapeers.

Note also that when a peer is acting as a leaf node, it does not necessarily
mean that it is firewalled and will reject all incoming connections. It's
just that he currently does not run as an ultrapeer because it still does
not honor some other conditions for becoming an Ultrapeer. The distinction
between leaf nodes and ultrapeer nodes is not about their firewall status,
but about the support by ultrapeers of incoming QRP tables from leaf nodes,
and honoring by the Ultrapeer the filtering of incoming requests coming from
everywhere before proxying them to its leaf nodes.

The leaf of Ultrapeer status is also not assigned to the nodes, but to each
established link: when a link is shieldedwith the QRP protocol, there's a
leaf side and an Ultrapeer side for that link, and the link side is not
necessarily terminal (even though it looks like it is terminal for the rest
of the world that can reach the Ultrapeer). So a peer may act as a leaf node
on some links initiated by itself to other peers, and act as an Ultrapeer
for some other links.

This dual status, depending of who the peer is talking to (a sort of
"schizophrenic" behaviour) may be:
* a transitory status when a peer changes from a Leaf-only mode and becomes
eligible to acting as an Ultrapeer : it does not necessarily needs to close
other existing connections to other ultrapeers, but may need to transform
its existing QRP table it has given to other Ultrapeers, using merged QRP
tables with incoming QRP tables from other Leaf nodes, and then sending
patches each time the local peer (now also an Ultrapeer) accepts incoming
connections from other leaf nodes.
* but this may also be the result of the local topology of an Ultrapeer that
is acting as a proxying agent for all other nodes with which it shares its
connection to the Internet in a private network: this proxying status is not
visible to the outside world and may require adjustment, by the Ultrapeer,
of the TTL distance of messages from the outside Internet world routed by
the Ultrapeer. From the outside view, these shielded leaf nodes in the
private network are not visible, the world sees this dual-acting peer as if
it was a single peer acting as a leaf node (even though is acts as an
Ultrapeer for the leaf nodes connected to it from the local private
network)...In such topology, the Ultrapeer will often need to become a full
proxy not only for Gnutella connections and messaging, but also for HTTP
transfers.

Supporting this dual "schizophrenic" mode does not change the protocol or
its policy. This is a local only policy, invisible from the outside. It just
needs to be consistent during the time, over each connection, instead of
just for all the connections of the local peer: the local-only
"schizophrenic" behaviour will be invisible from other peers in the global
network, and without consequences in the policy applied by them.

> -----Message d'origine-----
> De : [email protected] [mailto:[email protected]] De la part
> de [email protected]
> Envoyé : mercredi 26 septembre 2007 13:23
> À : [email protected]
> Objet : [the_gdf] Re: Ultrapper to Ultrapper Protocol
> 
> Quoting Tehsin azmi <[email protected]> from ml.gnutella.dev-forum:
> :Where can I find, Gnutella Ultrapper to Ultrapeer protocol specification?
> 
> What do you mean, Ultrapeer to Ultrapeer?  The protocol is the same
> between Ultrapeers and between Leaves and Ultrapeers.  The nature and
> semantics of the messages can vary of course (e.g. QRP routing means
> something different between Ultrapeers and between a Leaf and its
> Ultrapeer).