[FR] Add reconnection counter for the group in main/backup mode

[maxsharabayko]

When an active link is switched to a backup link, there should be a way for the application to know those switches are happening.
For example, a switch counter for the group.

Suppose we have Link A (main link) and Link B (backup link).
The initial value of the switch counter for a group is 0.

If Link A becomes (is detected as) unstable, Link B is activated, and the switch counter is incremented by 1.

If after some time Link A becomes stable again, and the transmission continues over this link, while Link B is back to idle, the switch counter is incremented. The condition is in force even if both links were used for transmission for the described period of instability.

TODO

• Define the API function to determine the switch count.
  • It should not be a group statistic.
  • It could be srt_group_data(..) function, but an additional argument would be required (GROUP_STATUS).
  • It could be a read-only socket option SRTO_SWITCH_COUNT.

[ethouris]

Reconnection is a term that doesn't exist in the implementation of the group, so this isn't possible to be implemented. Simply the SRT library doesn't have information it could use to calculate this statistical data.

Where's the problem: SRT knows only that the application requested a connection. If this connection breaks, it's removed. If the application connects to the same address again, SRT doesn't have any "history information" about the connection that was used once already. Even if you have used this connection in the past, for SRT this is always a "new connection".

Application is the only actor here that knows that particular connection is "renewed" and as well the only actor that undertakes the action of "reconnecting a broken link". The best place then to keep this information is in the application's connection table as this is the only place that can "identify the old and new link as the same".

[maxsharabayko]

"Reconnection counter" is an incorrect term I used in the title. However, the description talks about the "switch counter".

[ethouris]

Ok, so one more thing, just to make sure about the implementation.

If you have a situation that a link is considered unstable, the only reaction is activation of the highest priority idle link. Nothing more at the moment, and since this time there are two links used. Also there's nothing done about this fact for some initial period of time as the link is "temporary activated" and until this state is over, it's not considered parallel.

Only after this period is over, the temporary activation state is cleared and since this moment the link can potentially be treated as parallel. USUALLY though if the link was really broken, this link will be likely removed before this check could be performed. It works then more-less this way (let's say that every line represents a single call of the sending function, just the number of these calls here is way less than in reality):

running/stable | idle
running/stable | idle
running/UNSTABLE | running/tmpactive <-- GROUPSTABTIMEO exceeded, link unstable!
running/UNSTABLE | running/tmpactive (no parallel links atm)
running/UNSTABLE | running/tmpactive
running/UNSTABLE | running/tmpactive
BROKEN | running/tmpactive <-- the stability problem resolved to broken link
... | running/tmpactive
... | running/stable <-- Temporary activation period is over

The question is, which exactly event should cause the counter to be increased?

Note also that in case of the "stability overreaction" the scenario is a little different:

running/stable | idle
running/stable | idle
running/UNSTABLE | running/tmpactive <-- GROUPSTABTIMEO exceeded, link unstable!
running/UNSTABLE | running/tmpactive (no parallel links atm)
running/stable | running/tmpactive <-- Stable again!
running/stable | running/tmpactive
running/stable | running/stable <-- Temporary activation period is over
running/stable | idle <-- Link silenced

I think this situation also deserves some stats to be collected, but if you only have a counter of activated links, these two situations would not be distinguishable.