Request: Rearchitecture

[GoogleCodeExporter]

A speculative change request.  No doubt requires a lot of planning.  In 
essence, this change is about turning Paradice into a scalable and robust 
system for hosting MMO online games.  And Paradice9 itself.

Rationale: This entire changeset was borne of thoughts I was having while 
hiking in Switzerland:

If the server crashes, it is nearly always something to do with the GUI.  Like 
it or not, GUIs tend to be less stable than any other component (quite possibly 
since they are so much harder to test than anything else), and the current 
architecture has every bug drag the server down.

A solution to this is to separate the Game Server from a Client Server: the 
former communicates game state to the latter, and the latter is responsible for 
forming this into whatever user interface is needed.  In this way, if the 
Client Server crashes for whatever reason, this no longer drags the Game Server 
down with it; only that user is affected.

The next problem to solve involves getting data from the public facing IP 
address to the Game Server via the Client Server, which necessitates a Login 
Server to control the process, and the rest follows from there.

Added advantages to this decomposition include:
1) Many of the current problems with multi-threading vanish (as it is now 
multi*processing*).
2) The dissociation of the public facing IP address from the actual game server 
allows for a much more scalable architecture, which could involve multiple game 
servers, or even sharded servers.

So without further ado, here is the broken-down request:

Split the main Paradice server into several servers with distinct tasks:

* Login Server
  * Is hosted at the publicly available and disclosed IP address.
  * Performs client capabilities detection.
  * Used for log-in control and game server selection.
  * Communicates trivially between a client and a Client Server.

* Connection Manager Server
  * Maintains a list of available game servers/shards and their locations.  Reports on their IP address.
  * Can create Client Server instances and report on their IP address.

* Game Server
  * Reports its existence to the Connection Manager Server. This could be a shard for a server cluster, or just a completely different game server.  Could report on a different set of options for each.)
  * Parses actions received from the client via the Client Server.
  * Reports on game state updates to the client via the Client Server.

* Client Server
  * Created by the Connection Manager Server on behalf of the Login Server.
  * Communicates with the Game Server.
  * Provides the UI experience for the Client based on game state updates from the Game Server.

Notes:
* The Login and Connection Manager servers could be the same entity, although 
that may limit the number of available connections to the login server.

Original issue reported on code.google.com by [email protected] on 9 Jul 2013 at 11:25