User manual

6. Invoking Funcons Remotely – Funcon Rpc() and Friends

Remote Procedure Call (RPC)-related funconality is such a fundamental part of SNAP and SNAPpy that it is

worthy of a secon by itself. Refer also to the SNAP Primer for even more basic coverage of this topic, and the

SNAP Reference Manual for even more detailed coverage.

There are four SNAPpy built-in funcons that can be used to invoke a funcon on another node:

• mcastRpc()

• rpc()

• callback()

• callout()

These are non-blocking funcons. They only enqueue the packet for transmission, and do not wait for the packet

to be sent (let alone waing for it to be processed by the receiving node(s)).

Each can be used to invoke any public funcon on another SNAP Node (either a user-deﬁned funcon, or a built-

in funcon), but each has addional strengths, weaknesses, and capabilies.

The reliability of message delivery is an important consideraon in selecng the best way to send the message.

Mulcast messages (those sent using mcastRpc()) generate no explicit conﬁrmaon of receipt from any other

node in your network. If you want to be sure that a parcular node has heard a mulcast RPC call, you must

provide that conﬁrmaon as part of your own applicaon, generally in the form of a message sent back to the

originang node.

Unicast RPC calls are addressed to a single target node rather than being open to all nodes that can hear the

request. The reliability of these calls is bolstered by a series of acknowledgement messages sent back along the

path, but even that is no guarantee of a ﬁnal receipt of the message, especially in a dynamic environment.

Consider a situaon where there is distribuon of your nodes across a large geographic area, such that some

nodes cannot communicate directly with other nodes without SNAP’s automac mesh networking assisng by

roung and delivering the message through other nodes. If node Alice can consistently communicate with node

Bob, and node Bob can consistently communicate with node Carol, messages from node Alice to node Carol will

be forwarded automacally by node Bob if node Alice and node Carol cannot communicate directly.

However, the acknowledgement messages in this arrangement are each incomplete, each conﬁrming only part

of the whole path. When node Alice has a message for node Carol, it begins by sending out a route request,

essenally “Is node Carol in range, or does any nearby node know where I can ﬁnd node Carol?” Any non-Carol

nodes that hear the route request will forward the request: “Hey, out there! Node Alice is looking for node

Carol!” and this will connue (within limits) unl node Carol is found, replying to the node that it heard asking,

which then replies to the node it heard asking, all the way back to Alice.

So, node Alice asks for a route to node Carol, node Bob hears the request and asks for a route to node Carol,

node Carol responds to node Bob, which now knows it can talk to Carol, and which then responds to node Alice,

indicang that it has a path to node Carol.

Now node Alice knows that if it has a message for node Carol, it must ask node Bob to forward the message to

node Carol. When it sends a message for node Carol, node Bob hears the request and sends node Alice an

acknowledgement. It then forwards the message to node Carol and waits for node Carol to send an

acknowledgement.

For either of these transmissions, if the receiving node does not send an acknowledgement packet within a

conﬁgurable meout period, the sending node resends the message up to a conﬁgurable number of mes

before realizing that it cannot get through.

32 SNAP® Network Operang System