What are the Node Manager's responsibilities regarding keeping track of "controlling components?"

I have a component that was implemented (by another programmer) in such a way that it attempts to look up the address of its controlling component with the Node Manager. This lookup always returns false because the component never does anything to "register" the controlling component with the Node Manager in any way. I don't even see any way for a component to inform the Node Manager of the address of any component to which it has granted control.

As far as I can tell, the problem is one of the following three:

1) The component should never be performing the lookup at all because "controlling components" are none of the Node Manager's concern.

2) The component is neglecting to properly register or "check-in" its controlling component with the Node Manager. (If so, how should it do so? A CHECK_IN message doesn't fit the bill.)

3) The Node Manager interface has neglected to define an appropriate "REGISTER_CONTROLLER_ADDRESS" message.

Which is the proper solution?

Actually... the answer is none of the above.

The Node Manager is, as you suspected, unaware of anything having to do with component controllers. What you are probably seeing is that the original programmer of the component is trying to be clever and build defensive mechanisms into the component's state machine. This is done because safety-critical applications need to ensure reliable communications between a controller and the controlled component. JAUS does not explicitly provide such a mechanism. Therefore, it is done by the application programmer within the state machine to protect against any loss of signal between controller and controlled component such as network loss, unexpected shutdown, etc.

Often what you will see is that if a component requires a "controller" it will check for said controller in the INIT or STANDBY state and then only proceed to READY when a connection to a controller is established. Then, in the READY state, the controlled component will continuously check that its controller exists on the System Tree. The function you are most likely seeing used is:

JausBoolean ojCmptLookupAddress(OjCmpt ojCmpt, JausAddress address)

This function takes the provided JausAddress and queries the NM for this address, returning True/False if the address is found in the SystemTree. This function also supports wildcards in any of the address fields, but I suspect that is not what is happening here. Regardless, that function does not deal with the fact that the address being queried is a controller or not, it simply returns the absence or presence of the given JausAddress in the SystemTree. Things exist in the SystemTree due to the Discovery mechanisms built into OpenJAUS and the use of the ReportHeartbeatPulse message, which is multicast out at 1Hz. Components are removed from the SystemTree if they are not heard from within a given timeout period (typically 3-5 seconds).

If that is indeed the function which you are using and it is returning false, then you should check the state of the SystemTree and see if the controlling component exists and is registered properly. You can visually inspect the SystemTree in the Node Manager by pressing the 't' key while running the ojNodeManager binary.

Actually, the component isn't doing anything particularly clever or defensive, it's just calling ojCmptHasController, which calls ojCmptLookupAddress.

I suspect that my OCU is not producing heartbeats as it is obligated to do.

The problem boils down to this: my non-OpenJaus-based OCU subsystem is properly receiving the Open-Jaus-based subsystem's multicast heartbeats, but the OJ subsystem is not receiving those of my non-OJ OCU.

Through experimentation, I have shown that my non-OpenJaus-based OCU subsystem is not to blame for the problem. With two instances of it running across our network, each one is able to receive the multicast heartbeats of the other, so I know that they are both capable of sending and receiving multicast messages properly.

It looks to me like the problem lies in your implementation of your multicastSocketReceive method. I don't fully understand the details of using Linux's socket implementation, so I could be wrong, but... In short, it looks to me like multicastSocketReceive "prefers" to read from its unicast socket to the exclusion of its multicast socket. That is, regardless of whether the multicastSocketDescriptor is valid, multicastSocketReceive will always ignore it and read from the unicastSocketDescriptor instead.

If you would be so kind, could you take a quick look at it to confirm or deny my suspicions? Thanks.

Happy to. I have fixed problems with the multicast socket implementation in the past. Can you attach a copy of the multicastsocket.c file that you are using? I want to make sure you have the latest changes.

Wow, I wasn't expecting such a rapid response. Thanks.

I have attached the multicastSocket.c that I am using. Except for the printf's I have scattered about for debugging, I have changed none of the code since I was given a complete distribution of OpenJaus in April.