#139 Check SeqNums of connected edges and devices and trigger a ReBirth

0.0.0.0: SparkplugB Peer-2-peer Edge Node
open
nobody
None
2022-11-05
2021-05-15
hermsen
No

We must build a solution into the Primaryhost which checks the correctness of the received SeqNums, BdSeqs and triggers the corresponding Edge to ReBirth if Necessary

Check Validity of BdSeq Sequence of individual edges and devices against Birth certificate and ask ReBirth if flawed.
check Validity of SeqNum sequences per individual Edge and device and ask ReBirth if flawed.

Checking the validity has a high priority and must be rigid and forgiving at the same time as the ReBirth mechanism is triggered through this.

Discussion

more posts ...

  • hermsen

    hermsen - 2021-10-23

    seems a mechanism with little room for forgiveness.
    any seqnum not received in exact order will trigger a ReBirth..

    Idea
    Accept 'out of sequence' payloads within a certain "deadband"
    say we receive 9, 10, 12, 11, 13, 15, 14 we normally trigger a ReBirth, but we could allow to accept this out of sequence behavior without any course of action.

    This 'deadband' could be set by the user as a non normative behaviour i.e. "allow_out_of_sync_payload_deadband = 1 (0 = no, 1 or 2 = yes).

    this deadband works as an extra (non normative) safety net while we fix the real issue also, sending wrong seqnum sequences.

    a deadband of 1 means we allow an offset of maximum 2 between the last received seqnum and the current received seqnum with the exception of round robin borders.

    passing example1: LastSeqNum = 5, recv Seqnum = 6, deadband =1
    okay := IsValid( LastSeqNum, RecvSeqNum, DeadBand); // TRUE

    passing examples
    LastSeQ =20, CurSeq =22, DeadBand =2 // TRUE
    LastSeQ=20, CurSeq =18, DeadBand =2 // TRUE
    LastSeq=255, CurSeq= 2, deadband =2 // TRUE
    LastSeq=255, Curseq= 253, deadband=2 // TRUE
    255, 1, 2 // TRUE

    Failing Examples
    LastSeQ= 5, CurSeq =7, deadband =0 // FALSE
    5, 8, 2 // FALSE
    5, 3, 0 // FALSE
    5, 2, 2 // FALSE
    255, 2, 0 // FALSE

     

    Last edit: hermsen 2021-10-24

  • hermsen

    hermsen - 2022-01-09

    I wrote "FB_SeqHandler" accompanied by tests. Currently, the "out of sync" test implemented is unforgiving. It rejects anything out of sync i.e. 1 -> 2 -> 4 will yield a rejection. The FB can be expanded by an extra mechanism which will "widen" the acceptance window i.e. an out of sync of X payloads (currently NONE).

    "FB_SeqHandler" implements an interface called ISeqHandler. This interface implements currently a single method:
    CheckRecvSeq( Seq := RecvSeq ); Which returns a BOOL. I.e. it tests if RecvSeq is "in Sequence" or not.

    This FB should be usable for both SeqNums and BDSeq's.

    I will now add a property deadband get/set in order to make
    the "out of sync" test more forgiving is needed or wanted.
    Though my suggestion is to keep it default as tight as possible.

    Names for this property: OutOfSyncAcceptanceWindow (set/get) Rather long but does as advertised on the tin.

     

    Last edit: hermsen 2022-01-09

  • hermsen

    hermsen - 2022-01-15

    The spec helped to build the new FB_SeqHandler which is taking form: a state machine which checks the incoming sequence and compares it with the previous sequence. When the difference between them is too big (≥2) then the statemachine will start its timeoutwindow countdown. when that window has elapsed the FB asks for a rebirth. If the sequence gets repaired within this window however the sequencer continues its normal behavior.

    Some thing which need to be resolved is a initialisation after rebirth

     

    Last edit: hermsen 2022-01-15

  • hermsen

    hermsen - 2022-05-03

    The new Handler is implemented in the Host libray and base tests have been provided in the unittest project. We should add more tests in order to prove the FB is performing as expected.

     

Log in to post a comment.