Table of Contents
By now you should already be familiar with the distributed object model used in the Massiv. While the knowledge of the model is essential and allows you to write the logic of the distributed application, it does not give you any information about how to configure, setup, control and run the Core. This chapter will focus on these topics.
The Core can be controlled by utilizing two main classes: Massiv::System and Massiv::Core::Global. These are singleton objects with static methods. While the System class allows to control the Core in a more abstract way, the Global class enables to get access to concrete Core subsystems and allows a lower level access. Some of the accessed subsystems are private to the Core and need not (must not) be used by the application at all. See Chapter 16, Global Objects And System Interface for more information about the global objects.
Besides the application-to-Core communication, the Core sometimes needs to upcall/callback the application. The upcalls are either on the object level (special methods of managed objects are upcalled from the Core; mainly the migration deliveries and upcalls on special objects, see Chapter 14, Special Objects) or on the application level (they are global to the simulation). For example when a node connects to the simulation, the Core asks the application to create an object level representation of the local node (the application's response should be instantiation of an object derived from Lib::NodeObjectInterface, see Section 14.2, “Node Object”). Also since the model has been designed in such way that it is the Core that runs, the Core provides a next tick callback called at the end of each tick. This allows to perform additional application specific work that does not relate to the simulation directly, like redrawing the screen, handling keyboard input, etc.
As the application runs the system undergoes state changes. The states are called the system phases. It is strictly specified what can and what cannot be done in each particular system phase. When the application starts, the system is in the uninitialized state. The states can be changed using various calls to methods of the System class. Note that the Core can not be used if it is not initialized. The following diagram shows the system states, the transitions among them and the corresponding calls that cause the state changes:
| Phase | Semantics |
|---|---|
| PHASE_UNINITIALIZED | The Core is uninitialized and can not be used. This is the initial state. |
| PHASE_INITIALIZED | The Core has been initialized. It runs in an anonymous mode. |
| PHASE_DOWNLOADING_DATA | The Core is downloading minimal data required to start regular operation. |
| PHASE_DATA_DOWNLOADED | The minimal data was downloaded. The Core is ready to change its identity and register to the simulation. |
| PHASE_CONNECTING | The node is connecting / registering to the simulation using its real identity. |
| PHASE_CONNECTED | The node has connected to the simulation. |
| PHASE_RUNNING | The simulation is running. |
| PHASE_DISCONNECTING | The node is disconnecting from the simulation and changes its identity back to anonymous. |
| PHASE_SHUTTING_DOWN | The Core is shutting down and deinitializing itself. |
Application's main function usually does the following steps. The steps will be discussed in the sections below in detail:
Initializes the Core
Downloads minimal prerequisite data
Connects to the simulation
Starts the main loop
Disconnects from the simulation
Shutdowns the Core