search

eclipse-sparkplug / sparkplug

Sparkplug
Eclipse Public License 2.0
114 stars 39 forks source link

bdSeq number when sending new birth message #199

Closed pietercardoen closed 2 years ago

pietercardoen commented 2 years ago

Dear

The specification states that: "The NDEATH message MUST include the same bdSeq number value that will be used in the associated NBIRTH message. This is used by Host Applications to correlate the NDEATH messages with a previously received NBIRTH message."

If you have a node which transmits a new BIRTH message while being alive:

then this node needs to reuse the bdSeq value. Only when the node had been disconnected resulting in an NDEATH message being transmitted, then the bdSeq value may be incremented.

Is this valid?

Llorx commented 2 years ago

If you reuse the bdSeq in the new rebirth request, at least ignition will keep on asking the rebirth command again and again. It expects another bdSeq.

What I do is reconnect, so I can send another last will. Not optimal, but at least Ignition will accept that.

On the other hand, adding new metrics is a pain in the ass and you should reconnect again, which is also a bad thing. I had to avoid Node metrics and go always with devices.

jbrzozoski commented 2 years ago

Ignition will accept another NBIRTH with the same bdSeq repeated. It only complains and requests another rebirth if the sequence number doesn't reset to 0. (bdSeq and sequence are two separate counters.)

However, you are correct about adding/removing metrics on the node level being problematic. Our implementation handles this by aborting the MQTT connection (which triggers the LWT NDEATH message) and reconnecting with a new bdSeq and the updated metric list. Our state machine already handled reconnecting on accidental disconnects, so we just create one intentionally.

Llorx commented 2 years ago

Oh that's true! In the end it was the seq not resetting! My bad.

The only problem I see here is adding new metrics, and that the last will not having the same bdSeq if you don't reconnect and reset the last will. We also reconnect and it works as expected, just that the spec don't states this on the NBIRTH section and could lead to an error.

wes-johnson commented 2 years ago

I'll add a non-normative statement to clarify this in chapter 6