Jump to content
  • Advertisement
Sign in to follow this  
elvman

Server communications

This topic is 3174 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I am planning to make a multi-node game server. But I can't actually figure out, how they communicate with each other. If one node is a login server and all other are seperate "shards" (or how do you call it), the haw do these shards know that user has logged in? One method would be to store the session in database, but I don't know if it is OK. And what if multiple nodes serve the same world, how do player positions etc. stay synced on all nodes?

Share this post


Link to post
Share on other sites
Advertisement
One way to do this is a "state node"

Example:
Login_Node , State_Node, Shard1_Node , Shard2_Node ....

Connection connects to login node....
Login_Node adds user updates State_Node to Connection State == Shard1_Node
Login_Node then forwards connection to the Shard1_Node.
Connection wants to go to Shard2_Node
Shard1_Node updates State_Node to Connection State == Shard2_Node
Shard1_node then forwards Connection to Shard2_Node

This is a very simple example but I hope it gets my point across. Also on more advanced things you can do.. Check the state see if Connection has admin access then process command if he does. And if he doesnt then kick him.. That kind of thing.
peace

Share this post


Link to post
Share on other sites
One common solution for making multi-node game servers communicate internally is to use a central server, often called a naming service or directory server. When a server process starts up, it connects to the naming service and sends its server type ("login", "shard", etc) as well as the port on which it listens for IPC connections. It then receives a list of all other servers in the cluster, their types, and their ports. Then, the naming service sends off messages to all nodes but the one that just connected, informing them of the new node. That way, all nodes are always aware of the existence of every other node. They can then open connections to one another and exchange information.

The primary benefit of the method I described above is that it requires no routing service. That is, there is no need for the naming service to route messages from node A to node B; it just gives the two nodes all the information they need to communicate among themselves. This makes the system rather robust, even when faced with a naming service crash, as the nodes will maintain an individual node cache.

A popular alternative to allowing direct connections from external clients to internal nodes, is to introduce a front-end or proxy server. The proxy acts as a bridge between the server farm and the internet, passing messages back and forth. The benefit of introducing a proxy is that it is rather easy to smoothly redirect clients from a crashed server to a newly started replacement. If the client were to connect directly to the internal nodes (a la RanBlade's suggestion), hiding crashes would be difficult, and the server farm would be much more exposed to malicious crackers trying to break in.

With all that said, I think you may want to reconsider whether you actually need to build a distributed, highly scalable and parallel server system. I'm assuming that you are working on an MMO. If so, how many players to you expect to host at any one time within the next few years? Be realistic. Probably not many enough to justify developing, testing and debugging such a notoriously complex system.

If I were to ask you right now what your main bottlenecks will be in the final server, what would you say? Sure, you could guess, but would you know? Probably not. Is it CPU or memory? Will you need multiple proxy servers or is one sufficient? How should you ideally split the server up - geographically (as in a few small areas per server) or in some other way? All of these questions can only be answered by someone who has actually built and tested a real MMO server, and measured the performance of the various components.

My point is that rather than taking on the huge task of building a multi-node game server, you may want to consider starting out small with a simple server that is designed such that it can be expanded upon (or indeed distributed) later, if the need arises. Otherwise you will spend so much time getting the server working that you will have no energy left to make a game at all.

EDIT: And if you, against all odds, do manage to produce a working server, you are likely to find that you solved the wrong problem (i.e., tried to fix what was never broken, because you didn't know what would be the real issue) and end up with a server that performs much worse than expected. Embrace the idea of YAGNI and KISS.

Share this post


Link to post
Share on other sites
There general question of "how does place A know that place B has authorized something" is usually solved through a Hashing Message Authentication Code (HMAC). Typically, the servers in this case share a known secret, and issue a token to the player when logging in, which consists of playerid,logintime,hash(secret,playerid,logintime). This means that any server can verify the token, and know that the playerid and logintime is legit.

There's more information in the Forum FAQ, as well as in a MMO thread in this forum from just a few days ago.

Share this post


Link to post
Share on other sites
Really big thanks for all of your replies!
Windryder, you encouraged me to continue working on my simple server and implement those multi-node things only when (and if) needed.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!