Can anyone offer any suggestions for setting up a very simple lobby server? (Documentation or some sample code) I was just hoping to find a very simple PHP script or something that would assist me in handling the backend matchmaking work.

I have written one in C# which lets you start and join games, and chat while you waint for the game to start. It's a bit overengineered for what you want, though, and I don't want to release it just yet anyway. But I might be able to answer questions about design or whatever.

Thanks. How do your clients find each other?

I'll be using VB/.Net on the clients... I have a hosted server and I was intending on using it to help each of my clients "discover" each other. After that, the server wouldn't really be involved. What I was hoping to find was an example script (Perl, PHP, whatever... just not ASP.NET) that I could run on my server.

barebones implementation:

1. Client1 connects to lobby server
2. Client1 tells lobby server he has started a game at this address and port
3. Lobby Server records this info.
4. Client1 disconnects from lobby server.
5. Client 2 connects to lobby server
6. Client 2 requests a game list
7. Lobby server sends Client 2 a game list (which includes Client1's info)
8. Client 1 disconnects from lobby server.
9. Client 2 connects directly to client 1.


This model has issures when it comes to clients behind NATs, and knowing when a game has crashed/ends.

We can fix the latter issue by adding some new steps.

1. Client1 connects to lobby server
2. Client1 tells lobby server he has started a game at this address and port
3. Lobby Server records this info.
4. Lobby Server sends Client1 a secret password.
5. Client1 disconnects from lobby server.
6. Client 2 connects to lobby server
7. Client 2 requests a game list
8. Lobby server sends Client 2 a game list (which includes Client1's info)
9. Client 1 disconnects from lobby server.
10. Client 2 connects directly to client 1.
11. Lobby Server sends client1 a keepalive request.
12. Client 1 responds to the server's keepalive request with the password.

(In a production environment you would want something more complex than a simple password. Public key authentication and a challenge algorithm would be important to avoid DOS attacks)

Now, dealing with nats is more difficult, because you have to do hole punching. The process will go like this:


1. Client1 connects to lobby server
2. Client1 tells lobby server he has started a game at this address and port
3. Lobby server checks to see what address Client 1 looks like he is coming from.
4. Lobby Server records the address info in a client table(including both internal and external ip/port).
5. Lobby Server records the game information in a game list table.
6. Client 2 connects to lobby server
7. Client 2 requests a game list
8. Lobby server sends Client 2 a game list
9. Client2 sends the server a game join request with his local ip address and port
10. Lobby server records this information (as well as the ip/port it looks like the client is coming from).
11. Client 2 begins to send messages to both the internal and extrnal address of client1
12. Lobby Server Sends client 2 a message with client1's address information
13. Client 1 starts sending packets to both of client 2's addresses
14. Eventually both clients will recieve a packet from the other client, they both continue to communicate over this port.
15. Client2 disconnects from server.


This allows for nat punchthrough, and knowledge of game servers being created/destroyed. It incurs the penalty of the gameservers having to maintain an open connection to the lobby server.

This works best if the lobby server connection is TCP. Nat stuff still has to be done through the same port the game is going to communicate UDP through, however (or else the address/port combinations will be wrong). So you will want to augment the simplified version above with the server giving the client an authentication cookie, and the client returning that cookie when he sends UDP requests to the lobby server (this assures that the UDP port is tied to the TCP port, and it's not just someone randomly sending stuff to the server)


But thats the gist of it.

The AP (who is not me, by the way) sets out the basic points really nicely. My implementation differs in that the clients remain connected to the lobby server while playing the game(s), and all their communication is passed through the server. This is suitable for 'minigames' (for example, my test game is a bridge game), allowing clients to be playing more than one game at once and avoiding any problems with NAT, but adding lag and bandwidth use on the server. This also lets you run serverside games, such as those that require persistent worlds.

So in answer to your question, clients find each other because they are both connected to the same lobby server at the same time. One of the events the server sends to clients is a list of clients currently connected.