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
