RE: Re: Does the Push message still exist?

wwiltse25150 wrote:
> --- In [email protected], "Philippe Verdy" <verdy_p@...> wrote:
> > > 1. What port do I listen to so I might catch a UDP message? 
> > > Is it the same port I'm connected to other ultrapeers on via TCP?
> > 
> > Normally the same port.
> 
> So if I connect to multiple ultrapeers, should I create both 
> a TCP and a UDP socket for each one to handle the messaging? 
> I'm currently just connecting with a TCP socket. I realize 
> that UDP is not actually "connecting" but will need to create 
> a UDP object that listens on the same port as the TCP socket 
> I'm connected to the ultrapeer on.

No. If you already have a TCP session with a host, use that session to send
your message. You don't need the extra overhead of another socket, and of
the OOB header in the datagram, given that your session is already
negociated.

UDP will be used because it is faster (a single transit instead of several
roundtrips to open the TCP session, acknowledge it, negociate the TCP
window, and perform the initial connection query and negociate several
things before sending the message, and no need for the recipient to allocate
a new port when accepting the connection: the recipient just uses a single
port for the reception with UDP) and requires less bandwidth.

UDP will ba valuable if you need to maintain several active routes for
sending many messages. If your intent is to send messages to many hosts but
with little data to transmit to each one, establishing a full TCP session
will be too costly. Note that when you send a PUSH message, you have no
warranty that it will reach its receipient: it may already be offline, or
the route to it has been lost in the middle. sending PUSH messages via UDP
to the host nearest from the intended target that is likely to be
firewalled, you bypass the route, and you'll have more chance of reaching
the firewalled servent, if he's still connected, and you'll consume less
bandwidth in the global network. The PUSH message will reach the ultrapeer
faster, and that ultrapeer will just forward the message to the firewalled
servent, using its existing incoming TCP session from that firewalled
servent.

UDP messaging is also used as a way to bypass some firewalls for a good
reason: as it just uses a single port, and the firewalled servent is
actively sending its own data from the same port to other hosts, it is
actively "punching a hole" on the firewall to get through it. TCP cannot do
the same thing as easily because TCP sessions are dedicated only to a single
pair of hosts: itself (the firewalled leaf) and the ultrapeer to which it is
connected. A pair of TCP ports (one fixed: on the leaf to the firewalled,
one variable for each session: on the ultrapeers for each accepted session)
cannot be used to open a route in the firewall to soemthing else than
between the two already connected hosts.

That's why UDP is also used in an extension of OOB to support
firewall-to-firewall transfers within LimeWire's FW2FW extension. Just
consider the number of port allocations needed on each host. Even though the
UDP datagrams may have a cost due to the required minimum header to identify
a Gnutella service, this cost is minimized by the fact that no intermediate
host in the route and no router needs to manage the TCP session: UDP
datagrams are transmitted faster using only the IP address of the recipient,
with just IP routing tables and no need to manage session states. This has a
price: UDP messages, if they can't be delivered immediately, will buffer in
routers for very short time and will be dropped if there's not enough
bandwidth.

Also, UDP messages that are lost due to transmission errors are dropped but
there's no way in UDP itself to identify a lost datagram. This is not a
critical issue for a UDP datagram used to transport a PUSH message: send the
message wait for a few seconds to give enough time for the transmission and
for the remote host to receive it and handle it by opening a connection back
to you (But don't expect a negative acknowledge if the remote rejects your
request, it may be also offline, or it may be reaching something else than a
Gnutella servent).

Note that UDP messages should not be sent to servents running on low port
numbers (below 1024) without extreme caution. IF there's no reply after a
few seconds, you may retry it a couple of time, with an increased delay for
the expected connection back to occur, but don't insist too much: don't send
large volume of UDP datagrams to any host without having some confirmation
from it that it is accepting them. For this reason, the UDP datagram should
just contain a single PUSH message. FW2FW UDP messages are used in more bulk
form for larger volumes, but after you have negociated the transfer and made
sure that both hosts agree on the policy.

> > > 2. Is there any difference in the PUSH message structure sent vis 
> > > UDP? I'm just wondering if there will need to be any changes in
> > >  my code that increases the hops and decreases the TTL value.
> > 
> > Same structure, but there's an extra header in UDP datagrams to
> > indicate that they are transporting Gnutella protocol (because
> > there's no initial session)
> 
> Is this "extra header" or any other UDP protocol specifics 
> documented online? 

Look at OOB specs for the details of the minimum Gnutella header before the
normal Gnutella message in each UDP datagram.