Game Server, Lobbies and Routers (Gateways)

Networking & Multiplayer
#1

I’ve coded a multiplayer ‘chat’ server as a precursor to writing a multiplayer game server. However I’m having some difficult design decisions.

  1. If the server has multiple network interfaces, how to find the one with the internet connection. Currently I’m opening a port on each one. Suspect that this will do.

  2. If the player is running the server behind a router, what is the best strategy to get port forwarding:
    a) Detect private IP range on each interface. If none of the ethernet adapters have a public IP, display a warning about requiring port forwarding.
    b) On each interface with a private IP range attempt to discover a Gateway using UPnP. When found, configure port forwarding. While there are libraries out there, they’re quite big. Also most DSL/Cable routers come with UPnP disabled for security reasons, so the effort might not be worth it.

  3. How do we determine the router WAN address & test that it works
    a) Load the server from an external webserver using webstart. Dynamically generate the JNLP, so as to be able to pass arguments to the code. Pass REMOTE_ADDR & HTTP_X_FORWARDED_FOR, to allow the server code to ascertain the WAN address, even through a Proxy (Assuming the proxy is well behaved). The server code then attempts to open a (client) port on the WAN address to see if it can connect to its server port. This last step will only work if the router supports Loopback (i.e. you can access the WAN ip from behind the router).
    b) As a), but to test the WAN IP, you access a port on the webserver, which has scripting to attempt to remotely access your server. This gets round the problem of testing whether port forwarding is set up on routers that don’t support Loopback. However it is more complicated. Are there any popular routers that are known not to do loopback, that make this worth the effort?
    c) If we are doing UPnP discovery, we get ask the router directly for the WAN address. We will need this to tell the players where to go, but there is no real need to check the port forwarding, since we’ve configured it ourselves using UPnP.
    d) We get the user to type in the WAN address. We then check access to it.

  4. How do we get the address of the server to the other players?
    a) Have a dedicated server that is at a known location. Probably too expensive.
    b) The first player starts the server manually, using webstart. The server contains an http server. It opens a browser window to that server using the WAN IP address. The loaded page tells the user to cut ‘n’ paste the URL & send it to his/her players. This only works if there is no router, or the router supports loopback. It is my favourite option though.
    c) As b), but the page is opened on the server using the local IP, which should always work. The page provides the URL to provide to the players in the text of the page.

  5. How do we get the server IP into the client?
    a) Each user has to type it in
    b) The client is webstarted from the http page started on the server. The server can customise the JNLP served to pass the server IP as an argument. The loaded code can be on an external webserver to avoid overloading the limited bandwidth on the user’s server & to avoid multiple copies of the game cluttering up webstart. This only works if the JNLP can be on a different server to the application. I think this is the case. The client code must be signed as it must access an IP address different from that of it’s source server.
    c) As b), but the main app is loaded from the game server. This part of the app contains the network code. The rest can be loaded as extensions from an external server.
    d) Webstart the entire client from the web page loaded from the game server.

So… there are loads of options. Ideally I want the whole thing to need minimal user knowledge to work. However I don’t want to generate reams and reams of code. i.e. what is the minimum of webserver PHP support? How much effort should be put into the server to help users with their routers - e.g. is the UPnP code worth the effort, considering that most routers have it switched off by default?

Your views welcomed

Alan

#2

Short of attempting to make a conenction on each to a well known reciever on the internet there is no way to tell. There is no difference between a LAN conenction and an Internet conenction to your computer. It all has to do with the routers that connection connects you to and who they connect to.

That COULD work, but its not absolutely gauranteed. The local LAN might not be configured with “illegal” internet IPs, even though it should.

UPnP is a security mess. I think anyone who knows anythign disables it. I also suspect may routers come with it disabled by default for these reasons.

Lobbying serves are generally set up with static IPs. If there is a firewall it is configured specifically t oallow connectios nto the lobby server. Besides solving your NAT problem, this also merans that your cleints can find your server. If you use dynamic IP then you are going to have to use a service like dyndns.org to allow users to find the server.

