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-----