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

[Daniel Aquino]

Do you think you can provide your modifications to enet that show how
your reading your own data and then passing it off to enet ?

On Mon, Apr 27, 2009 at 7:48 PM, Madhan Kanagavel <madhan at yahoo.com> wrote:
>
> 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
>