Game Matchmaking on a LAN

If you're writing a networked game, you are probably asking yourself: "How can a new client on the network find the server or servers that are currently hosting games on the local area network?."

The Short Answer

Use a pre-canned library, such as MDNS (Open Source from Apple, used for the ITunes service, among other things).

The Long Answer

The long answer is: You want to use UDP broadcasts on a known port. Let's say you're using port 7848. Further, decide on two magic cookies -- say, the value 9292929 as a 32-bit integer, and the value 2929292. Call the first one "solicit" and the second one "answer".

On the server hosting the game, while it is soliciting new clients, it should listen for broadcasts on port 7848. Any datagram that arrives on that port should be checked for whether the first 4 bytes is the solicit magic cookie. If it is, the server responds by broadcasting a packet on port 7848 which starts with the "answer" magic cookie, and is followed by information about the specific game (map type, server version, number of players, what have you).

On a client browsing for games, it should initially send a broadcast packet on port 7848 with the "solicit" magic cookie as the first 4 bytes. Further, the client should listen for any packet arriving on port 7848, and if that packet starts with the "answer" magic cookie, it should add that server/game to its list of servers/games, or update its entry if it already has it. If the packet starts with the "solicit" magic cookie, and does not originate from the current system, and does not originate from another client that the client has heard about already, then the client should increase the count of known clients on the network.

After starting up, the client should keep sending "solicit" messages every min(1+N+M, 10) seconds, where N is the number of game servers that it currently knows about and M is the number of other clients that it currently knows about.

Even though UDP is lossy and COULD be lost in transit, this system will heal itself, for two reasons:

The client will re-transmit more frequently if it knows of no servers on the local LAN. Even if the current client is waiting to re-transmit a broadcast, another client is likely to broadcast, and the response to that broadcast will show up at the current client.


The magic cookies for soliciting and answering are chosen semi-randomly, to filter out possible broadcast traffic on the same port used by some other, previously unknown application using the same port as you. The timeout between re-solicitation is increasing, in order to spare the network from unnecessary broadcast traffic. More clients and more available servers means more broadcast packets that give data to the clients wanting a server listing, anyway. For a single server and a few clients on a corporate LAN, increasing the time with the number of clients and servers will not give much of an advantage, but if you're trying to host your game at a large LAN party, with multiple hosts and multiple clients per host, it will start to matter. If you think the response time for finding games is too sluggish, feel free to halve the timeout time between successive solicitations.