The following picture tries to give you an idea about the Massiv internal structure. It doesn't even hope to present a complete or exact information; a graph that would represent it would be very difficult and it won't be shown in this book (the Core user doesn't need to know it). The picture shows only the most significant Massiv modules and to what layers they approximately (the Massiv doesn't have a strict layered architecture) belong.
The following modules are involved in the previous image:
Network Layer
The special network layer enables to communicate over the network using an interface similar to the standard iostreams. It is a more simple way than using standard sockets libraries. See also Appendix A, Network Layer.
System Messages
System messages are simple serializable objects that can be sent between nodes. Most subsystems of the Core use them to communicate over network instead of lower-level networking interface.
Node Management
Node manager stores information about all known nodes and status of nodes connected to the simulation. System message delivery algorithms cooperate with the node manager when delivering the messages.
Registry
The registry is a persistent database that is used for the Massiv configuration as well as for storing statistical values, etc. See also Chapter 19, Registry.
Logger
The logger enables to log messages, filtering them according to several criteria and sending them to potentially more destinations. It was one of the most significant tools for debugging the Massiv. See also Chapter 20, Logger Library.
Object Searching
Because objects in the Massiv can transparently move to other network nodes, a facility that would be able to localize a given object in the simulation is necessary. It is also needed to have a mechanism able to give objects new identificators so that there are no collisions in the whole system. The Object Searching and IDs module accomplishes this task. See also Section 4.4, “Object Identification”.
Migration
The migration means moving Massiv objects to other nodes, either transparently or on demand. For more information see Chapter 6, Migration.
Replication
The replication enables to create a Massiv object replicas on other nodes, which improves the network throughput. Some operations can be performed on replicas instead of accessing the original object over the network. See also Chapter 7, Replication.
Archivation
The archivation is responsible for storing the actual state of simulation. The task is non-trivial, because all servers participating in the simulation must store the state transparently and relatively to the same time. See Chapter 23, Archivation and Startup.
Load Balancing
The load balancing module tries to avoid the situation when some servers are overloaded, whereas others are idle. It should transparently migrate some objects from the idle servers. See also Appendix B, Load Balancing.
Garbage Collector
The garbage collector destroys all Massiv objects that are not needed any more. We do not specify now what this exactly means; refer to Section 5.4, “Garbage Collector”.
RPC
RPC stands for remote procedure call. It enables to call methods of objects that are located on other network nodes in a simple way. See also Chapter 8, Remote Procedure Call.
Data Service
The data service manages all simulation data (models, textures, etc.) in a tree hierarchy, where, for example, a specific texture can be replaced by its ascendant temporarily. This enables even players with a modem connection to download all data dynamically while they are already playing. See Chapter 24, Data Service.
Account Management
It manages creation of client accounts.
Time Synchronization
The time synchronization is responsible that the simulation time on all participating servers does not differ too much. For more information, see Chapter 18, Simulation Time.
Helper Utilities
A set of auxiliary utilities useful for the Massiv simulation administrators. For more information see Chapter 25, Auxiliary Utilities.