[ENet-discuss] NAT punchthrough sample source code (yet again)?

[Erwin Coumans]

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 <lsalzman at gmail.com> 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
>> ENet-discuss at cubik.org
>> http://lists.cubik.org/mailman/listinfo/enet-discuss
>> .
>>
>
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss