bridge & client relationship

[korda]

On the large network we have several computers (w/connected bridge nodes) monitoring network's status.
All client software is identical, but the master PC only sending RPCs to update network status, all others client programs in the listen-only mode.
We store each node data on the master PC w/node's MAC.
In case with bridge nodes, we can see them all on the network, but we do not know which bridge is connected to which PC. They all shown as bridges w/different MACs.
Question - how to differentiate "local" (to this PC) bridge from remotely connected bridge?
Thank you

[korda]

Forgot to mention that I am aware of the vmStat (TTL=1) option. Does it guaranty that the next arrived message will be from the locally connected node? I think I know that the answer is negative...

[mgenti]

Sending a multicast vmStat with a TTL of 1 will cause only the locally connected bridge node to respond back with a tellVmStat. This is actually the way that Portal determines which node it is attached too.

[korda]

I have tried reading more of "SNAP Reference Manual" ver 2.1 on the subject of global ping and found that the document does not really describe all parameters going in to the vmStat() call. I could not find any reference to "Global Ping" functionality for example. I also would like to see this call from a traffic minimization stand point. Can you make your suggestion please? We were using parameter 5 to return the node name, but we do not really care for its name. Which call generates minimal return message? Is the second parameter "6" only works as time window in combination with 5(VM_NAME)? What is MAX value of time window?

This is what in the manual (page 62)

vmStat(statusCode, args…) – Back door used by Portal

This is in our client code:

proxy.mcastRpc(this.getSnapNetAddr(), new byte[] { 0, 1 }, 5, "vmStat", new object[] { 5, 6 });


Second,
9=VM_SCAN - what is the scan window duration used for channel power calc? You kind of hinting in the manual that we need to do AVG ourself...
This what makes Link Quality for VM_NAME call almost useles for us, because of it instantanious nature, numbers jump all over.

[mgenti]

I could not find any reference to "Global Ping" functionality for example.

The global ping is not a builtin snappy function which is why it is not mentioned in the SNAP Reference Manual. It is just a multicast RPC calling the vmStat method with the VM_NAME and spread time as a parameter.


I also would like to see this call from a traffic minimization stand point. Can you make your suggestion please? We were using parameter 5 to return the node name, but we do not really care for its name. Which call generates minimal return message? Is the second parameter "6" only works as time window in combination with 5(VM_NAME)? What is MAX value of time window?


Unless you are using very long names for your units I'm not sure you will notice a difference using different arguments when calling vm_stat. I would look at what information you would find more useful than the name and ask for that information when doing your global ping.

You can use the time window parameter with any of the vm_stat calls and the maximum value is 255.


Second,
9=VM_SCAN - what is the scan window duration used for channel power calc? You kind of hinting in the manual that we need to do AVG ourself...
This what makes Link Quality for VM_NAME call almost useles for us, because of it instantanious nature, numbers jump all over.

Are you trying to determine what channel is best to use? Link quality returns the dbm of the last received packet where vm_scan will listen for energy on all channels and return that information.

[korda]

I think it would be very useful to have a scan done to figure out channel power level. How reliable or useful this option and how long does RF engine listens each channel?
Is there any averaging done for the time interval?

[mgenti]

Is there any averaging done for the time interval?

This particular SNAPpy function is implemented by the radio we are using in the RF Engine which takes a measurement for 128us per channel and returns the average power per channel.