UDP unicast slave clock stuck in UC_HAVE_ANN after restart due to missing unicast_client_state_changed()

[liangtu1]

This issue occurs probabilistically with the default logQueryInterval=2, and becomes easier to reproduce when set to 3 or higher.

A unicast slave clock restarts rapidly while in the S2 steady state.
The master clock continues to send Announce/Sync messages because the subscription has not yet expired.

Anomalous Timing Sequence 1:

1. The slave clock receives Announce/Sync messages, the state changes to PS_UNCALIBRATED. the unicast_client_state remains in UC_WAIT.
2. When the logQueryInterval expires, Signalling occurs, and unicast_client_state changes to UC_HAVE_ANN.
3. When EV_MASTER_CLOCK_SELECTED triggers the state transition from PS_UNCALIBRATED to PS_SLAVE:
   p->unicast_state_dirty=true,
   However, c->sde is not set to 1.
4. Consequently, unicast_client_state_changed() is not triggered. The unicast_client_state gets stuck in UC_HAVE_ANN, causing loss of synchronization.

Anomalous Timing Sequence 2:

1. The slave clock receives Announce/Sync messages, the state changes to PS_UNCALIBRATED. the unicast_client_state remains in UC_WAIT.
2. When EV_MASTER_CLOCK_SELECTED triggers the state transition from PS_UNCALIBRATED to PS_SLAVE:
   p->unicast_state_dirty=true,
   However, c->sde is not set to 1.
   Since logQueryInterval is configured to a large value, the unicast_client_state remains in UC_WAIT.
   Even if c->sde were set to 1, unicast_client_state_changed() would still be ineffective at this stage.
3. When the logQueryInterval expires, Signalling occurs, and unicast_client_state changes to UC_HAVE_ANN.
4. Consequently, unicast_client_state_changed() is not triggered. The unicast_client_state gets stuck in UC_HAVE_ANN, causing loss of synchronization.

Final Stuck State:
PS_SLAVE
c->sde=0
unicast_state_dirty=true
UC_HAVE_ANN
The master clock stop sending Sync messages when the subscription expires.

[codingsimpleton]

Than You