General Computational Model of a Node

Here we describe the gradient forwarding mechanism used, and define the functions required to understand the pseudocode in the following sections. Also, in its current form, the code for the different stages of the algorithm is executed on nodes after a period of time elapses - the mechanisms for scheduling and handling these timeouts are described. Finally, the different gradients and timeouts used in the proposed edge detection algorithm are listed.

A single node only executes code response to two events: a previously scheduled timeout, and receiving a neighbours’ message. All code is assumed to be executing in a serial fashion. When an event is handled, it is handled in its entirety before handling of any other event may occur.

In the pseudocode, a node can read and write local state with the myState ob-

ject. This object contains one well known property,nodeId, which is the node’s ran-

domly chosen identifier. In some places2_{, the pseudocode may reference ahostState}

object, which is an alias for themyState object residing on the node that the code

is executing on.

3.2.1.1 Timeouts

A node can schedule a timeout using thescheduleTimeout(T IM EOU T N AM E)

function. For the sake of simplicity, in the pseudocode, the T IM EOU T N AM E

argument is just a mnemonic name - the point in time it corresponds to would be calculated based on the convergence times of the different stages (refer to section 3.2.11 for these calculations).

When a timeout event occurs, the scheduleTimeout(T IM EOU T N AM E)

function will be called to execute code to handle the timeout.

3.2.1.2 Communications

The communications capability of a node is assumed to include broadcasting of small messages to nearby neighbours lying within in a roughly circular radius. It is assumed that the communications link between neighbours is bi-directional - a node should not be considered a neighbour if the link is only unidirectional.

This communication link is unreliable: message loss, collisions, and other faults are possible.

3.2.1.3 Homepages

A node maintains a list of key-value pairs in a read-write table called a HomePage. A node will periodically broadcast this HomePage to its neighbouring nodes, re-

gardless of whether the HomePage has changed or not3_{. Each node also stores the}

2_{Namely, in theConstaintpredicate (see section 3.2.1.4)}

3_{It should be noted that the communication’s mechanism used in the simulations of the algo-}

latest received, or imported, HomePage from each neighbour, as a read-only table. This mechanism allows the exchange of state between neighbouring nodes.

If no HomePage is received from a neighbour after a reasonable period of time, that imported HomePage is deleted and the node is no longer considered to be a neighbour. Likewise, if a new node is placed within communications range, or an old node has become available after a period of failure, it will be considered a new neighbour by nodes receiving its HomePage.

A neighbouring node, at certain points in time, may not have the resources available to receive or process incoming messages. Also, a collision, or some other communications fault, can cause a broadcast message containing the HomePage

to be lost. It is a node’s periodic broadcast of the HomePage to neighbours

that can accommodate for the unreliable nature of the communications. If the sent HomePage was not received, and the fault is not chronic, it is likely that the message will be received by one of the subsequent periodic HomePage broad- casts. After broadcasting a HomePage, a node will schedule a timeout for the

next broadcast. This timeout will occur after a random time, period, has elapsed,

where M inP eriod ≤ period ≤ M axP eriod. The range between M inP eriod and

M axP eriodis chosen to best avoid repeated collisions. In the face of common com-

munication errors, a constant calledM axM sgDelayis chosen to denote the longest

reasonable delay to expect before a HomePage update is received by a neighbour.

The M axM sgDelay constant is useful in deciding upon how long the different

stages of the algorithm should take (e.g. see section 3.2.11). This constant may be different for different communications mediums and operating environments, but as

an example,M axM sgDelaycould be set to (M axP eriod∗3) to allow for recovering

from up to two consecutive communication failures.

Two functions related to HomePages are referred to in the pseudocode:

• putInMyHomePage(key, value) - Places a new mapping in the node’s

HomePage. This will be exported to all neighbours in the usual fashion when the node next broadcasts its HomePage.

• existsInNeighboursHomePage(id, key)- Checks for the presence of the

key in the latest imported HomePage from the neighbour identified by id

3.2.1.4 Gradients

This subsection will describe how gradients are started, how they propagate, and will introduce the functions and events used in the pseudocode.

no communication faults in the simulations, and there are no node failures. This means there is no need for periodically re-sending HomePages if they have not been modified - something that allows a quicker execution of the simulations.

A gradient is started by placing details of it in the HomePage. A gradient nor- mally has several standard details associated with it, which are briefly enumerated in the following list:

• GRADIEN T T Y P E - A name for the gradient. This designates which gra-

dient handler functions are used during propagation.

• sourceID - This is the ID of the node which started the gradient. Where

gradients have multiple sources, this is not used.

• gradientID- An ID identifying the gradient. This distinguishes different gra-

dients, of the sameGRADIEN T T Y P E, from each other in the HomePage.

• Constraint - This is a predicate that is evaluated whenever deciding if a

gradient should be allowed on to a particular node. It serves to direct and

restrict the propagation of the gradient4

• Hops - This is the number of hops that the gradient has travelled from the

source. In the source node’s HomePage, this will be 0.

• isDecaying - A flag indicating the gradient was stopped by the originating

source node and is currently in the process of being removed from participating nodes’ HomePages.

