User manual

All of this route seeking and acknowledgement protocol occurs automacally with SNAP. There is nothing the
user must “turn on” in order to make it work (though much of the funconality can be fine-tuned through the
use of NV parameters).
In the above configuraon, imagine a situaon where node Alice has discovered a route through node Bob to
node Carol, and sends node Carol a message. Node Bob hears the message and sends node Alice an
acknowledgement, so node Alice goes on about its business confident that its message is delivered. However at
the point that node Alice hears the acknowledgement, node Carol has not yet received the message from node
Bob. If node Carol is sleeping or is otherwise unable to hear the message from node Bob, node Bob will aempt
the configured number of retries, but will eventually give up if node Carol cannot be found – and (other than a
route failure message that goes out, indicang to node Alice that the next me it tries to communicate with
node Carol, it should first perform a new route request) this failure to forward the message will not be reported
back to node Alice.
If you need to be sure that your target node has received a message, whether the message were sent by unicast
or mulcast, it is best to write your applicaon to explicitly send a confirmaon that the message has been
received, and to explicitly retry sending the message if no such confirmaon comes.
McastRpc(group, ttl, function, args…)
Built-in funcon mcastRpc() is best at invoking the same funcon on mulple nodes from a single invocaon.
The tradeoff is that the actual packet is usually only sent once. (The excepon to that rule is if you have enabled
the oponal collision detect feature of SNAP, in which case the packet might be sent more than once if a packet
collision were detected.)
How many nodes actually perform the requested funcon call is a funcon of three factors:
1) Number of hops
a) How many hops away are the other nodes?
b) How many hops did you specify in the mcastRpc() call? (TTL parameter)
2) Group membership
a) What mulcast groups do the other nodes belong to?
b) What candidate groups did you specify in the mcastRpc() call?
c) If the desnaon node is more than one hop away, do intermediate nodes forward the specified group?
3) Only nodes that actually have the requested funcon can execute it
Examples:
mcast_groups = 2
hop_count = 4
mcastRpc(mcast_groups, hop_count, "startDataCapture")
All nodes in the second group that can be reached within 4 or fewer “hops” (forwards, or retransmissions of the
message) will invoke funcon “startDataCapture” (if they have a funcon with that name in their currently
loaded script).
This is an example of using mulcast RPC to increase the synchronizaon of the nodes. Note that all of the nodes
will not necessarily be “starngDataCapture” at the same moment, because the closer nodes will be hearing the
command sooner than the nodes that require more mesh network hops.
reactor_temperature = get_reactor_temperature()
if reactor_temperature > CRITICAL_TEMPERATURE:
mcastRpc(1, 255, "runForYourLives")
SNAP® Network Operang System 33