Thanks for your advices. I have made some coding and tried achiving a simple solution for my problem and so far it works, but I think its maybe not the best solution and has some shortcommings I just dont know yet. I tried it not with my game but as a short prototype and it seems to work.
Translated to my problem the solution would be: A webserver and a socket.io-Masterserver are given. Clients connect to webserver (not the masterserver) and can open new gamerooms. First n gamerooms are handled by socketServer1 with port p. After the limit n of this server is reached he sends a message to the masterserver which then opens a new socketServer2 with port p+1. All new gamerooms are now handled by socketServer2. When a client connects to a gameroom he connects to the socketserver wich handles this particular gameroom (and internally the specific socketio-room). Of course a socketServer has to message the masterserver when he has space again for new gamerooms and then the socketServer with the lower number would be prefered when creating new gamerooms. When a socketServer has no more clients he can be closed. What do you think of this solution? Its just a quick and dirty try without any real testing. I just open new socket servers with executing the commandline "node socketServer.js <port>" with the current port as <port>. I surely think that my solution has someting really bad in it which Im just not knowing of. But its quite simple and fits my problems. The different socket servers are completly seperated, just rarely communicating with the masterserver which itself doesnt even have a connection to the clients. Am Freitag, 11. Januar 2013 08:15:59 UTC+1 schrieb Brian Link: > > Not exactly the same scenario as you but we have a chat-based app that > also communicates 'mood' stats every 5 seconds as well as other > administrative messages. We had to build it robust enough to handle 3-5k > users chatting at a pretty high frequency so we definitely needed multiple > physical machines each with multiple processes. > > Our stack (which can handle the load very well) includes: > > - https://github.com/carlos8f/engine.oil > - https://github.com/amino/amino > - https://github.com/amino/amino-gateway > > I'm afraid theres not any existing documentation on how to set it all up, > but feel free to check it out. > > One of these days we'll start blogging about Amino and make some good > tutorials on how to put it to use :) > > P.S. We originally used socket.io with the redis-store .. but had HUGE > performance issues with the amount of cross-talk that the redis-store has > to do to keep all the servers in sync. This was a number of versions of > socket.io ago, so I'm not sure if our issues have been resolved or not. > > On Thursday, January 10, 2013 6:08:29 PM UTC-8, Charlie Edward wrote: >> >> Yeah, you are right, if you want to finish your thesis topic and learn >> something, starting from simple is a wise choice. >> You may consider pomelo when your project scale up. Hoping the pomelo >> example and tutorial can still inspire you. >> >> >> On Friday, January 11, 2013 12:51:15 AM UTC+8, DerDree wrote: >>> >>> Thanks for your suggestions. Sure I will give the framework a try but Im >>> quite forward with my game so I dont want to start at the beginning again, >>> so I need to figure out how to combine it with my actual version. >>> Also like I said it is possible that I want to make this project to my >>> thesis topic in university where own implementations and deep inside are >>> requested, so a ready to work framework may not be that good for it altough >>> it seems very appropiate. >>> >>> So I think next to trying the framework out I will still try to >>> implement a simple version of it by my own just to study it. When I fail >>> its not that bad because of the framework, but I think it can help a lot >>> learn some things for it. >>> >>> As to your statements to my thought of a simpler solution: >>> I am not that familiar with multiple socket.io processes, but Pomelo as >>> a framework states that the complex part is connecting the different >>> servers and that players on different servers can interact in an mmo for >>> example. In my game totally seperated processes would be okay, so that for >>> example gameroom 1 - 100 are processed by process1 and the next 100 by the >>> next process and so on. I thought that once the client is connected to the >>> right socketserver-process the connection always stays with this process >>> and there is no need for me to change a server for a client or to >>> communicate between these because my gamerooms are totaly seperated. So a >>> gameroom is using one socket-process and when the client connects to this >>> gameroom he connects to the same socket-process. I hoped that this would >>> need a single routing to the right process at the beginning and then the >>> connection to the right process would be established. >>> >>> But as I stated I am not that experienced with it. Maybe connecting to >>> the same process as the gameroom is is not that easy as it sounds first. >>> But if anyone has some good readings for this I would be very happy going a >>> bit deeper into this topic. >>> >>> >>> On Thursday, January 10, 2013 10:56:16 AM UTC+1, Charlie Edward wrote: >>>> >>>> Well, I do not think the simple version is as simple as you think. >>>> Game is more complex than web application in some aspects, you have to >>>> take >>>> care of a lot things, especially in multi-process environment. Servers >>>> communication, route, session management, broadcast, request/response, >>>> package parser, channel assignment, dynamic server extension, all these >>>> things will make your simple version game not simple at all, and error >>>> prone. >>>> >>>> Using a framework is a much more reasonable way, actually your >>>> requirement is really close to pomelo. Take a try, really less code, >>>> and >>>> much more scalable. Github: https://github.com/NetEase/pomelo >>>> >>>> On Thursday, January 10, 2013 5:02:26 PM UTC+8, DerDree wrote: >>>>> >>>>> Thank you both very much. That are two nice solutions for this kind of >>>>> problem. >>>>> >>>>> I studied the solutions and am I right that the main idea behind these >>>>> is to instantiate more processes for handling the websocket messages? >>>>> This >>>>> was also one of my ideas aboth. Altough I would like to try programming >>>>> it >>>>> by my own in a simpler version rather than using a full framework. The >>>>> main >>>>> functionality of my game is quite far in development and maybe I will use >>>>> this whole project for a thesis during my study. But these two projects >>>>> give a great inside in managing such thinks, that is very usefull. >>>>> >>>>> I also think that my particular game can work with a simpler solution >>>>> just now. I have completly seperated games (with each up to only 8 >>>>> players >>>>> max) and there is no need to communicate between the different games. So >>>>> I >>>>> think I just could try to open another process at a specific number of >>>>> games going on and then sending all new games to this new process until >>>>> the >>>>> first process is not anymore at the limit. I just hope that the number of >>>>> games a process can handle will be acceptable so that there doesnt need >>>>> to >>>>> be too much processes for a few games. >>>>> >>>>> But my concern would still be that, altough there are multiple >>>>> processes handling the messaging, it still would be only one machine. Are >>>>> there any studies on how many messages can be send in a second or half >>>>> using multiple processes on one machine? I could imagine at some point >>>>> the >>>>> machine reaches its maximum network load, making more processes useless. >>>>> Than this really would need some complexer solution where maybe these >>>>> frameworks would be really handy. >>>>> >>>> -- 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
