RE: Re: Question regarding how 2 hosts transfer files if they are both behind a firewallDate: Tue, 1 Jul 2008 08:06:33 +0000 (UTC)

 

> -----Message d'origine-----
> De : [email protected] [mailto:[email protected]] 
> De la part de [email protected]
> Envoyé : mardi 1 juillet 2008 10:07
> À : [email protected]
> Objet : [the_gdf] Re: Question regarding how 2 hosts transfer 
> files if they are both behind a firewallDate: Tue, 1 Jul 2008 
> 08:06:33 +0000 (UTC)
> 
> 
> Quoting david_chen100 <[email protected]> from 
> ml.gnutella.dev-forum:
> :The documentation says that if the servent that contains the 
> file to :be transferred is behind a firewall, it can PUSH the 
> file to its :counterparty (who is receiving the file) via GIV in HTTP.
> :
> :However, what happens when both hosts are behind firewalls? 
> How does :the file transfer happen in this case?  
> 
> If both hosts are behind firewalls, then it is not possible 
> for them to exchange files through TCP/IP.

Not exactly: it's not possible through TCP but possible through UDP that
does not require the allocation of a port number to the incoming connection.
For this to work the firewall must just allow a technic called "port
punching" for UDP: the recipient that wants to accept traffic from a UDP
port just has to push some UDP datagram throuh it, in orer to have the
firewall accept and direct incoming datagram coming to this same port to
reach the intended recipient.

That's the basic of how the FW2FW sub-protocol in LimeWire works: it
reimplements TCP over UDP, using a single port number, to allow incoming
Gnutella-formatted traffic encapsulating a TCP emulation.

This does not solve all firewall issues, but at least, if you're able to
send traffic to the network via UDP and recieve just one reply from it, it
will work.

The FW2FW subprotocol allows transporting anything that a TCP connection
would transport, so it can be used as well to maintain sessions, including
file transfers and chat. You may think that the extra layer of encapsulation
slows down the traffic: it's true in theory, nut not in practice.

Note that some parts of the TCP protocol, that is used to autodetect the IP
MTU and avoid or autocorrect data fragmentation through negociation may not
work with FW2FW with just a basic emulation of it in an encapsulation. This
must be handled by the encapsulator itself detecting it internally from the
incoming datagrams, and inorming the upper layer of the TCP emulation about
the corrected MTU size. That's the complex issue to solve (otherwise you
will suffer from poor performance.