Each managed object keeps list of nodes it should be replicated to, and for each node the simulation time when replication of the object to the node should be stopped. When the Core decides to update replicas on a node, it gathers set of objects that should be replicated to the node, determines all objects belonging to their replication groups, and sends the replication update to the node.
![[Note]](images/note.png) | Note |
|---|---|
Replication of replicas is illegal. | |
In this chapter, when talking about a given object and its replication, replication server refers to the node that owns the object, and replication client refers to each of the nodes the object is replicated to. Somethimes this may be shortened to server and client. When talking about different types of nodes, as described in Section 2.1, “Types Of Nodes”, server node and client node terms will be always used.
The Figure 7.1, “Replication Example” shows a simple situation, where Replication Server owns two objects, Object A and Object B, and replicates them to Replication Client 1 and Replication Client 2, respectively. The Core keeps the copies of the objects and their replication groups on replication clients, until the replication timeout simulation time is reached.
The figure does not indicate whether Object A and Object B belong to the same replication group or not. If they belonged to the same group, the same set of objects would be replicated to both replication client nodes, even if the replication was “triggered” by a different object.
Only server nodes are allowed to replicate their objects. Any client node that tries to replicate an object to a server node will be disconnected from the simulation. There are two reasons for this behavior:
Replication from client nodes to server nodes seems useless. None of the two scenarios where replication may help (world presentation and communcation optimizations) applies to client nodes.
Replication from client nodes to server nodes would be dangerous and insecure. It would allow client nodes to spam server nodes with tons of useless objects.
When an object, that is replicated to several nodes, migrates, the new owner node becomes responsible for replication of the object. All replication requests, along with their timeouts, will migrate with the object.
Object remembers replication request even when the replication client node of the request is the same as the owner node of the object. Such requests are perfectly legal. No replicas on the owner node will be created, but if the object migrates to a different node, the new owner node will automatically replicate the object back to the former owner node.
Because client nodes are not allowed to replicate their object, when an object migrates to a client node, all replication requests of the object are forgotten and its replicas are destroyed.
You should already know what class kinds mean. If not, refer to Section 4.3.7, “Class Kinds”.
It is allowed to replicate objects of any kind to a node of the same type, but when replicating to a node of different type, all replicated objects must be of KIND_SHARED.