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" <[email protected]> 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 [email protected] http://lists.cubik.org/mailman/listinfo/enet-discuss _______________________________________________ ENet-discuss mailing list [email protected] http://lists.cubik.org/mailman/listinfo/enet-discuss
