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