What is User Extensible Caching in Programming

Replica data blocks

A replica data block is a user-expandable network object. One or more objects can belong to a replica, which serves both as a container and for the management of replica data blocks. A replica belongs to a primary peer and is passed on to other network nodes as a proxy replica. The data contained in a replica data block should generally be related to the other data stored in it. Because multiple data blocks can be assigned to a replica, unrelated data can be stored in other data blocks within the same replica.

A replica data block can contain datasets and / or remote procedure calls (RPCs). Datasets store any data that only the primary replica can change. All changes are forwarded to the data blocks in proxy replicas on the other nodes. RPCs are methods that can be run on remote nodes. They are first called on the primary server, which decides whether the call is forwarded to the proxies.

Replica Data Block Requirements and Limitations

A replica data block has several important attributes:

  • It can contain up to 32 definitions for.

  • It can contain up to 256 definitions for RPCs.

  • References to the data block are counted and must therefore be stored by an intelligent pointer.

  • It is not synchronized with the session until the Replica Manager is ready to use.

Implementation of a new type of replica data block

You have two options for implementing a new type of replica data block: Either you edit changes to data records and RPC calls ("game logic") within the data block or outside it. In both cases, the following applies:

  • The name of the data block type must be unique in the entire system. To achieve this, each replica chunk type must implement the static membership function. (E.g .. The returned string function must uniquely identify the data block type.

  • To indicate whether the owner of this data block type can be transferred, each data block type must overwrite the virtual function. If any block of data in a replica is nontransferable, the owner of the replica cannot be transferred from one peer to another.

  • Each data block type must define an intelligent pointer that accepts the instances of the data block type.

Declaration of a replica data block type with internal processing of the game logic

To specify that your replica datablock class handle game logic directly, it should inherit from:

Declaration of a replica data block type with external processing of the game logic

In order for your replica data block class to act as a simple data forwarder, passing data changes and events to a specific handler (an external class), let your handler class inherit from and the replica data block class from:

Registration of the data block type

Each custom replica data block type should also be registered in order to create the factory required for replica managers.

You can register replica data blocks with the following call:

Associate a replica data block with the replica

You must associate a replica data block with a replica before you bind the replica to the replica manager. After you bind the replica to the replica manager, you can no longer add or remove replica data blocks from the replica.

You can create a replica data block with the following call:

Whereby is passed to the constructor of.

You can append the data block to a replica with the following call:

Alternatively, you can create and add the data block in one step:

After adding the data block to the replica, the replica stores a smart pointer to the data block. The data block is only released when the associated replica is deleted.