Master" server / Matchmaker question...
by Thomas Blom · in Torque Game Engine · 02/22/2006 (1:48 pm) · 2 replies
The master server (hereafter called "matchmaker") seems to require that it not exist on a local network with computers wishing to use it for arranged connections, unless ALL computers that will use it are on the same local network.
Is this true?
For example, if a server exists on the LAN with the matchmaker, when he connects to the matchmaker his *internal* LAN address (192.168 etc) will get registered with the matchmaker. If a client from outside of this LAN then contacts the matchmaker, he will be provided with this internal address, which cannot be reached from outside.
Similarly if the server is external, but the client is on a LAN with the matchmaker. In this case when the matchmaker contacts the server to make a connection request on behalf of the client, it will provide the clients *internal* address.
In both cases there is no way of knowing the external address as created by the NAT on the way out.
It would seem that since in each of these cases 1 of the parties should be able to successfully contact the other (the external address is valid), there *should* be a way for even this scenario to work.
But I wanted to verify my understanding of the code, which seems to be that a two-way handshake of "punch" packets is required to establish the connection...
thanks....
Is this true?
For example, if a server exists on the LAN with the matchmaker, when he connects to the matchmaker his *internal* LAN address (192.168 etc) will get registered with the matchmaker. If a client from outside of this LAN then contacts the matchmaker, he will be provided with this internal address, which cannot be reached from outside.
Similarly if the server is external, but the client is on a LAN with the matchmaker. In this case when the matchmaker contacts the server to make a connection request on behalf of the client, it will provide the clients *internal* address.
In both cases there is no way of knowing the external address as created by the NAT on the way out.
It would seem that since in each of these cases 1 of the parties should be able to successfully contact the other (the external address is valid), there *should* be a way for even this scenario to work.
But I wanted to verify my understanding of the code, which seems to be that a two-way handshake of "punch" packets is required to establish the connection...
thanks....
#2
After some experimenting, I can state more precisely when the issue I originally stated actually happens.
If you are on a typical home LAN and employ a router to share one "real" external IP address (that is held by your cable or dsl modem), the problem I stated can occur.
The issue is that the matchmaker and server both share the same real IP address, and packets sent from one to the other may never be assigned an external address by the router. An example follows.
To make the matchmaker visible to the internet, you setup NAT to forward requests on port 29001 (in our case, the matchmaker listen port) to some internal address where your matchmaker is.
So when a game-server, on that same LAN, sends a connect request to REAL ip address 123.123.123.123:29001, it gets forwarded to 192.168.1.103:29001 - great, that's what we want. The problem is that the IP address reported as sending this request is an internal one - the router presumably sees that the destination of the request is also internal, and thus needn't employ the typical NAT port-mapping technique - it simply forwards the request using the internal address. The following lines are log output from an actual session in which a client has connected to the matchmaker, and received the "connection accepted" rpc from the matchmaker with a list of possible addresses to contact the server at:
Will send punch packets to these possible addresses:
IP:192.168.1.1:2291
IP:192.168.1.1:2290
IP:192.168.1.103:2290
As you can see, it tries two addresses that are the supposed "external address", but this is really the internal gateway address. The third is the internal address of the server on the LAN. None of these addresses will work for a client that exists outside of this LAN.
This behavior may vary based on router NAT implementation: if the router had sent the game-server connect request to the matchmaker using a sender address of 123.123.123.123:, everything would be rosy;
To use the TNL matchmaking architecture as-is, the answer seems to be to obtain at least one additional static IP address.
Please let me know if you still think I am mistaken...
thanks again,
thomas blom in austin, tx
03/06/2006 (10:31 am)
Thanks for your response.After some experimenting, I can state more precisely when the issue I originally stated actually happens.
If you are on a typical home LAN and employ a router to share one "real" external IP address (that is held by your cable or dsl modem), the problem I stated can occur.
The issue is that the matchmaker and server both share the same real IP address, and packets sent from one to the other may never be assigned an external address by the router. An example follows.
To make the matchmaker visible to the internet, you setup NAT to forward requests on port 29001 (in our case, the matchmaker listen port) to some internal address where your matchmaker is.
So when a game-server, on that same LAN, sends a connect request to REAL ip address 123.123.123.123:29001, it gets forwarded to 192.168.1.103:29001 - great, that's what we want. The problem is that the IP address reported as sending this request is an internal one - the router presumably sees that the destination of the request is also internal, and thus needn't employ the typical NAT port-mapping technique - it simply forwards the request using the internal address. The following lines are log output from an actual session in which a client has connected to the matchmaker, and received the "connection accepted" rpc from the matchmaker with a list of possible addresses to contact the server at:
Will send punch packets to these possible addresses:
IP:192.168.1.1:2291
IP:192.168.1.1:2290
IP:192.168.1.103:2290
As you can see, it tries two addresses that are the supposed "external address", but this is really the internal gateway address. The third is the internal address of the server on the LAN. None of these addresses will work for a client that exists outside of this LAN.
This behavior may vary based on router NAT implementation: if the router had sent the game-server connect request to the matchmaker using a sender address of 123.123.123.123:
To use the TNL matchmaking architecture as-is, the answer seems to be to obtain at least one additional static IP address.
Please let me know if you still think I am mistaken...
thanks again,
thomas blom in austin, tx
Torque Owner Stefan Lundmark
As far as I know, it shouldn't.
No. The matchmaker will (or should) register the server with it's external address, unless the code supplied in TNL is very different from how the GG master server works.
Edit: Correction, TNL.. not TDN.