RE: Re: PUSH packet !!

If you nezed to send a PUSH message to a host using a proxying connection to
reach the intended servent, it's because it's not reachable directly. Its IP
and port address (used by it to connect to some proxying servent that will
relay your PUSH message) have no usable values. They are local to the
connection used by the firewalled servent.

So it is normal that when the firewalled servent connects back to you, it
uses another IP and/or port (which may be different). The only way you can
recognize that firewalled servent in your incoming GIV connection is in the
few information available in its TCP connection handshaking headers that
include the GIV line (however, the data in the GIV request is not very
reliable, given that the file index and file name present in that request
are not very precise, and may not be encoded exactly like in your PUSH
message that you have sent.

Notably: the file index is very imprecise as it is a replica of the file
index found in the query hit for which you have sent a PUSH to download that
file. However, file indexes are limited, and PUSH messages may be sent to
request a connection back without needing it for a HTTP download but for
another connection type (in that case, the best you can do in your connect
back is to try finding a matching query hit associated to the host you want
to connect with you. 

And in Query hits, senders should still be able to assign at least a random
file index, if they can't compute a reliable file index. This way, a peer
like you that attempts to send a PUSH message will replicate that file index
in the PUSH message, and the firewalled servent will issue a connection back
with a GIV message using the same file index that you can recognize as it
matches the file index you used in your PUSH message.

The filename parameter is often useless, at least when the filename contains
non ASCII characters: some servents are encoding filenames in query hits
and/or in PUSH messages and/or GIV connection requests using their local
native encoding (LimeWire uses UTF-8, which is independent of the host local
native encoding).

I do think that GIV connection requests should better include the GUID of
the connecting peer (this can be done in handshake headers), and that PUSH
message should also contain the GUID of that firewalled peer. But all we
have is a query GUID in query hits, most of the time. I think that query
hits should then contain the GUID of the sender and not only the Query GUID
of the searcher, used to route back the query hits.

In other words, IP and port numbers only work in non-firewalled environments
that don't need any proxying. The identity of the sender AND recipient of
EVERY message sent to the Gnet should be revealed by their host GUID. This
is unfortunately a legacy heritage of the old Gnutella protocol, that did
not solve completely the addressability and identification of all hosts. We
should consider IP/port addresses only as connection-local and not
network-global, due to the increasing use of firewalls and/or NAT routers.

(Note that this is exactly what the Microsoft P2P protocol uses (as well as
other instant messaging protocols): it does not care much about the IP/port
which is not assumed to be network-global.

Things would be different if IPv6 was globally available as an alternative,
because IPv6 addresses may be assumed to be network global (an 128-bit IPv6
address acts like an 128-bit GUID but it is directly routable like IPv4
addresses, and it avoids using complex NAT translations for connection
sharing, as it contains two parts: a globally routable network address and a
locally assigned part to reach specific hosts in private networks and the
mapping between permanent local addresses and global temporary addresses
used on the Internet is MUCH simpler and can easily support changes of
internet connections, with a transparent reconfiguration without the need to
change any setting in the final local hosts).

> -----Message d'origine-----
> De : [email protected] [mailto:[email protected]] De la part
> de rakesh
> Envoyé : mercredi 13 juin 2007 10:00
> À : [email protected]
> Objet : RE: [the_gdf] Re: PUSH packet !!
> 
> Any comments ?
> 
> -R
> 
> rakesh <[email protected]> wrote:
> Thanks !!
> 
>  One more question - After sending PUSH packet, when firewalled peer
> connect back, its IP and Port are same as received in Query Hit packet or
> they are different?
> 
>   I am asking this because I have observed different IP, port. May be I am
> wrong!!
> 
>  -R
> 
>  Philippe Verdy <[email protected]> wrote:
> The file index is deprecated, as well as the name specified in the GIV
>   request as it's difficult to match it with a local file that the remote
> host
>   accepting this connection will request. The effective file will be
> specified
>   in the HTTP GET request by this host.
> 
>   Many servants don't care about this info. The only important thing that
> a
>   host (accepting a incoming TCP connection with a GIV request) need to
> check
>   is whever it has recently sent a PUSH message to a host for which he
> tried
>   to get a connection with.
> 
>   There are extensions of the Gnutella protocol that uses this connect
> back
>   mechanism by ignoring completely the data provided with the incoming GIV
>   request: it is used to establish a connection for something else than
> just a
>   Gnutella connection.
> 
>   Note that the reply to a incoming GIV request is either to reject it or
> to
>   close it (if no PUSH was initiated, or nothing is needed from that
> remote
>   host), or to initiate a Gnutella connection asif it was an outgoing TCP
>   connection.
> 
>   Note that if the PUSH message may be delivered through UDP, the GIV
> request
>   is implicitly sent only through TCP (there's still no connect back
> mechanism
>   that works through UDP, despite it could work as well, with a UDP-based
> GIV
>   message that would trigger the port forwarding from the firewalled
> servent,
>   without having this firewalled servent to establish a full TCP session).
> 
>   Such extension would be interesting with NAT routers that support port
>   triggering for defining a (temporary) routing from the Internet to the
>   firewalled servent, and this would not absolutely require using a proxy:
>   If you received a UDP-based GIV message from a host, it would just mean
> that
>   you are authorized to establish an outgoing connection to the source of
> that
>   UDP message, or to send it USP messages that will reach it directly.
> 
>   With such extension, you would not need ANY TCP connection to reach a
>   firewalled servent.
> 
>   But see also the "Firewall-to-Firewall" (FW2FW) protocol extension...
> 
>   Philippe.
> 
>   > -----Message d'origine-----
>   > De : [email protected] [mailto:[email protected]] De la
> part
>   > de rakesh
>   > Envoyé : lundi 4 juin 2007 07:57
>   > À : [email protected]
>   > Objet : RE: [the_gdf] Re: PUSH packet !!
>   >
>   > Thanks for detailed and very informative reply.
>   >
>   > Why do we need to send File Index in PUSH packet ? Because in any case
>   > requestor need to ask for a file ones a connection is established
> between
>   > a firewalled peer and requestor. It seems that file index is useless
> in
>   > PUSH packet.It gives  wrong impression to requestor that he  will get
> the
>   > file for that file  index ones firewalled servant connect back !!
>   >
>   > Am I correct ?
> 
> 
> 
> 
> 
>  ---------------------------------
>  Finding fabulous fares is fun.
>  Let Yahoo! FareChase search your favorite travel sites to find flight and
> hotel bargains.
> 
>  [Non-text portions of this message have been removed]
> 
> 
> 
> 
> 
> 
> ---------------------------------
> Looking for a deal? Find great prices on flights and hotels with Yahoo!
> FareChase.
> 
> [Non-text portions of this message have been removed]
> 
> 
> 
> 
> Yahoo! Groups Links
> 
> 
> 
> 
> --------------------------------------------------------------------------
> -------------
> Orange vous informe que cet  e-mail a ete controle par l'anti-virus mail.
> Aucun virus connu a ce jour par nos services n'a ete detecte.