OK, let's ignore symmetric NAT for now. In Raknet, they mention the success for the combination of various NATs: http://www.raknet.net/raknet/manual/natpunchthrough.html
What entries in this matrix would be working with your simple solution in the first thread? (just for the 9 combinations of Full cone NAT,Address-Restricted cone NAT and Port-Restricted cone NAT) You didn't mention STUN yet ((Simple Traversal of UDP through NATs), Why is STUN useful? http://sourceforge.net/projects/stun Thanks for your help, Erwin On 4 May 2013 10:25, Lee Salzman <[email protected]> wrote: > In terms of trading addresses, the third-party must not be behind a NAT, and > for that matter, it will see whatever global address is visible from the > outside. That is exactly the address that you need and that is what it > relays to both ends. Since ENet uses the same UDP socket for a given host, > this address is all you need to trade. > > For reference: > > http://nattest.net.in.tum.de/results.php > http://think-like-a-computer.com/2011/09/16/types-of-nat/ > > If it's symmetric NAT you're just screwed anyway. There's no real fool-proof > method of punching through symmetric NAT. Just have the user explicitly > forward ports on his router and leave it at that. You'll save yourself > endless hassle. > > Otherwise, simple punch-through schemes follow from the description of how > they work in that second link. Worst case requires sending some extra > spurious packets out on the UDP socket of the hosts, but otherwise is almost > as simple as the scenario I described in my first email. > > The third-party is going to be different in different use-cases. There > really is not going to be any one universal way to do it. > > If you have a game networking setup based on a client-server architecture, > then it is just more useful to completely ignore all this and have the user > explicitly open ports on his router, IMO. So long as the server has > forwarded ports, clients don't have to bother with any of this at all - they > just connect to the server, the end. > > > On 05/04/2013 07:51 PM, Erwin Coumans wrote: >>>> >>>> Set up a third-party ENet host C. Hosts A and B connect to C. C gives A >>>> the address of B. A directly connects to B. A and B disconnect from C. >> >> I doubt this will work. What kind of addresses and ports are >> exchanged? The global IP addresses is different from a local IP behind >> a firewall. >> >> If NAT punchthrough were that simple, why would people use Libjingle for >> it? >> >> http://maemo.org/development/documentation/manuals/3-x/howto_use_stun_bora/ >> >> >> It would be great if we can get a simple working sample source out of >> this tread, >> instead of long discussions how one could attempt to implement it. >> Thanks! >> Erwin >> >> >> >>>> There is no official sample, per se, but it perhaps bears repeating that >>>> a NAT punchthrough implementation is as simple as: >>>> Set up a third-party ENet host C. Hosts A and B connect to C. C gives A >>>> the address of B. A directly connects to B. A and B disconnect from C. >> >> >> On 05/04/2013 07:30 PM, Erwin Coumans wrote: >>> >>> Hi, >>> >>> I found many discussions on the topic but >>> no working sample code for NAT punchthrough with enet. >>> >>> Is there any self-contained sample source that works with enet? >>> Thanks, >>> Erwin >>> >>> >>> >>> _______________________________________________ >>> ENet-discuss mailing list >>> ENet-discuss at cubik.org >>> http://lists.cubik.org/mailman/listinfo/enet-discuss >> >> _______________________________________________ >> >> ENet-discuss mailing list >> [email protected] >> http://lists.cubik.org/mailman/listinfo/enet-discuss >> . >> > > _______________________________________________ > ENet-discuss mailing list > [email protected] > http://lists.cubik.org/mailman/listinfo/enet-discuss _______________________________________________ ENet-discuss mailing list [email protected] http://lists.cubik.org/mailman/listinfo/enet-discuss
