Creating a Master Server
Author
Hi,
I'm currently trying to implement a Master Server. The low level stuff is already done, but now I don't know excatly how to proceed, but here's what I have currently in mind:
- When a new server starts, he sends a heart-beat udp packet to the master server. The master server now sends a packet to the server to see, if it's really availble. If the server replies, it is added to the list of available server. The master server only stores the address and the port of server. Now here's the first question: Is this enough? Should the master server store more informations about the server? What's a good heart-beat interval? And should I ack the udp pakets or can I ignore the fact, that a udp paket will get lost?
- Now, when the clients queries the master server, the master server replies with the list of all valid servers in it's database (it returns the address and the port). When the client recieves this list, he sends a query to all these servers in order to gain informations about them (current map, players, max players, ping, etc.). All the server, which reply, will be added to a list, where the player can choose a server.
Well, this is what I thought about it so far. Any other useful informations about this or something, that I should change?
Clients don't query individual servers, only master server.
While this puts more load on master, it's simply not viable, since clients have limited bandwidth (consider dial-up).
Single master can distribute all this much more efficiently, despite remote servers needing to update their information periodically, but that's not much of a problem.
Also, if you want to allow queries across the board, you might as well drop master server and go for P2P with "masters" being supernodes. In that model, every server is a master server. When they join any super node, they exchange their states.
Servers then propagate available states, but clients connect to any super node, and yet have (although slightly delayed) state of all servers available to them from single point.
But if you want to keep things simple, just have one server maintain entire state.
While this puts more load on master, it's simply not viable, since clients have limited bandwidth (consider dial-up).
Single master can distribute all this much more efficiently, despite remote servers needing to update their information periodically, but that's not much of a problem.
Also, if you want to allow queries across the board, you might as well drop master server and go for P2P with "masters" being supernodes. In that model, every server is a master server. When they join any super node, they exchange their states.
Servers then propagate available states, but clients connect to any super node, and yet have (although slightly delayed) state of all servers available to them from single point.
But if you want to keep things simple, just have one server maintain entire state.
Quote:. The master server only stores the address and the port of server. Now here's the first question: Is this enough?
That depends on what the servers are for. If this is a Counter-Strike style map game, where players want to browse servers by various criteria (# players, map played, geographic location, etc) then you need to store that on the master server, too. It's not realistic for each client to ask each real server about all that information, when it's much more efficient to let the master server do the selection for you.
If this is just part of a peer-to-peer network where all you need are a few other servers to talk to, then storing ip/port is sufficient.
You probably want to have the master server ask each server whether they're alive every 30 seconds or whatever, too. Or have the servers, while they're up, send packets to the master server. Either way, consider also updating the full/map/whatever information with each such update.
Some 'lobby' servers also divide up the servers that register with it by one or more subsetting criteria so that the entire list doesnt have to be sent to the client (who's request includes the criteria).
Compression of server list info would likely be useful (to cut bandwidth) if significant data is sent for each server (to the clients).
Quote:Original post by Antheus
Clients don't query individual servers, only master server.
While this puts more load on master, it's simply not viable, since clients have limited bandwidth (consider dial-up).
I disagree - look at any FPS client. They get a list of servers from the master, and then in order to sort the list by ping times, they have to query every individual server.
Most on-line games aren't designed for dial-up, but as usual, if dial-up support is in your specifications then take that into account (however, back when I played quake 1 on dial-up, the game-spy server list would still ping all of the servers! it only took a minute, or three...).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