This is sort of the primary point of lobbying servers-- they provide a well-known palce on the internet for the players to conenc to and conenct up to each other.

Well if you configurd the router you shoudl knwo what that IP is. If its assigend via DHCP you sahoudl be able to query the router. BUT you cna also go to one of many “whats my IP” sites that well tell you what IP you are conencting with. ipchicken is one of many.

HOWEVER if you are being assigned an IP via DHCP there is no gaurantee that it wil lremain the same. Thsi is what servcies like dyndns are good for,. They allow you to map whatever your current IP is to a known site name. (eg foolobby.dyndns.org).

This all seems like WAY too much work. Again, if you are using DHCP dynamic IPs I recommend dyndns oir a simialr service. There is a little client (many actually) that you cna dowenlaod and install on your serve that will keep dyndns informed of what your current ip is.

Well known DNS name. See above.

nope. not really. Lost of cheap solutiosn to thids as logn as you have an always on conenction and machine.

DynDns is free.

See above. DNS lookup :slight_smile:

NMya dvice. A lot of your dieas are very clever and I slaute you for ingenuity but why reinivent the wheel?

The whoel point of a lobby server is that it solves all of this simply and elegently. It also allwos you to do UDP punch through, if you need that.

#3

@Jeff

Thanks for your thoughtful comments. I’ve printed them out for a more leisurely look.

A static IP or using DynDNS would make life much simpler. My router does support DynDNS so one possibility is to run a server behind my broadband connection. However if a full complement of players ran the game for more than about 4 hours a day, I might go over the bandwidth allocation. (The server uses N x the bandwidth of a player, where N is the number of players) Maybe I could be cleverer with the position updates & send them at a frequency linked to linear & angular velocity, so 4 hours is a worst case scenario. Also due to asymmetric bandwidth (256kbps upload) the server could only host around 10 players simultaneously. These limits are probably Ok provided the game isn’t too good and doesn’t do a lot of business (quite likely).

Renting a server is another possibility, but a bit over the top, unless the game is top notch. Maybe write the game as a servlet. This could spawn a thread to do the work, which stays alive, while the normal httpServelet thread(s) handles each incoming connection. (Could be wrong, not tried it). The load could be quite high during play, which might adversely effect other people on an affordable shared server. Dedicated servers look a bit too dear though. Hosting it myself is probably the better option.

So… to avoid the issues with the above, I was looking at how easy it would be to use player hosting. This has the advantage of scalability (any number of small concurrent games), but has the problems (as discussed above) of i) Dealing with NAT Routers and ii) Distributing the game server ip to the game client. These are real problems since most users give up as soon as anything ‘hard’ turns up.

I agree with you about UPnP security. Mine is turned off. Most routers come with it switched off these days. I figure that if the user is knowlegeable enough to configure the router to turn UPnP on then he/she probably knows enough to do the port forwarding. So scap that as an idea.

Your comment about the computer knowing where the router is, if it’s IP was provided by DHCP is one I hadn’t thought of, although I’m not sure that I can get at that information directly from java without native libraries (requires opening port below 1024). Worth a further look. However the user could be using static IPs (which as you say, might not be in the private range). There always seems to be exceptions which kinda sink clever ideas.

Sticking with my player run game server for the moment on the grounds of minimal cost (to me), I’ve added an http server to the game server. It needs more work, but will be able to report all the LAN addresses (if there is more then one) & if present the router WAN address (if this is passed as an argument by webstart). The user can then cut ‘n’ paste the relevant link and post it in a forum to allow players to join. I could choose not to display the LAN addresses to reduce confusion (if LAN play is not required). If the WAN address doesn’t match any of the LAN addresses, then instructions on implementing port forwarding are displayed. Fairly simple, particularly if the game server isn’t behind a router. I think it’s worth a try.

Best Regards
Alan

/Edit I’ve dug out Games Gems 5, to read the chapter on Punch-through. I’m a bit leary of it, but it would keep the server bandwidth down, solving my concern about hosting it on my connection.

#4

