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<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:nodejs@googlegroups.**com <[email protected]>> >> >> To unsubscribe from this group, send email to >> >> nodejs+unsubscribe@**googlegroups.com<nodejs%[email protected]> >> >> <mailto:nodejs%2Bunsubscribe@**googlegroups.com<nodejs%[email protected]> >> > >> >> For more options, visit this group at >> >> http://groups.google.com/**group/nodejs?hl=en?hl=en<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<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 >> nodejs+unsubscribe@**googlegroups.com<nodejs%[email protected]> >> For more options, visit this group at >> http://groups.google.com/**group/nodejs?hl=en?hl=en<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<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 > nodejs+unsubscribe@**googlegroups.com<nodejs%[email protected]> > For more options, visit this group at > http://groups.google.com/**group/nodejs?hl=en?hl=en<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
