Replication Priority

Revision as of 14:26, 20 June 2011 by HE-NICK (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search



Replication copies nodes from one GOM to another. Often, there are so many changes for nodes that are being replicated from servers to clients that there is not enough bandwidth to send all the changes. This page is about the design time choices which control the order in which field changes are sent to clients. Besides the formula for prioritization, this also covers the concepts of atomic sets and discrete changes.

Field priority

When the Dude Server receives an update for a field from an Area Server instance, it checks if there is already an update of that field pending. If it is, the field updates are combined into one new update unless the field is marked for discreet updates, in which case this becomes an independent update.

If it is a new update, then a priority is assigned. This priority is established separately for each client.

When the Dude Server is ready to send replication updates to a client it starts with the highest priority value and continues to the lowest until all updates are sent or the bandwidth limit is reached. Atomic sets can cause lower priority updates to be sent, however, as described below.

The priorities of any updates that were not transmitted (due to bandwidth limitations) are then adjusted based on their field settings.

Each field has three attributes in the DOM used for priority and one attribute for lifetime as follows:

Initial priority

Initial priority is the priority value that is assigned when a field changes or first becomes replicated to client. When an field changes before the previous value has been sent to a client, one of two things happens:

  1. If the field is marked as preserve discrete or the previous value is part of a discrete atomic update, the change is queued after the discrete update with its accumulated priority set to the initial priority.
  2. Otherwise, the accumulated priority of the update is retained.

Delta priority

Delta priority is an amount to change the update's accumulated priority over time. Even though the priority may be computed more frequently, delta priority is given in units of priority per second.

Distance factor

Distance factor is multiplied by the current distance between the group's position and the client's position as specified by Spatial Awareness System entities (see Controlling Replication). The effective priority is set to the accumulated priority minus this product.


It is possible that field updates will be delayed by higher priority updates past when they are applicable. This is where Lifetime comes in. If non-zero, it specifies the number of milliseconds to keep trying to send an update. After that much time elapses and the update has still not been sent to a client, it is dropped from the list of updates needing to be sent for that client.

Class definition

The DOM class definition specifies which fields participate in replication as well as the initial set and any atomic sets.

Initial set

When a node is first replicated to a client or a class is added to a replicated node, the values of fields in the initial set(s) are sent along with the change to node structure, so that they are present when the client receives the event. The initial set(s) of the parent classes are included in this initial update.

Atomic sets

There may be circumstances where you want to group fields together such that an update to any of them forces an update to them all. In other words, if any change, they all change atomically. This is done by assigning the fields to an atomic set. Ignoring discrete changes for the moment, when a field update is chosen to be sent, any other (lower priority) updates that are in an atomic set with that field are replicated at the same time. All of the transmitted field values are updated on the destination node before the script callbacks for the fields happen. The atomic set(s) of parent classes are also used when determining which updates are atomic.

See the next section for how atomic sets and discrete changes interact.

Preserving discrete changes

Normally, when a field definition has discrete set to false, changes are coalesced until they are actually delivered to the destination. This means that if a replicated field changes twice, each client may receive 2, 1, or zero changes (for zero see lifetime).

When a field definition has discrete set to true, no coalescing is done. Each change on the source node happens on the destination(s) unless the updates reach their lifetime. Priorities are still used for each change, so the changes can be delayed, but when sent, they are sent in order. Note: The discrete option should be used sparingly because it uses more bandwidth and much more memory on the Dude Server.

Discrete atomic updates

When a field marked discrete is also in an atomic set, changes to that field lock in the values of the other fields in the atomic set. It's not that the other fields can't change, but rather that the changes are put in a queue to go out after the discrete atomic update. It is as if a picture was taken of all of the fields in the atomic set at the moment that the discrete field changed, and the replicated fields must look like that picture when that update is delivered. Note: Using discrete with atomic sets can use even more bandwidth and memory on the Dude Server.

See also

Personal tools