Hello Guest

Multiplayer Networking

  • 0 Replies
  • 11830 Views
Multiplayer Networking
« on: July 11, 2005, 07:53:10 »
I'm considering trying a multiplayer game and am trying to figure out how to make the set-up user friendly.  It's going to be server based, rather than peer to peer, but I want people to host their own servers as the cost of hosting a dedicated server is way to much for a fun experiment in network coding.

Coded so far is a simple 'Chat' server.  The client connects to a port on the server using TCP/IP.  Data to the server is split at each carriage return and sent to all other currently connected clients.  The server socket processing uses NIO.  Writing to the clients also uses NIO, but effectively blocks if any of the client's aren't reading data fast enough.  i.e. the server slows down to match the slowest connection.

I reckon this (with a minor rewrite to support binary data) will do, provided the bandwidth is kept low.  Perhaps each client would transmit ident (1 byte), position (X,Y,Z two bytes each), rotation (X, Y, Z one byte each) and linear velocity (X, Y Z, one byte each) for the player & (say) up to 4 bullets at 10Hz.  This gives a bit rate of 13*8*5*10 = 5.2kbps.  For 5 players, the total client BW is 26kbps.  Hopefully this is low enough not to block.

The server could be a webstart application.  It needs to be signed as it has to open a server port.  The problem is how to reliably and easily give the a link for potential players to reach the server.  The client computer has an IP, but if the server is running behind a NAT router, it may be only reachable from the local LAN.  It would be nice to be able to determine the WAN side router address (if router present).  It seems to me that this has to be done using scripting on the external webserver.  One possibility is to use SSI to embed the client IP in a webpage.  I considered REMOTE_ADDR, but then realised that if the user's ISP uses proxies (mine does), then this would return the proxy IP rather than the user's router WAN IP.  Looks like I need to check HTTP_X_FORWARDED_FOR as well.  Maybe PHP should be used to customise the server's JNLP so that these IP's can be provided as arguments to the server code, which could then figure out the network configuration, inform the user to do port forwarding if required & provide a suitable link for posting as the game address.

The other issue is how to get that IP to each player easily.  The easiest way would be for the server owner to post an Http link on a Forum & for the players to follow it.  The link must therefore contain the IP of the server.  Two possibilities come to mind.  Either i) the game server code could contain a small webserver & the link could reference that, or ii) The link could go to my external webserver, with the user's server IP as a parameter in the URL.  Some scripting would be required in the latter case to provide a link to the game server.

Lastly the client code should be webstartable.  The question is how to pass the server IP to the client code.  One possibility is to serve the client application directly from the server via a small http server.  This way, the client already knows where the server is.  Furthermore, the client would not have to be signed (unless LWJGL is used).  However the client would need to be small, to avoid clogging up the server upload bandwidth.  Maybe only put the main code on the server & provide the rest as extensions from an external website.  An alternative is to sign the client code, which can then be loaded from the external website.  However the server IP needs to be provided as an argument.  Looks like PHP again to create the JNLP on the fly.

It all looks rather complex.  Maybe I've missed a trick somewhere.  The objective is to minimise the amount of knowledge required by the users in setting up the server and initialising the clients.

Got to stop (about time I hear u say) & go to work, I'm late...

Alan

/Edit It also occured to me that one could check the address range of the computer running the server, and if it is in the private range, then attempt to find and configure the router using UPnP (if available).. Worth a thought anyway.

/Edit2 UPnP is disabled by default  on my router (pretty sensible really, so I suspect that's generally true), so it doesn't really work as easy (for the user that is) configuration option.. Not sure it's worth the bother.
ime flies like a bird. Fruit flies like a banana.