hi, I've been doing quite a bit of research into this area recently. there is a lot of interesting stuff, I have a blog post that summarizes some approaches and links to some papers http://dominictarr.com/post/25083602144/distributed-programming-is-easy
eventual consistency is not actually that difficult to achieve, requires rethinking everything. I've got a project for replicating realtime data between servers, https://github.com/dominictarr/crdt it has a trello like example, that replicates some lists between multiple clients. I'm not sure if it's assumptions meet your use-case, and I agree with dan that you will probably need to partition your game world. but it may be helpful, or be a useful in your research, because you are really getting into cutting edge territory! cheers, Dominic On Thu, Jul 5, 2012 at 8:52 PM, hd nguyen <[email protected]> wrote: > Thanks Dan, > > Separating each game on a server is good idea, but when the number of users > for that game is big enough, that exceeds server processing ability, so we > need to scale out (cannot scale up now, it reaches the limitation of > physical machine), and we turn back to initial problem, how to maintain the > same game state between different users, right? > > And as you said, broadcasting between many servers is a costly task indeed. > > Initially the No. of users of a game is not too big, but we want to think > more far away for future, maybe we cannot figure out any solution > properly(no such of tool to make it easier) :(, but personally, I > appreciate your solution a lot, Dan :) > > On Thu, Jul 5, 2012 at 3:29 PM, Dan Milon <[email protected]> wrote: >> >> 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 <[email protected] >>> <mailto:[email protected]>> 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 <[email protected] >>> <mailto:[email protected]>> 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 [email protected] >>> <mailto:[email protected]> >>> >>> To unsubscribe from this group, send email to >>> [email protected] >>> <mailto:nodejs%[email protected]> >>> >>> 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 [email protected] >>> To unsubscribe from this group, send email to >>> [email protected] >>> 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 [email protected] >> To unsubscribe from this group, send email to >> [email protected] >> 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 [email protected] > To unsubscribe from this group, send email to > [email protected] > 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
