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

[M. Rijks]

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


Quoting Shawn Yarbrough <shawnyar217 at yahoo.com>:

>
> You possibly might want to do your hole-punching with plain UDP   
> packets before you bring ENet into the connection. Because UDP has   
> no strict notion of a connection, you can send UDP packets one at a   
> time in whichever direction(s) you need to accomplish the hole punch.
>
> Then set up an ENet connection from client to server over the same   
> UDP port numbers. The firewalls involved won't know the difference   
> between the original UDP packets and the later ENet packets.
>
> Note I have not done this but I do know it is how UDP is supposed to work.
>
>
>
> On Apr 27, 2009, at 4:34 AM, "M. Rijks" <enet at forge.dds.nl> wrote:
>
> Hi all,
>
> Another query I would appreciate your advice on. I'll be a bit   
> lengthy to paint the whole picture, apologies for the bloat. :)
>
> To allow player-hosted servers and clients to connect to each other,  
>  I'm trying to design a hole punching technique that should help  
> both  peers to traverse firewalls and NATs. This is how I currently  
> plan it:
>
> 1. Both the client and the game server connect to a public service   
> (which I call the lobby server). Since most firewalls allow packets   
> going out to a peer to be returned from that peer, this initial   
> connection should pose little problem.
> 2. The game server then notifies the lobby server that it is opening  
>  up a session.
> 3. The client asks for a list of sessions from the lobby server.
> 4. The lobby server returns the public IP and port of each connected  
>  game server.
> 5. The client selects the session it wishes to join from the list.
>
> The trouble is where the remote firewall only accepts incoming   
> connections on that port when an outgoing connection to the client   
> peer was already sent. To battle this:
>
> 6. The client sends a message to the lobby server, telling it which   
> session it is trying to join.
> 7. The lobby server gives the public IP+port of the client to the   
> game server and tells it to fire a connection attempt to that the   
> client
> 8. The client ultimately connects to the game server directly. Since  
>  the game server made the first attempt to connect, it should have  
> no  problem to respond.
>
> This is where my query comes in. I only use the game server's   
> connect attempt towards the client to punch the hole - as soon as a   
> (or ANY) packet is sent through the port, the connect attempt may   
> immediately be dropped. Naturally, should the packet be received on   
> the client it should, too, be dropped - I want the client to connect  
>  to the game server and not vice versa.
>
> So what happens if client and game server simultaneously try to   
> connect to each other? Can a connect attempt be immediately dropped   
> at the game server? Can the incoming request at the client end, if   
> any, be ignored? Or will I get into some sort of communication mayhem?
>
> Thanks in advance for any response!
>
> 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
>