Re: [p2p-hackers] Re: Both ends behind NAT... (fwd from [email protected])

Eugen Leitl <[email protected]> Thu, 27 Nov 2003 11:17:14 +0100
Newsgroups gmane.comp.audio.speak-freely.general
Message-ID <[email protected]>
----- Forwarded message from "Sean R. Lynch" <[email protected]> -----

From: "Sean R. Lynch" <[email protected]>
Date: Wed, 26 Nov 2003 22:16:02 -0800
To: "Peer-to-peer development." <[email protected]>
Subject: Re: [p2p-hackers] Re: Both ends behind NAT...
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.6a) Gecko/20031103 Thunderbird/0.4a
Reply-To: "Peer-to-peer development." <[email protected]>

Paul Harrison wrote:
><evil>
>
>Suppose two NATed machines both want to communicate. Maybe there is a
>server coordinating things somewhere, maybe not.
>
>There are 65536 UDP ports. If machine A sends 256 UDP packets (each from a
>different port) to machine B, that means there will be 256 holes in his
>NAT that machine B could get a packet through. The NAT *must* allocate 256
>different ports: since each packet was sent to the same IP, the port
>number is the only way for the NAT to distinguish each possible reply.
>
>It will then take machine B about 256 tries to get a packet through to A
>(at which point a connection has been established). This is because each
>time B sends a packet it has about a 256/65536 = 1/256 chance of getting
>through.
>
>Some knowledge about how different NAT implementation work could speed
>this up, but even with no knowledge, 512 small packets is pretty
>reasonable.

Does anyone know of a NAT implementation that does *not* map UDP packets 
from the same source IP and port to the same source port on the NAT 
address? In this case, even if the firewall NATs you to a random port 
(that's the same for source IP/port pair regardless of dest IP/port), 
you could just send a packet to a host that both peers know about, and 
it can tell you which port each end is using.

One hitch I thought of in using p2p for my MMORPG engine: while all 
clients *have* to be able to reach the server, if they can't all reach 
*one another* there will be problems. However, I'm thinking in this case 
one can just fall back to routing updates for that client through the 
server. Since the server would need position updates anyway to determine 
which peers needed to talk to one another, all the clients have to do is 
tell the server "I can't see this peer" and the server will just copy 
messages to that peer.



_______________________________________________
p2p-hackers mailing list
[email protected]
http://zgp.org/mailman/listinfo/p2p-hackers
_______________________________________________
Here is a web page listing P2P Conferences:
http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences


----- End forwarded message -----
-- Eugen* Leitl <a href="http://leitl.org">leitl</a>
______________________________________________________________
ICBM: 48.07078, 11.61144            http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE
http://moleculardevices.org         http://nanomachines.net
signature.asc (application/pgp-signature, 198 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

iD8DBQE/xc8qdbAkQ4sp9r4RAmDYAKCM11IrBplVlRmX42HmS3Bouc2SgwCgk9gF
gyMpep8Q1jvbMsqcJ/r7XAo=
=rxo8
-----END PGP SIGNATURE-----