Question: [tck-id-message-flow-edge-node-birth-publish-will-message-payload-bdSeq] #593
Description
What do you want to know?
5.4 Edge Node Session Establishment
[tck-id-message-flow-edge-node-birth-publish-will-message-payload-bdSeq]
The Edge Node’s MQTT Will Message’s payload MUST include a metric with the name of bdSeq, the datatype of INT64, and the value MUST be incremented by one from the value in the previous MQTT CONNECT packet unless the value would be greater than 255. If in the previous NBIRTH a value of 255 was sent, the next MQTT Connect packet Will Message payload bdSeq number value MUST have a value of 0.
This question focuses on:
... value MUST be incremented by one from the value in the previous MQTT CONNECT packet...
Consider a scenario where EdgeNode attempts but FAILS to connect either at the TCP/IP layer or at the MQTT layer. When no TCP/IP connection is established, no MQTT CONNECT packet is transmitted. Do we retry with the same value of bdSeq or are we supposed to increment for each retry? My intuition is to retry with the same bdSeq value but I could see some diagnostic value, being able to identify potential issues when there is a gap between bdSeq in adjacent sessions. At the MQTT layer I suppose you could have a malformed packet, conflict with MQTT version, auth issue etc. If there is no MQTT session established, I don't think the bdSeq value would ever been seen by the broker.
I'd suggest an edit:
... the value MUST be incremented by one from the value in the previous MQTT CONNECT packet accepted by the broker, unless...
Is this related to a Sparkplug Listing request? If so, link the issue from https://github.com/eclipse-sparkplug/sparkplug.listings here.
No response
Version
3.0.0 (Default)
Accept EFTL Terms
- I agree to the terms of EFTL