You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If the ethernet link between the controller and a Milan device is down at the same time the device is sending the CONTROLLER_AVAILABLE message (to detect if the controller is still present), the controller will not be able to respond to it.
In this case the Milan device has to remove the controller from the registered list, and send a deregisterUnsol notification to it.
If the link is still down, the controller will miss this message and thinks it's still registered.
If the link goes back up before the ADP timeout, then the controller is in a state where it no longer receives notifications from the device, thinking it should.
The text was updated successfully, but these errors were encountered:
My opinion is that until 1722.1 has a proper solution to this race condition, the controller available message should be synchronized to the ADP ENTITY_AVAILABLE message, and it should require that 3 consecutive controller available messages be not responded to in a row before removing the controller from the registered list.
Thanks for your input Jeff, I think this is a very good easy to change modification that should be proposed to the Milan working group (at least until 1722.1 handles it properly). The current Milan specification says the Entity should send a CONTROLLER_AVAILABLE only once every 60 seconds.
I was thinking of partially handling this issue on the controller side (until better solution) by re-registering every now and then.
If the ethernet link between the controller and a Milan device is down at the same time the device is sending the CONTROLLER_AVAILABLE message (to detect if the controller is still present), the controller will not be able to respond to it.
In this case the Milan device has to remove the controller from the registered list, and send a deregisterUnsol notification to it.
If the link is still down, the controller will miss this message and thinks it's still registered.
If the link goes back up before the ADP timeout, then the controller is in a state where it no longer receives notifications from the device, thinking it should.
The text was updated successfully, but these errors were encountered: