The G System is designed to simulate huge virtual realities. This can include many solar systems and planets, down to small details such as houses, environments, and even individual plants. All these things are not static. This means everything can change, humans (often controlled by real human users) move around, interact with other elements in their environment, ...
To allow for such a large scale simulation, some infrastructure needs to provide the computer processing power, the storage, and the communication. This infrastructure is provided by the GWE - the G World Engine, it is the container framework for all elements.
Elements simply operate. To them, the complete simulated universe is just a huge (hierarchical) collection of elements. They are not concerned with the physical location of other elements when communicating. Providing this seamless network transparency of a distributed server infrastructure is the purpose of the GWE.
As hinted in the previous section, the GWE is a distributed server infrastructure, or in other words, an element container and thus the framework the elements rely on for their operation.
The following UML diagram should give an idea of the GWE structure.
To provide a flexible implementation a general interface for
each functionality is defined. This currently includes the
GweController which is responsible
for element execution management and logic, and the
GDataController which is responsible
for persistent and network transparent data management and
GWE Server network communication.
The abstract interfaces, including the GWE Factory class, are available as public API, thus enabling application developers to control the GWE behaviour without being dependent on the actual implementation classes being used by the different components (for example whether a simple or advanced GWE Controller is used) because the implementation is not part of the API. The Factory class is used to bootstrap a GWE Server which uses the differen implementation classes.
An important part is the complete abstraction of physical data location. This is accomplished by a data controller class that manages all data and data transfer. This is also where the other GWE Servers in the network are known and intelligent load and data balancing is done according to the logical hierarchical structure of the virtual universe.
Currently there is one XML based data controller available. This controller uses a separate serialisation class to convert between C++ objects and XML representation of elements. The C++ objects are required for execution and the XML representation is used for sending element data across the network and managing database content.
Currently there is one Network implementation available, the
GXmppNetwork. This implementation builds
on the standardised XMPP
protocol. XMPP is essentially a real-time XML router, as Justin K.
has put it in an email. And this is exactly what we need. We have
XML data that needs to be routed through the network to some
destination (another GWE Server).
Speaking in XMPP language a GWE Server is an XMPP client and uses an XMPP server to communicate with other GWE Servers which are also XMPP clients (possibly from other XMPP servers). Thus we do not even have hardwired peer-to-peer connections but rather a transportation framework that takes care of message routing and delivering.
The network structure basically looks like the following:
The elements that make up the universe are structured hierarchically. Every element, such as a planet, includes all its subelements and presents itself as one complete unit. This way it does not matter how complex an element is internally. Planets, complete landscapes, cities, or even houses can be represented by one element, altough they consist of many subelements internally. This hierarchical structure can be thought of as logical layering. Communication between elements usually only takes place between adjecant layers. This makes the complete GWE Server infrastructure enormously scalable because each GWE Server only needs to know about adjecant Servers!
For every element exactly one GWE is responsible. Responsibility distribution is usually handled according to communication load between elements. Elements that communicate a lot with each other normally reside on the same physical GWE Server.
GWE Servers that contain elements that send influence to elements not managed on the same GWE Server need to know where to find these elements. This information can be obtained from GWE servers higher in the hierarchy.
The network capabilities of the G System include distributed element management and in particular element responsibility. This means that responsibility can also shift between GWE Servers. This raises the requirement for data transport and for control messages. Data messages can contain any element data, either complete elements or just partial data which can then be updated on the receiving GWE Server. Elements that are known on multiple GWE Servers can only have one GWE Server that actually is responsible for a particular element. Passing on the responsibility can only originate from a server that currently possesses the responsibility of a particular element.
Network latency implicitly requires save transactions and no influence loss. Here is the general procedure for shifting element responsibility described:
First, the elements themselves need to be made known to the target GWE Server. This is a simple data transfer. The source GWE Server needs to keep track of all received influences after the element data has been transfered, since influences are only forwarded to the currently responsible GWE Server. This can be done by sequentially numbering received influences and remembering the last number that the elements have received before the last data transfer to the target host.
As soon as the data has been sent to the target host, the source GWE Server asks the target host if it has enough capacity to take the responsibility for the specified elements. If the target GWE Server rejects the elements, then no further actions are taken. All influences are further delivered to the elements on the source GWE Server.
In case the target GWE Server accepts the responsibility for the elements all influences that were received by the source GWE Server in the meantime are forwarded to the target host, the responsibility is implicitly shifted and all GWE Servers that are directly higher in the hierarchy of the shifted elements are notified about the responsibility shift. Note that this shift implies that the new responsible GWE Server activates influence emitting of the taken elements while the source GWE Server disables influence emitting for these elements.
It is also possible that other GWE Servers do execute elements they are not responsible for to get adequate predictions of states. Such predicted elements are called secondary elements wheras the real elements are called primary elements. Each GWE Server can thus have primary and secondary elements.
Secondary elements are usually found on a GWE to which clients are connected. Such secondary elements never send out influences but still can receive them from local influence sources to improve prediction accuracy. Such influences are then multiplexed to the primary element and the corresponding secondary element. Influences are never sent to remote secondary elements but only to the primary elements and local secondary elements. The data of predicted elements are constantly updated from the GWE Server that hosts the corresponding primary element.