[Twisted-Python] Operating on metainformation in a distributed system

[Krysk]

>Hi Krysk
>
>I had similar design constraints when wanting to match up to four human 
>players or computer players playing a card game. In the first monolithic 
>approach I got a better feeling for how long match making actually 
>takes, today we're seeing seldom more than ten tables being in the match 
>make process, while there are up to two thousand user playing cards. The 
>matchmaking for the game isn't the fun part, so users do away with it 
>pretty fast.
>
>After observing user behavior for more than a year, I spread out the 
>game logic to separate game servers with a central matchmaking process, 
>maintaining all the metadata, doing the load balancing for the game 
>servers and handling the broadcasting of status and activity information 
>to players. Metadata stored and passed around is the usual stuff like 
>game skill level, likeability, friends, blocked users, number of games 
>played, and some. The data is kept in a MySQL DB, is fetched at log in 
>and passed around with the player instance.
>
>This scheme so far balances very well and in case of needing to handle a 
>lot more users, I would separate the matchmaking process to a dedicated 
>machine.
>
>The whole setup for more than 50k games played to the end per day (about 
>13mins average play time per game) is handled by an 8 core single 
>processor machine with 24GB of RAM, usually we do not run more than 5-6 
>game logic server processes. The machine is well balanced, extremely 
>stable, no runaway situation was observed since deploying the system two 
>years ago.
>
>The bottleneck I foresee in our case is the 100MB/s connection we have 
>at the hosting center, currently we are only allowed one interface.
>
>For me dodging the sharing of metadata for the matchmaking was crucial, 
>I didn't fear the sharing so much as the latency induced by sharing 
>metadata among processes or machines, because the added latency adds a 
>lot more incongruous stuff happening to the user's experiences. Match 
>making on screen with manually selecting partners puts quite a strain on 
>the imagination of the average user, with added latency to clicks and 
>and answers, the users shy away from match making and start playing 
>alone or with the much easier selectable computer players.
>
>HTH, Werner

That sounds similar to the approach I was planning on taking. That
does leave the question of how do you manage events? For instance,
when the central server figures out an appropriate match, how do you
pass the relevant data about the match (players, etc) to the game
server that's going to run it?

I imagine you either put that data in MySQL and have all servers poll
it periodically, or you have some kind of direct notification system
that are servers are listening to. Can you clarify?

Thanks,
Krysk