[ENet-discuss] ENet and NAT hole punching

[fuzzy spoon]

You could also add a small library such as miniupnpc alongside ENet.

On Fri, Jan 21, 2011 at 4:26 AM, Jay Sprenkle <jsprenkle at gmail.com> wrote:

> Thanks very much for the response.
> Why five packets? A few extra to insure delivery?
>
>
> On Thu, Jan 20, 2011 at 7:43 PM, Philip Bennefall <philip at blastbay.com>wrote:
>
>>  Hello there,
>>
>> In my implementation I simply open a UDP socket directly, send about 5
>> packets with a small interval between each, and close the socket again.
>> Then, ENet kicks in and attempts a connection. The ENet socket wrapper
>> functions are more convenient, but obviously the result will be exactly the
>> same so it just depends on your taste.
>>
>>
>> Kind regards,
>>
>> Philip Bennefall
>> ----- Original Message -----
>> *From:* Jay Sprenkle <jsprenkle at gmail.com>
>> *To:* Discussion of the ENet library <enet-discuss at cubik.org>
>> *Sent:* Friday, January 21, 2011 2:36 AM
>> *Subject:* [ENet-discuss] ENet and NAT hole punching
>>
>> Good evening,
>>
>> I'm interested in making my ENet powered application able to do NAT hole
>> punching.
>>
>> After looking through the NAT hole punching RFC it looks fairly simple
>> (section 2.3 here<http://pdos.csail.mit.edu/%7Ebaford/nat/draft-ford-natp2p-00.txt>
>> ).
>> What is needed is a way to send a single packet to a specific address and
>> port number.
>> The content of the packet isn't important since it will be discarded
>> anyway. It's just used to get the NAT to remember the address.
>>
>> If I read the source correctly I could simply open a connection and let it
>> fail.
>> Is there any way to send this packet without going through all the
>> overhead?
>>
>> Perhaps just call enet_socket_send() directly?
>>
>>
>
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20110121/2b69a7b2/attachment.html>