This section briefly lists the basic features of the Core. See Section 2.4, “Core Internal Architecture Survey” for general overview about how these features are achieved. You will also find links to the relevant chapters there.
Object Orientation
The Massiv provides a fully object-oriented interface to its user. It provides its own sophisticated object model (see Chapter 3, Object Model Introduction for more general information) that provides fundamentals for implementation of most of the following features.
Distribution
Because of a large number of players and a potential complexity of the imaginative world it is typically needed to spread the simulation over more servers. To cope with this, the Massiv comes with an object migration (enables object to move to another node, either transparently or on demand). The migration is one of the main concepts of the Massiv - even sending messages is implemented as a migration of message objects.
The main drawback of the simulation distributed over arbitrary locations is the unavoidable performance loss. It is obvious that we could never construct even nearly as efficient system as anyone who uses a computer cluster. Another disadvantage is an increased number of persisting bugs, because the complexity of debugging of a system such as Massiv is significant. There also are greater demands on system administrators - they must be able to behave as an efficient team, which might be quite difficult because of the distribution all over the world.
Security
The necessity of secure connection between client and server is obvious; it is needed to prevent players from cheating and other parties from doing harm. But together with the concept of servers located apart from each other there arises also the requirement of secure connections between servers and between a server and the data service. Classical MMO games didn't have to implement the security on this level. This security even more prolonges the communication delays, but cannot be avoided.
Interactivity
Players must be able to interact with the world in the real time. Also the simuation and presentation must be real-time.
Persistence
Because the world simulation runs generally continuously, the system must be able to ensure a world persistence to some extent. In the Massiv, this means that it must be able to generate a game backup (archive) at any moment and transparently (without giving players a chance to notice). The persistence in the Massiv ensures that the game always can be returned to the last consistent state. The frequency of archivations can be determined by administrators of the system. See Chapter 23, Archivation and Startup for more detail info about the archivation.
The Core itself implements complex protocols to ensure various aspects consistent. The Core user doesn't have to cope with these problems again and thus his situation is much easier. Some of the consistencies are:
Consistent Archive
Although the archivation process runs simultaneously on several servers (and each server generates its own part of the archive), it must be ensured that all objects stored in all archives correspond to their state at the same simulation time.
Consistent Pointers
Users of the Core can work with special pointers that can refer to objects on other nodes. However, because objects can migrate freely, it requires additional mechanism to ensure consistency of the reference (pointer) and the referee (object).
Consistent Replicas
Replication is a concept of duplication of some object on other servers to reduce the network communication and thus the latency. However, it must be seen to it that these replicas are in a consistent state with originals.
Time Synchronization
Time synchronization is needed for scheduling events. Obviously all parts of the simulated world must share the same time.
Load Balancing
Load balancing makes use of the migration and manages a distribution of objects over servers so that there is no server that is much more encumbered than the others.
Data Download
Data service nodes provide a dynamic download of data that are needed by client and server nodes. The data can be both textual and binary. The data service can be used to distribute configuration files to all nodes or to provide data required by the client for the presentation of the world, such as 3D models and textures.
Presentation
Presentation itself is not implemented by the Core. However, the Core provides some mechanisms that can be used to implement it. For example, the replication can be used to replicate the presentation-related object to clients . The programmer using the Massiv Core should be careful about separating the presentation data from the data that is used between servers during the simulation. This will help to prevent players from cheating and/or causing some inconsistencies in the simulated world.
Auxiliary utilities
The Massiv also provides number of external utilities that can be useful to system administrators. For example, there is a generator of configuration files, generator of RSA keys, tools for work with volumes/archives and others. See Chapter 25, Auxiliary Utilities for more information about external tools.