The Deus Networking Architecture

There are several programs in a complete game of Deus.

The Master Server

There is only one Master Server. Its only roles are in organisation and coordination. It handles logins for players (indirectly), and directs them to the correct Map Server. It maintains lists of all extant map servers and routing servers.

The Map Servers

The game engine is located in the Map Server. A Map Server handles, in general, several maps, and all enitities etc. in them. Map Servers communicate with each other concerning their boundaries.

The Routing Servers

The routing servers form a network, accepting incoming TCP/IP connections from clients, and directing them to their destination by the fastest route. They maintain routing tables indicate the latencies and reliabilities of their connections to the master server, all map servers, and all other routing servers. The connections between routing servers and the other server types are UDP, and compressed, combining all data for that destination. These enable the Deus network to route around internet instabilities (to some extent).

A routing server which happens to be on the same machine as a map server or the master server may be able to communicate by a more efficient protocol (e.g. unix domain sockets) depending on the OS involved.

The Clients

Clients communicate by TCP/IP connections to routing servers. A client should be configured with the addresses of (ideally) several routing servers. However, a client's first action is to download a list of all routing servers. It then runs a quick latency check on each, and decides on the best to use (and should store away this list for later use). There will always be a routing server running on routing.deus.net.

The Protocols

• Routing Server Redirection Client <--> Routing
  This unauthenticated protocol enables a client to request a connection with the master server or a particular map server. This is the only client protocol to which a routing server can directly respond.
• Router Enquiry Client <--> Master
  This protocol enables any client (no authentication is needed) to download a list of running routing servers, from the master server. There is a command which only returns the list if it has changed since a certain time.
• Authentication Client <--> Master
  This protocol ensures the supply of fresh soup to the mexican army. It also allows the various types of client to authenticate themselves. Any login simply involves a name and password. Password suitably encrypted. Different login names, however, will have different kinds of access. 'Player' access gives control of, and the Point Of View of a particular entity (the player character). 'Administrator' access, permits the administrator to view the entire world, moving his Point of View at will. A successful player logon returns the ID for the Map Server to use, and an authentication token.
• Logon Tokens Master/Map <--> Map
  This protocol is used by the master server to inform the map of authentication tokens. Tokens time out after a few minutes, but the map will allow the client to log in during that time. The master tells the map server, as well as the token ID, the IP address and the login name to expect. It is also used by one map server to inform another when a client is moving between map servers.
• Map Login/Control Client <--> Map
  A client uses an acquired token to log in to a map in this simple protocol. Having logged on this becomes a control stream, - the client can request other sessions to be started - e.g. a Point of View session. When a client leaves one map server, this connection is ended with directions to the next map server to use, and a new token.
• Point of View Client <--> Map The point of view protocol sends data almost exclusively in the map to client direction. A map simply sends a client all the information which can be seen from its point of view. [??? how often ???]. The client presumably uses this, in most cases, to construct an on-screen representation of the Deus world for the benefit of the player. Some point of views allow the client to send back commands to move the point of view - only the administrator ones. Those point of views bound to an Entity are limited by the game engine (which can calculate line of sight, etc.). The unbound, administrator point of views, describe their own parameters (e.g. line of sight, range of sight, presences observed).
• ???? Map Dump Client <--> Map There may be a case for an administrator to request a map dump connection, which tells you *everything* about the current map. It would be high bandwidth, though.
• Actor Control Client <--> Map The player does not directly control his entity. In fact, he controls the actor which controls the entity. Different actors can implement different commands within this protocol. For example, the actor which player gods use is more flexible than the actor which normal player characters use.
• DDL control Master <--> Map When maps load, they download from the master server the DDL code for all entities, effects, etc. that they need. On demand, as necessary, they can download more. When the DDL code for an object is changed, the change can be uploaded to the master server, which will then propogate the change to all maps.
• DDL object exchange Map <--> Map When an entity leaves one map server, it is sent to another using this protocol.

Issues

As I write this, I am unhappy about the multiple map server model - w.r.t such concepts as a mage using a spell to look at a map on one map server whilst he is in another. Maybe we should ditch the concept - but it helps scalability so much. At least, my client to map design needs upgrading to cope with the concept of points of view on different map servers to the entity. Hmm... or maybe I can model that already --- JB.