expression or, per default, only if the result differs from the current value stored in the variable. Similar applies to notifying the application about the result of the evaluation, but the notification can be also switched off completely, what is the default setting if no trigger parameter is provided. The value of the trigger parameter is set using one or a combination of the defined constants (see Listing4.1).
Theglobalparameter (see TableA.1) is used to indicate that the variable is a global one. If it is not enabled the variable is an array variable. Themigrationparameter (see TableA.2) enables the migration of the ownership of the entity of a global variable. The parameter specifies the number of required consecutive write operations from a single external node to the entity that trigger the migration of the ownership. If the parameter is set to zero or not defined the migration is disabled.
Thetimestampparameter (see TableA.3) enables choosing between time-stamping and versioning the instances of the variable. This parameter defines the actual meaning of the value in the timestamp field of each instance of the variable. Versioning is the default option. The following two parameters are independent from the actual content of the timestamp field - timestamp size(see Table A.4) and timestamp tolerance (see Table A.5) specify the minimum required size of the timestamp field in bytes and the maximum allowed difference between the timestamp of the instance stored in the tinyDSM middeware and the timestamp specified by a read request to be able to answer the request with the stored instance.
Therequest number sizeparameter (see Table A.6) specifies the size of the data type required to store the request sequence number for the given variable.
4.4.2 Replication policy parameters
The parameters from this group specify the features of the replication for all the entities of the variable. They control the replication strategy mechanism and the forwarding of the update messages introduced in Section 3.2 and Section 3.1, respectively. The replication rangeparameter (see TableB.1) specifies the maximum distance from the source node in hops within which the instances of the variable can be replicated. Thus, this parameter specifies the potential copy holders of the data. If thereplication range is set to zero, then the replication area is unlimited, i.e., the variable will be replicated in the whole network. Leaving it undefined disables the replication for the variable.
Thereplication densityparameter (see TableB.2) specifies the desired density of the replicas in the network depending on the distance from the owner of the master copy.
The size of the input array is defined by thereplication rangeparameter. These values specify in per cent how many of the nodes at each hop shall store replicas for the variable.
The first value in the array (index zero) represents the owner of the master copy and is always regarded as equal to one hundred.
The replication copies parameter (see Table B.3) defines the desired number of replicas in the part of the network defined by the replication rangewith the distribu-tion defined by thereplication density. As mentioned in Section3.2, if this parameter is set, then only the nodes that store the replicas send the acknowledgment messages.
Thus, it may reduce the network traffic compared to the verification in the pure density based approach. However, it requires a priori knowledge on the amount of nodes in the network, to avoid specifying the number of copies to a value that cannot be achieved.
The update pattern parameter (see Table B.4) is used to specify the replication strategy (see Section3.2) for the entities of the variable. It takes as input three integer values that parameterize the phases of the replication. The first value specifies the max-imum number of advertisement repetitions in the ADVERTISE phase if the replication goal is not reached. The second value specifies the number of successive update requests in the UPDATE phase that do not require any acknowledgments that are sent until the
VERIFY phase is applied. The third number specifies the maximum number of verified update requests, if they repeatedely state that the replication goal is not reached. If any of the values is set to zero, the corresponding phase of the replication is not executed.
Thereplication history parameter (see TableB.5) defines the number of the his-torical instances to be stored on the remote nodes that store the replicas of the entity of the variable, depending on the distance from the owner node. The size of the input array is defined by the replication range parameter and its values are influenced by thereplication densityinput, i.e., if any of the values in the replication densityis set to zero, then the corresponding value in thereplication historyarray is set to zero as well. The first value in the array represents the source node itself, i.e., it defines the size of the history on the owner node.
By default, the dependent forwarding of update requests is used (see Section 3.3).
The independent update forward parameter (see Table B.6) enables forwarding of the update requests even if the forwarding node does not store the data contained in the message. This allows increasing the penetration strength of the update requests and reaching nodes that are hidden to the update mechanism by the neighbors that decided not to store the replica. It allows achieving an equal distribution of the replicas in the replication range. However, this is combined with increased communication costs. If thereplication densityarray contains any zero followed by a non-zero value, then the independent update forwardingis enabled automatically. If thereplication range parameter is set to one, then the independent update forwardingis disabled.
4.4.3 Reliability policy parameters
Parameters from this group control the reliability of the data storage in a broad meaning of the term.
Thepermanentparameter (see TableC.1) indicates that the local copy of the most recent instance of the variable shall be stored in a non-volatile storage. This ensures that the most recently written value will be available even if the node experiences problems that caused hardware reset and the content of the RAM memory is lost. It influences the implementation of the functions to access the storage where the local copies are stored (see Section 4.5.2).
Thevariable timeoutparameter (see TableC.2) enables a different kind of reliability–
the data reliability, i.e., it specifies the period the instance is valid after it is stored in the local storage. This ensures that, in case the source of the data is not on-line anymore, the out-dated data is not used and increases the quality of the data storage.
Theanswer not local gets parameter (see TableC.3) allows the nodes to respond to remote read requests about entities that do not belong to them. On one hand, this increases the reliability of the system by increasing the chance to get the data, but on the other hand, it induces additional resource consumption. The default setting is that a node answers only requests about its own data.
4.4.4 Optimization policy parameters
In general, the policy parameters from this group allow enabling and controlling mecha-nisms to save resource consumption. These resources include memory, transmission and processing time. The parameters from this group can also influence the reliability of the system by controlling the use of these resources.
In order to reduce the chance of keeping stalled requests that will never be handled and block the resources to handle new ones, a timeout period for a request can be defined.
After this time elapses the request is marked as failed due to timeout and a notification is sent to the source of the request. The timeout period can be set depending on the source of the request using thelocal request timeoutandexternal request timeout parameters (see Table D.1 and Table D.2). Setting the timeout parameters to zero disables the timeout mechanism for the particular variable.
The local request retries and external request retries parameters (see Table D.3and TableD.4) specify the maximal number of delivery retries for requests in order to reduce the chance of storing requests for which the delivery fails forever. Setting any of the parameters to zero disables the limitation of the number of delivery approaches, i.e., it will be retried until the delivery is successful.
Thefifo processing parameter (see Table D.5) indicates that the variable requires that the requests on its entities are processed by each node in the sequence they were delivered to that node.
Thediscovery hopsparameter (see TableD.6) specifies the maximum height of the request forwarding tree for the master copy discovery described in Section 3.4. Setting the parameter to zero disables the discovery mechanism for the variable. This is also the default setting.
The following paragraphs present the parameters that control the instance filtering mechanism as described in Section 3.6. They control the behaviour of the master copy owner. The replica holders are not affected by these settings, they only replicate the data that is sent to them.
Themin store delta time(see TableD.7) andmin update delta time(see Ta-bleD.10) parameters allow specifying the minimum time difference between two consec-utive accesses to store the instance of the variable in the history storage and between two consecutive replica update requests for the instances of the entity, respectively. Setting to zero disables the filter.
The replica update requests are issued by the owner only for instances that it stores in its local history storage, so the value specified for the min store delta time also applies for themin update delta time, if the value defined for the latter is smaller.
The min store delta value (see Table D.8) and min update delta value (see Table D.11) parameters specify the minimum allowed difference between the values of two consecutive instances to store in the history storage and to issue a replica update request, respectively. Setting the parameters to zero disables the filter.
The minimum value difference may be defined either as an absolute value or it may be defined by per mille ratio. Setting the permille store delta value(see TableD.9) or permille update delta value(see Table D.12) enables the per mille ratio for the respective filter. By default the minimum delta value is provided as an absolute value (see Section 3.6for details).
Again, the filter specified for the storing of the instances in the history storage may also apply for the replica update request issuing, if the filter of the latter is stricter.
However, a direct comparing of these two filters is only possible if the minimum difference for both is defined in the same way, i.e., either they are both defined as absolute or they are both defined as per mille delta.
4.4.5 Access rights policy parameters
The access rights policy parameters specify the allowed operations to be performed by the local node on its own entity of the given variable (see Table E.1) and on an entity that belongs to another node (see Table E.2).