Search code examples
unetstack

How to find the address and location coordinates of the neighbouring nodes?

I am implementing an algorithm in UnetStack and I am trying to write an agent to get the required parameters from the neighbouring nodes. I want to send a broadcast message to all neighbouring nodes and these neighbouring nodes should reply with their address and location coordinates.How can I implement this ? I know that I need to access the NodeInfo service of the neighbouring nodes but not sure what servive / protocol to follow for broadcast transmission and reception.

Solution

  • There are several ways to do this:

    1. You can send RangeReq with requestLocation set to true. This requests a peer node to transmit it's location coordinates back. On success, you'll receive a RangeNtf with the location field filled in.

    Example shell session using a 2-node network:

    > ranging << new RangeReq(to: 31, requestLocation: true)
AGREE
ranging >> RangeNtf:INFORM[from:232 to:31 range:999.99976 offset:-348702972
 rxTime:2042489677 peerLocation:1000.0,0.0,-15.0]
    1. You can use the remote service to request the information. To do this, make sure that the responding node has remote control enabled (remote.enable = true). Then send it a request to send it's location to you, and you'll receive it shortly as a RemoteTextNtf.

    Example session:

    > rsh 31, '?node.location'
AGREE
[31]: [1000.0, 0.0, -15.0]
    1. You can write your own agent running on each node, and listen for specific DatagramNtf with your own special PDU, and respond to those with the information gotten from the node info service. This is most flexible, but will need you to develop the agent from scratch.

    Do note that both 1 and 2 are not a broadcast request, but requests to specific nodes. If you wanted to do something similar to option 2 with broadcast, you can do it:

    > rsh 0, '?node.location'
AGREE
[31]: [1000.0, 0.0, -15.0]

    but bear in mind that this mat not work well with network congestion if all nodes try to respond immediately. If that proves to be a problem, option 3 might be your solution to schedule the responses to manage the network load.