A Peer Model For Worldforge?

by Arnan Mitchell

You may have heard a snippet here or there about a server/client model dubbed 'The Peer'. This article is meant to be an overview of what the peer is meant to be and why it is needed. It will also discuss a little about where it could be used (trying not be invasive) and how it should be used without adding unnecessary bloat.

The peer concept for WorldForge was born from an identification that much of the functionality present in the server (then qserver) and basically any client that wanted to connect to it (in particular uclient) would be duplicated, appearing in both code bases. At first it would seem that the client and server are two very different beasts, and indeed there are many significant differences, however as I will try to show in the following, there is a great deal of symmetry in the underlying modules that make up a client or a server (or both).

The goal of the peer concept is to break the client and server down into the abstract components that they share and attempt to identify symmetries. The following two sections attempt to do this.

The abstract peer server

The abstract peer server consists of three major components. These are identified below are identified below in the following.

Most obviously, there is the game 'world'. For reasons of object oriented design, imagine that this game world is almost hermetically sealed and totally automatic with the exception perhaps of an externally supplied clock pulse linking real time to in game 'world' time. The working of this world are not of interest to The Peer being more the realm of STAGE, and as will be seen later, it is of use to abstract this world to provide symmetry between the client and the server.

As stated above, the 'world' is not entirely hermetically sealed. Communication between the outside real world and in-game world is possible in a highly structured and controlled way. To communicate to entities within the world, an 'Agent' for that entity is requested, and this 'Agent' becomes the interface through which commands are sent. Call the module that creates, manages and destroys Agents the 'Agent Manager'. Agents can be manipulated directly (through public member functions) or they can interpret commands sent to them through a network 'Socket'.

Having mentioned 'Sockets' there is a module that deals with networking, whether they be external requests by clients to login to the server, external requests from other servers to share workload, or internally generated requests by the server to connect to another server in a multi-server model. Call each network connection a 'Socket' object and the whole module 'Socket Manager'.

For a login, the server would be responsible for identifying that a new 'Socket' had been generated by the 'Socket Manger' and finding out what it wanted. Having identified that it wanted to login, the peer would then prompt the 'Agent Manager' for an appropriate 'Agent', plug the socket into it and then plug the 'Agent' into the 'World'. The peer would then longer need to be involved in the transactions of that socket.

This all sounds very server specific, so how can symmetry be found with the client ?

The abstract peer client

Here is a picture of the abstract peer client, again, there are three major components.

The world here is the 'perceived world' for the client to render. It is the accumulated information that the logged in player 'sees'. It needs pretty much all the same data structures as the server world, needing entities and all their basic parameters like names, dimensions etc, and it needs a similar database storage systems. This 'perceived world' is also almost hermetically sealed, with all the details of the rendering etc hidden from the core of the client. The 'perceived world' does not need to be clocked by the client, instead it receives its updates through Agents communicating with the game world server.

To access this world, again Agents are used. These receive instructions from the server, such as visual updates, which they pass on to their corresponding entities which in turn update the world around them. The client world is, after all, simply the entities perception of the server world and thus it has permission to create and destroy objects as it sees fit. These agents can also be manipulated directly by the client user interface. Since there is no game 'world' locally, these instructions are passed, via 'Sockets', to corresponding 'Agents' in the server.

The client will of course need a networking layer to connect to one, or maybe more servers.

Ok, so you have a client built on components with similar names - what's this peer thing?

The abstract peer

The abstract peer has room for all four blocks mentioned above. This allows the same object to be used for client and server. Below is a picture of the peer, with the optional components dashed.

For any application, each of these optional components must have the same basic functionality. Thus base classes for each of these objects should be provided, which can be enhanced to behave in the specific way that a client or server wants them to behave.

Below are some topologies that may be of interest. For the benefit of those reading plain text, these are a) standard client server b) Stand alone client/server, c) clustered server and d) relay point.


The future of the peer architecture is currently uncertain. I believe that using such a structure would be the most efficient in terms of code reuse and particularly maintenance between the many separate components of the WorldForge project. Having a compulsory 'Agent' module with each peer ensures that all peers talk the same language, and that any protocol change is automatically applied to all servers and clients.

I will be continuing to develop this model (currently qpeer - not in CVS yet), based on the roots of qserver2, but will hopefully be able to contribute some of the findings onto 'The Demo2' and STAGE.