Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Must NBIRTH sequence number always be '0'? #373

Open
SeppPenner opened this issue Mar 22, 2024 · 1 comment
Open

Must NBIRTH sequence number always be '0'? #373

SeppPenner opened this issue Mar 22, 2024 · 1 comment

Comments

@SeppPenner
Copy link

A question from my community under SeppPenner/SparkplugNet#57:

For me it is not quite clear, if the NBIRTH sequence number must always be '0' as it is currently implemented. The SparkplugB 3.0.0 documentation is ambiguous. In chapter 6.4.19 the sequence number "MUST have a value between 0 and 255". But in chapter 12.13. it is written "The NBIRTH MUST include a sequence number in the payload and it MUST have a value of 0."

The following theoretical example shows wrong data if the NBIRTH sequence number is always '0':
Let's assume, the 'bdseq' remains the same. The following messages are sent:
-> NBIRTH (seq=0)
-> NDATA (seq=1)
<- receiving NCMD "Node Control/Rebirth"
-> NBIRTH (seq=0)
Now let's assume the host application receives the 2nd NBIRTH message before the NDATA message. As a result, the host application would process the NDATA message as the sequence number is higher than the sequence number of the 2nd NBIRTH. This may result in wrong data. Unless the timestamp is taken into account as well.

Hence my question: what is the correct behavior of NBIRTH sequence number from your point of view? Thank you very much for any thoughts.

So: How should the sequence number behave?

@ghocev1
Copy link

ghocev1 commented Mar 27, 2024

NBIRTH sequence number must always be 0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants