   MMO Server Design - Brainstorming help needed!
  I have an idea for a MMO Server Design but wanted to get some thoughts on it before pushing forward with it.AS = Authentication ServerRS = Region ServerMS = Main ServerLBS = Load Balancing ServerC = ClientDiagram:_______________________________________________________________________________Ok So now that you have seen the diagram let me explain my idea.We have a single Load balancing Server that all the main servers connect to. The LBS keeps track of Which main server all of the region servers are connected to. When we bring a new main server online it connects as a client to the LBS where it is registered and is giving a unique ID.When bringing a new Region Server online it connects to the LBS as a client. The Region Server is registered with the LBS, giving a unique ID, and then told which main server to connect to. The region server then connects to the main server it was assigned to and disconnects from the LBS.When a client connects it first connects to the Authentication Server where the username and password are checked. If correct the client advances to the select character screen. From there the player can either select a character or create a new character. The Authentication Server handles both character selection and character creation. In the character database the ID of the region that the character is located on is stored. Upon selecting a character the authentication server obtains the region ID and connects to the LBS. The Authentication Server sends the region ID to the LBS which then sends the connection information for the region server and the main server back to the Authentication Server. The connection information is then relayed to the client and the client connects to the region and main servers and disconnects from the Authentication server.* Numbers in this next section are just example numbers that will need to be tested for best results.Each Region server can manage a set number of Players. Lets say the number is 200. Each main server can also only handle a certain number of connections lets say 1000. Each Main server can have a max of 20 region server connected to it at a time. So giving those numbers if a Main server had 20 region servers connected to it and each region server had it's full complement of 200 users that would be 4000 connections to the main server. This is where the LBS comes into play. Upon reaching it's full number of connections ( or a set threshold) the main server would send a message to the LBS requesting to have a region server moved to a new main server. The LBS would then select the main server with the least number of connections and send the connection information back to the main server that requested the move. The connection information would be relayed to the region server who would then connect to the new main server and disconnect from the old main server. The old main server would send all the clients who were connected to the region server the connection information for the new main server. The clients would connect to the new main server and disconnect from the old one. The old main server would also connect to the new main server long enough to send the user information for those players connected to the region server and then disconnect. At any one time a Client could be connected to 4 Region Servers and 4 Main Servers. As the player moves around regions are loaded and unloaded in a background thread giving the impression that everything is seamless.A Region represents a 100 square mile area. The Region Server and Main Server representing the current region the player is located in are the controlling servers. When standing in the corner of one region the client would be connected to 4 different region servers and depending on what main servers the regions are connected to up to 4 main servers as well.Ok so here is my design. Now some questions. Giving this setup what should the main servers be responsible for besides managing the region servers? I was thinking that communication should be done through the main server. Also should the main server manage the player data or should that be a job of the Region Server?Region Diagram:
  It sounds a bit like BigWorld. But it's also fairly pointless you throwing the numbers around unless you have something to back them up. There's little point designing an architecture for a problem you don't have, or one that only fixes part of your problem, after all. I would also say that it's fairly meaningless to talk about region servers and main servers when you've not decided on the relationship between them. Don't design an arbitrary chain of computers and then work out where to put the work - design a chain of work and decide which computers to put it on. Only then will you know what connections need to be made.   ;  do you already have working single server solution? if not first concentrate on it to attract enough people to load your server.as you already pointed yourself, your main server sounds like a bottleneck. alternative way is to connect clients directly to zones(regions in your terms) so you don't need to keep all these connections in main server. main server should manage only common data state that have to be synchronized between all zones, e.g. global chat or something else. the simplest possible case is to have single lobby/main server and many zone servers. you need huge userbase to have more then one main server in case it doesn't keep all client connections and is just a communication/synchronization center between regions.About seamless world: note that seamless world is quite complicated topic. if you already have working game logic you probably will have to make significant changes in your architecture/core implementation. If you don't have working game logic - read the first sentence of this post again :)  yeah, sounds fine to connect client to the zone it is located in and to those adjusted zones that client is approaching. in opposite case you can generate a lot of useless traffic. just don't hardcode zone size too deeply cos probably you'll need to adjust it to the number of clients. two alternative approaches:1) to have many small zones each one handled by separate process and possibly some of less loaded zones live on the same physical server. Seems to be a bit simpler to implement but can bring some important limitations in the future2) to have configurable zone size. so single zone will live on single server. you'll be able to reconfigure your cluster to have highly populated zones handling smaller world regionsalso virtual world depends on your cluster configuration. consider big city or dungeon with frequent massive battles that is crossed by zones borders. even if you carefully implement your seamlessness this can bring you performance problems.tbh there're few discussions of seamless world implementation on this forum, and in general on web, so I would highly appreciate if somebody post some interesting links or share his opinion   