multicastRPC

[WilliamM]

First off, I think the Snap Reference Manual needs to be updated because it has listed "mcastRPC", which, in my experience, causes an error to occur.

My question, though, is about the "ttl" parameter. What is it exactly? Is it the number of hops to be made from the node that invokes the multicastRPC? And how do you define a "hop"?

For example, if ttl = 1 will the node broadcast to all of its direct neighbors or will stop broadcasting after it contacts one other node?

Also, if a node has 5 direct neighbors, but there are more nodes outside that, does ttl = 5 mean it will only discover the 5 direct neighbors or will it go 5 hops out (along one path) before stoping?

[kbanks]

First off, I think the Snap Reference Manual needs to be updated because it has listed "mcastRPC", which, in my experience, causes an error to occur.

I'll check the docs. The command for SNAPpy scripts is mcastRpc().

My question, though, is about the "ttl" parameter. What is it exactly? Is it the number of hops to be made from the node that invokes the multicastRPC? And how do you define a "hop"?

TTL is an acronym for Time To Live, and yes, it controls the number of hops the message can take.

For example, if ttl = 1 will the node broadcast to all of its direct neighbors or will stop broadcasting after it contacts one other node?

All of it's direct neighbors. It is a limit on how many hops it can take, not a limit on how many nodes can act on it.

Also, if a node has 5 direct neighbors, but there are more nodes outside that, does ttl = 5 mean it will only discover the 5 direct neighbors or will it go 5 hops out (along one path) before stoping?

The second case - all of the "direct neighbors" are "one hop away". Also be aware that the message will follow ALL "5 hop" paths that it can find.

[WilliamM]

the message will follow ALL "5 hop" paths that it can find.

Would this be the best way to implement a global ping? Send out a multicastRpc with an estimated max necessary ttl and prompt the nodes to respond (ie. calling vmStat)?

Or is there another way that would be less redundant?
(but still faster than topology)

-William

[kbanks]

When Portal does a "ping", what really happens is a multicast of vmStat(5, 2)

When the nodes answer, Portal makes additional vmStat() calls to get additional info about each node.

The vmStat() paramters are documented elsewhere on the forum.

If you need different info than what can be obtained via a vmStat() call, then put some sort of "reporting" function in the SNAPpy script of each node.

[tom@origtech.com]

The mcastRpc SNAPpy API call has the first parameter defined as ‘dstGroups’. All of the example SNAPpy script files have this value set to ‘1’. What is the function of this parameter?

It would be helpful if the manual contained more information on all of the parameters defined for all of the API calls.

[kbanks]

If you grab the latest beta software (today that is Portal 2.1.17 and SNAP 2.1.7) and install it, then you will automatically get the latest (but still incomplete) SNAP Reference Manual.

Several new sections have been added, including more information on SNAPpy, and detailed descriptions of all API functions.

Please note that the GUI sections and the *Portal* API sections are still being updated.

[RoSz]

I'll check the docs. The command for SNAPpy scripts is mcastRpc().

I am also getting an error when using "mcastRpc". Error message sais: "An error occurred while trying to call the function pauseSleeping on node Portal"
When I instead use "multicastRpc", it seems to work as intended.
Question: What should it be; mcastRpc or multicastRpc?

(running ZIG2410 on ZICM2410-EVB3 with 2.2.14 SNAP core)

[kbanks]

The command is called mcastRpc() in SNAPpy (node) scripts.

It is called multicastRpc() in Python (Portal) scripts.

[admin]

It is called multicastRpc() in Python (Portal) scripts.

Starting in Portal 2.2 we have added support for using mcastRpc instead of multicastRpc to help prevent confusion.