In the pseudocode, there are two functions for starting a gradient:

• makeGradient(GRADIEN T T Y P E) - This just creates and returns a

new gradient object (with a hop count 0) of the given type. It does not place it in the HomePage. This new object would then be populated in the pseudocode with gradient specific details.

• startGradient(gradientObject) - The passed gradient is placed in the

node’s HomePage, effectively allowing it to begin propagating when the Home- Page is next broadcast to neighbours.

Gradients propagate throughout the network whenever a node exports its Home- Page. All nodes, when receiving an exported HomePage from a neighbour, will look for any gradient details in the HomePage updates. When a gradient is found in this update, a gradient object is reconstructed from the details and this gradient ob-

ject has its Hops value incremented by one. The gradient’s Constraint predicate

will then be evaluated, which possibly can draw on local node state. Only if the

Constraint evaluates to true, is the gradient considered for propagating on to the

receiving node.

4_{For brevity, the pseudocode treats this predicate as mobile code passed from node to node}

and evaluated at run-time. In the Java simulations however, every node contains the code for all gradient types’ predicates at compile time. The Java simulations also do not store and propagate the predicates via the HomePage.

If a gradient from a neighbour’s HomePage satisfies the Constraint predicate, the local node will check it’s own HomePage to see if the same gradient has pre- viously propagated on to this node. If the gradient is not already present in the node’s local HomePage, then it is simply placed in the HomePage. If the gradient is already present in the node’s local HomePage, the gradient forwarding mechanism will call the function

isBetterThan(GRADIEN T T Y P E,newGradientObject, existingGradientObject)

to decide whether the existing gradient is overwritten with the new gradient. If the

isBetterThanfunction returns false, no further action is taken, and the gradient

is effectively ignored; however, if the isBetterThan function returns true, the

existing gradient is overwritten with the new incoming gradient.

Once a gradient has satisfied both the Constraint predicate and the _isBet-

terThan function, it is written in the node’s HomePage, thus allowing it to be

exported to neighbouring nodes as per the normal HomePage updates. Immediately after writing the gradient to the node’s local HomePage, the

gradientDetected(GRADIEN T T Y P E,newGradientObject)

function is called to allow the node to handle the new information.

The gradient forwarding mechanism allows a gradient to be stopped and eventu- ally removed from all participating nodes’ state by flagging the gradient as decaying,

using the isDecaying gradient attribute. These decaying gradients are treated dif-

ferently to normal gradients and will be ignored, during forwarding, by nodes that have not before received a gradient of the same type and ID. They are not ignored, during forwarding, by nodes that are host to a non-flagged gradient of the same type and ID, and the incoming decaying gradient causes the node’s current non-flagged gradient to then be flagged as decaying. This continues until all of the nodes that ever received the gradient have it flagged as decaying. After some suitable time (in order to avoid any undecayed part of the gradient from spreading again) each node will remove the decayed gradient from their state.

The steps taken by the gradient forwarding mechanism, upon receiving a neigh- bours’ HomePage broadcast, is summarised in Listing 3.2.1.

Algorithm 3.2.1: _{GradientForwardingMechanism}(neighbourHomeP age)

for each gradient∈neighbourHomeP age

do                                                                                              gradient.Hops←gradient.Hops+ 1

existingGradient←_getGradient(gradient.GRADIEN T T Y P E)

if (_notNull(existingGradient)and existingGradient.isDecaying)

then comment:Gradient is ignored as it is decaying

else if(gradient.isDecaying and _isNull(existingGradient))

then comment:Gradient is ignored as it is decaying

else if(gradient.isDecaying and notNull(existingGradient)

then (

comment:Flag the gradient as decaying, if it is not already

existingGradient.isDecaying←true

else if_eval(gradient.Constraint) =true

then                          acceptGrad←true if _notNull(existingGradient) then gT ype←gradient.GRADIEN T T Y P E

acceptGrad←_isBetterThan(gT ype, gradient, existingGradient)

if acceptGrad=true

then (

comment:Store the gradient in the node’s own HomePage

gradientDetected(gradient.GRADIEN T T Y P E, gradient)

else comment:Gradient is ignored

else comment:Gradient is ignored

Two further functions, for obtaining gradients from a node’s HomePage, may be seen in the pseudocode:

• _{getGradients(}GRADIEN T T Y P E₎ - Obtains a list of all gradients, of

the specified GRADIEN T T Y P E type, from the node’s own HomePage.

• getGradient(GRADIEN T T Y P E), gradientID - Obtains the single

gradient object, with the specified GRADIEN T T Y P E and ID, from the

node’s own HomePage. This will be null if the gradient is not present in the HomePage.

3.2.1.5 Failures

The periodic updates of the HomePage mechanism act as a buffer against com- munication failures, and allow for gradients to adapt to changes in the network’s connectivity; nevertheless, the simulations of the algorithms in this thesis do not cover node failures, communication failures, node additions, or node mobility. The description of the algorithms will contain only passing reference to possible handling of communication and node failures. Further discussion of chronic failures and the ramifications of other topological changes for the algorithms is deferred to chapter 7. Comprehensive consideration of all cases of communication and node failures is an area for future research.