Your requirement to be able and spin up more servers of the same "game" requires a lot of sharing between each of these servers, because they need (eventually) to be in the same state. The only advantage of this over having a single server for each "game" is that you load balance incoming traffic and concurrent connections, but introduce connections/traffic between the servers. Then even more problems arise when a 3rd server comes in, and every action means notifying also the other two servers.

Even if you implement this, i dont think it will be sustainable, as you can imagine. Maybe we have to redesign how we think about MMO servers. Just a quick idea: Only one server handles a specific area/city (literally) of the game. So you limit the shared state, and can still scale to many machines.

You also have to classify your data.
Eg in-game messaging system can be in some db that each server asks when player visits mailbox. (no need to IPC since it is not a "realtime" message. But player location has to be the same on all servers every moment, so movement messages must be sent out straight away (no db).

Good luck with your project ;)

danmilon.

On 07/05/2012 11:21 AM, hd nguyen wrote:
It's right Charles.

And I also understand you and Dominic's idea, I just want to find a tool/module that supports replicating game state between different servers.

If such a tool exists, it's very helpful to us than starting from scratch :)

On Thu, Jul 5, 2012 at 3:07 PM, Charles Care <c.p.c...@gmail.com <mailto:c.p.c...@gmail.com>> wrote:

    I think you're asking about two things: load balancing and
    replication of state between instance. These are separate problems.

    Nginx and http proxy will help you with load balancing and the
    configuration of sticky sessions etc. This allows you to
    horizontally scale your front-end servers.

    However, replication of state between your application servers,
    that's more tricky. You need to think about what state needs
    replicating, how often, and what happens if the system has a
    temporary network split. As Dominic says above, a lot of these
    problems become easier if you can architect your system to support
    eventual consistency (i.e. not every server will always be exactly
    the same, but that they will converge on the same state). Ideally
    your nodes should be able to deal with events arriving out of order.

    In order to share this state, you'll need to open a communication
    channel between the two node.js processes (raw TCP might be
    enough, personally I would use Zeromq, but that's an
    implementation detail)

    USER1 -----> GAME1 <-----> GAME2 <----- USER2

    Hope that helps,

    Charles


    On 5 July 2012 08:53, hd nguyen <nguyenhd2...@gmail.com
    <mailto:nguyenhd2...@gmail.com>> wrote:

        I think it turns out too detail when discussing about
        code/business processing here.


        To imagine easier, please look at below diagram:

        As you can see, we have 2 users access to the same game hosted
        in 2 nodejs servers. Client communicates to server through web
        socket protocol, example user1 joins game and stick with
        server1, user2 joins and stick with server2, of course through
        proxy server as load balancer. 2 users on the same scene of
        game, assume user1 attacks user2, so user2 must see user1's
        action and vice versa.

        So nginx or node http proxy can help us on this situation
        transparently with as less effort as possible? Or any
        different solution to get over it?



-- Job Board: http://jobs.nodejs.org/
    Posting guidelines:
    https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    <mailto:nodejs@googlegroups.com>
    To unsubscribe from this group, send email to
    nodejs+unsubscr...@googlegroups.com
    <mailto:nodejs%2bunsubscr...@googlegroups.com>
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en




--
Nguyen Hai Duy
Mobile : 0914 72 1900
Yahoo: nguyenhd_lucky
--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en


--
Job Board: http://jobs.nodejs.org/
Posting guidelines: 
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Reply via email to