Check the Massiv Demo for some real-world examples of replication usage. On server side, replica-optimized SRPC calls are used, for example in src/demo/lib/server/robot.cpp. Manual replication is used too. For example, in src/demo/lib/server/sector.cpp, Sector::get_tile_elevation() accepts neighbor-sector tile indices. If the neighbor sector is local or a replica of the neighbor exists, correct elevation is returned. Otherwise, elevation is estimated from current sector, and replication of the neighbor is requested.

There is one interesting feature in server-to-client replications. All presentation-related data of entities and sectors are stored in special classes. For example, class Entity has strong pointer to class ClientEntity, which contains all presenation data of an entity. This separation is actually required because of class kinds. ClientEntity is KIND_SHARED (i.e. known to both client and server nodes), while Entity is KIND_SERVER (i.e. its definition and implementation is unknown to client nodes). If presentation data were stored directly in Entity, it would have to be KIND_SHARED. That would mean that all classes used by Entity would have to be KIND_SHARED too, but that would include nearly all classes of server lib.

Because of this, the repflags attribute is not used in demo at all. Pointers from Entity to ClientEntity have ptr_repflags set to SERVER - the objects are in the same migration group and in the same replication group when replicating an entity to a server node. But when a ClientEntity object is replicated to a client node, Entity will not be in its replication group.

The client use the replica manager to monitor changes to all the Client* objects. Source of replica managers can be found in directory src/demo/client/game.