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.
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.
- 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
- 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
- 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
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.