Table of Contents
The purpose of this chapter is to give the reader an overview of the Massiv object model and to make him familiar with the basic principles that will be described in the second part of the book in detail.
The Massiv defines and implements its own distributed object model built on top of the C++ object model. The model can be separated into two independent parts:
Object model design - what can be done with the objects and how.
Mapping to the C++ object model and discussion of implementation issues.
At the early development stages the team had to carefully clarify what the basic model design goals were, what could be done with objects, how and to what extent the object manipulation would be supported (automated) by the Massiv Core. The generic C++ object model had to be extended to allow implementation of new features that were not supported by the standard but were required to satisfy our distributed object model goals. The usage of the new model should have been as close to the standard model as possible. We were certainly inspired by some existing challenging middlewares but also found many of their principles useless and impractical for purposes of MMO games and so developed our own techniques which we believe to be really novel.
The following design goals were taken into consideration:
Unique object identification
Objects must be uniquely identifiable (addressable) through out the distributed object space. The identification of an object never changes and does not depend on the object's current location. Object identifications are not recycleable, they are persistent and can be passed to other nodes.
Location transparency
Objects can migrate. Effect of an operation should not depend on the relevant object's current location. The Core must be able to localize an object even if it migrates. The Core must be able to migrate objects not only in consequence of user requests. The actual migration operation must be transparent to the user and the Core must not require the user to participate in the migration process (cooperate with the Core).
Automatic persistency
The Core must be able to automatically serialize objects and perform consistent backups. Objects can point to other objects and such pointers are persistent too.
Automatic replication
Any object can be replicated to other nodes. The Core must be able to gain access to either original object (primary replica) or its replica (secondary replica).
Flexible object migration and replication granularity
Objects can be optionally grouped into migration and replication groups. The Core ensures that the groups will always be processed as an aggregate (objects from the same migration group will always be located on the same node). Groups can be changed at run-time and the way of how they are defined must respect the dynamic nature of the changes. The definition should be automatic, possibly driven by object pointers.
Object to object migration as a primary way of object collaboration
Object migration is the only directly supported way of data exchange between objects and object interaction. Migrations are addressed by objects. This is basically an agent model, where agents (objects) migrate in order to accomplish their tasks. Once delivered to an object, a callback is called on the delivered object. Almost everything else (RPC and messaging, for example) can be built on top of the object migration.
Automatic object management
Objects can be dynamically created and automatically accessed from all nodes. This includes even short time living objects. There is no need to discriminate between local "unmanaged" objects and the objects managed by the Core. A form of automatic (non-cooperative) garbage collector is essential in this kind of environment.
Simplicity, scalability and efficiency
The proposed object model should be easy to use and as efficient as possible.