[ENet-discuss] NAT hole punching with Enet - query on an approach

[M. Rijks]

Thank you all for your reactions, I'm now convinced I can send a UDP  
packet directly (not using ENet) to punch the NAT.

I really appreciate the feedback I'm receiving here, it has boosted  
the design stage. Now it's time to put it all together. :)

Thanks again!

Martin

>
> That is how we do it in Tonido (www.tonido.com) for NAT traversal.
>
> We have our own layer that does NAT punch so that ENet can establish  
>  connection. It uses the same UDP socket.
> We simply look at each packet(first couple of bytes) before handing   
> it over to ENet. It works pretty well.
>
> By the way, much thanks to ENet. Its a great library, considering   
> how much we have abused it. :-)
> It has withstood everything amazingly well.
>
> -Madhan
>
>
>
>
> ----- Original Message ----
> From: Daniel Aquino <mr.danielaquino at gmail.com>
> To: Discussion of the ENet library <enet-discuss at cubik.org>
> Sent: Monday, April 27, 2009 4:41:25 PM
> Subject: Re: [ENet-discuss] NAT hole punching with Enet - query on   
> an approach
>
> Are you saying that I could send/recieve my own type of data on the
> udp port even while enet is using it ?
>
> On Mon, Apr 27, 2009 at 11:38 PM, Lee Salzman <lsalzman1 at cox.net> wrote:
>> Almost anything that doesn't look ike a valid ENet packet will be ignored.
>>
>> Lee
>>
>> M. Rijks wrote:
>>>
>>> Thank you for your reaction Shawn.
>>>
>>> Yes, I considered sending around UDP packets before getting ENet in the
>>> equation. However, I have a timing issue there. After the game server has
>>> punched through towards the client IP+port, I need to find an appropriate
>>> time for the client to initiate the ENet connection on the other end. But I
>>> don't exactly know if, or when, the server's punch packet arrives at the
>>> client. I can't wait for its arrival since the client's firewall may block
>>> it entirely. So there is the risk that when I finally tell the client to
>>> initiate its connection to the server, it first receives the UDP   
>>> packet that
>>> was used to merely punch the server-end hole. It will most likely contain
>>> data that will make no sense to the client, throwing off ENet's connection
>>> protocol.
>>>
>>> Maybe I should change my question into "what kind of UDP packet content
>>> will ENet happily ignore when waiting for the connection to establish?" :)
>>>
>>> Cheers,
>>>
>>> Martin
>>>
>>
>> _______________________________________________
>> 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
>