Okay, your problem here is that you are combining two seperable problems in your head-- dont!

You run the match making/lobby server but the hosting player runs the actual server for the game.

You match maker just serves to solve all the issues of how to find and hook up to games. Its basically a host registry.

Basically it looks like this:

(1) Host creates game session (launches server).
(2) Host connects to YORU sevre to register that he has a game accepting players.
(3) Players connect to YOUR server to find a game session to join.
(4) Your server gives the player the IP of the host.
(5) Player then connects to the hsot directly.

See?

Well you can handle this with UDP punch through. If you want to use TCP then its trickier and the host really needs to map a port on their router :confused:

My thoughts too.

You can and its easy. You just use the DNS name to open the socket, the java.net libraries do all the lookup for you :slight_smile:

good luck!

JK

#5

Jeff,

Thanks for your comments. Splitting the lobby server from the game server does help clarify things.

Alan

#6

Since most games on here are lucky to be played by one person at a time, let alone more then one, I’ve decided to concentrate on a single game environment, that people automatically join when they webstart the game. Since people can join or leave anytime, this either means a permament server or a fully peer-peer solution. Since the bandwidth associated with a dedicated server puts it out of the frame, it looks like peer-peer.

In peer-peer, each client sends/receives position data to all other clients. The required bandwidth grows with the square of the number of players, rather than linearly (as with server design) so the maximum number of players is more limited and dial-up play may not be a realistic proposition.

Since the game will often only have one player, there should be computer controlled enemies. Peer-peer means that they have to be controlled by one of the clients. My plan is for each client to spawn a small number of these. Thus the more players, the more enemies. Enemies can attack any player. If a player disconnects, his/her enemies will disappear (easier than trying to hand them over to another client).

When the game is webstarted, it will start sending a UDP packet to an Introducer at a known address at 1Hz. This will continue until the client is terminated. The packet will contain the game name (so future games can use the same Introducer), instance (future expansion for full lobby services) & a flag to indicate whether the client should be registered with the Introducer. The default action is to register the client. Each time the Introducer receives a packet, it will return a list of active clients (address & port) for the specifed game type. Any client which has not sent a packet to the introducer in the last 5 seconds is assumed to be disconnected & removed from the client list. I now have code which does this, although it is a bit buggy (received packet size is wrong!).

The initial test game will be a simple 3D FPS. The plan is to add network code at the start of the main game loop:

  1. Check to see if a packet has arrived from the Introducer. If it has, then update the list of active clients. Remove any orphan entities from the game.
  2. If it is more then a second since last sending a packet to the Introducer, then do so.
  3. Transmit state of all entities owned by this client to all other clients in the active client list.
  4. Process all packets arriving from other clients and create/update copies of the entities. This includes linear and angular position & linear velocity. Ignore any packets from other addresses. Remove any entities, no longer being position reported.
  5. Update positions of all entities using current velocity data.
  6. Update player position directly from player input.
  7. Do Collision detection between entities owned by this client, with all entities. Make appropriate adjustments to position, health, death etc. for directly owned entities only.
  8. Create new entities (projectiles, enemy spawning)

In practice, since the packets from the Introducer are coming in on the same port as those from the clients, they will be interleaved. This may or may not be a problem. Obviously the packet containing the updated client list could be saved in a temporary variable & processed one game loop later if necessary.

Thus if you fire on another player, then your client creates the bullet. The other player’s client receives bullet position updates, detects the collision and kills the other player. The problem is how to register the kill for scoring purposes. It looks like we need an additional message to be sent from the client detecting the kill, to the client deemed to have caused it.

We also need some way to identify players within the game, i.e. entry of a nickname. This could go in each peer-peer packet, but is a bit of an overhead. Maybe a seperate message at a lower rate, or let the Introducer handle it. A chat system is also needed, via another message, sent as required.

… so the concept is coming together, slowly. See any obvious flaws? This one will take a while :wink:

Alan

#7

Hi alan,

Not ignoring you but I gotta read this one when Im totally awake :slight_smile:

WIll read and consider soon, I rpomise.

JK