views:

57

answers:

2

Hi!

Been reading a bit about the subject, and out of curiosity, online games which maintain a "lobby" system that lists games;
How do they keep each client synchronized with the current games list state?

I'm talking in a "client asks for the games list update" terms and not in event driven terms (game's state changes and immediately broadcasts it <--- not scalable!).

Possible scenraio:
A server holds 5000 connections to online players.
It has a list of 1000 games.
A client asks for a games list update every one second.
Now the server needs to iterate through all the games list and compare the last update time of each particular game, then if it sees that the player's last update is older it will send an update.
This means that every one second it is going to have (5000 * 1000 = 5,000,000) iterations!

Is there any practical way to avoid it?
Did you do it already, and can share a tip with me?

I've been thinking about having a cache. What's your solution?

+1  A: 

You could invert the order: whenever your gamelist change you send all your clients an update.

If you want to save bandwidth you should create a small update packet, that contains just informations that differs from last update sent, with an int id for your games this will be easy.

Keep all the clients synched to the same lobby status, also because this is what you need to do.. why do you want to care about different timings when you are publishing a common list?

Jack
Correct yet the games' state is **constantly** changing. It's impractical. Besides, while a player is playing, and not viewing the lobby, he doesn't need any updates, thus sending him these updates is just a waste of resources.
Poni
Yes, of course you don't actually send game updates to players that are in game instead that in lobby. Why would playing users need it? If you need scalability you would also decouple things: having 1 server for lobby and other servers for games.
Jack
Also if state is constantly changing you don't need to send an update for every change. Just buffer them and send 1 packet per second for example.. bulk updates is also what you usually have on actual games
Jack
And what if the lobby and the game are in seperate windows where a player could simply a window? You know, like in all those board games, where you got the window of a lobby and several open game windows opened. Thought of that?
Poni
+1  A: 

First off, 5 million comparisons a second will not noticeably tax modern hardware. Let's assume a comparison takes 10 cycles on a 1 GHz Cpu. Then this would cause a CPU load of merly 5%. Of course one could easily optimize that, but we have more important things to do, don't we?

A much more likely bottleneck is network bandwidth. Do I really need to transfer data about 1000 games to each client every second? Let's assume 100 bytes data per game. This would equate to a bandwith of about 1MBit for each player.

Fortunately, the clients need not know about every game. A typical pattern would be that the user states which games he wants (for instance by game type), the client sends this filter to the server, and the server sends only the matching games.

meriton
Well, first assume that all the 1000 games are of the same type and the client wants them all listed and up to date. Secondly, after the first time a game is listed to the client, every update is just an "update", meaning only "volatile" information will be sent. Less bytes then. Thirdly, since the games list is protected by some sort of mutual exlusion mechanism (a semphore I'd say), there's a blocking activity which slows things down.
Poni
1) Why would the user want to see 1000 games? He is unlikely to read through a list this long. And the client doesn't need to load data the user doesn't want to see, right? 2) Granted. Shall we say 10 Bytes? With 5000 users in the lobby, your server still needs 500 MBit. That's much more costly than 5 million loop iterations a second. 3) It is quite possible to run the check whether something has changed in a lock-free manner. (In Java, one would declare the modification timestamp volatile for that).
meriton
You mean ~400kbit (10 * 5000 = 50,000 = 50kbyte). It still doesn't solve the iterations issue though..
Poni
My assumption was 10 bytes *per game* per user per update.
meriton