| Re: [sparkplug-dev] Sparkplug Spec Project Team Meeting - Meeting Notes - 09 March 2021 |
Hi all,
thank you for the summary.
I do think that the HA section needs further discussion, I'm happy to provide additional viewpoints on that. I do not believe that clustering does not guarantee in-order delivery, but this might be implementation dependant. Most MQTT brokers I'm aware of (commercial and open source) that support clustering should give the same guarantees a single broker instance would give. In fact, an ordered topic guarantee is required for MQTT 3.1.1 and MQTT 5 compatibility of any MQTT broker. If bridging is meant here instead of clustering or other HA possibilities, then this might be a different conversation (as this could lead to out of order messages).
I'm realizing based on this discussion that we also need a profile for brokers, as there are multiple implementations and in order to be Sparkplug compliant not all MQTT 3.1.1 features need to be supported. This also would give Sparkplug end users the confidence that a specific broker software is 100% Sparkplug compliant. I'm happy to help with creating a broker profile and a TCK implementation. This could then also help us getting set up for MQTT 5 (optional) support.
Thanks,
Dominik
--
Dominik Obermaier | CTO
phone +49 871 97506300 | mobile +49 171 2211168
HiveMQ GmbH | Ergoldinger Str. 2a | 84030 Landshut | Germany
Registergericht Landshut | HRB 8906
Geschäftsführer: Christian Götz | Dominik Obermaier
On 10 Mar 2021, at 23:09, Nathan Davenport wrote:
Hi all,
Please find the meeting notes from yesterday’s Sparkplug Spec Project Team Meeting below.
Sparkplug Spec Project Team Meeting - Meeting Notes - 09 March 2021
- Attendees (7)
- Chad Kienle
- Frederic Desbiens
- Ian Craggs
- Ilya Binshtok
- Nathan Davenport
- Travis Cox
- Wes Johnson
- Progress Report
- Chapter 1 – 5 Clean-up and normative statements added
- Count of tests that need to be created is getting larger via normative statements (~15 tests)
- Chapter 8 (Clustering/HA) – may need to collaborate with Dominik @ HiveMQ
- Cirrus Link tends to discourage the use of Clustering WRT in-order delivery as it is not guaranteed
- Ian to discuss w/ caveats with Dominik
- MQTT Engine has code to work around out-of-order messages. Kafka can also be used to reorder / ensure order...
- This content could go outside of the core doc in a supplemental doc (e.g., implementation guide)?
- Misc Open Issues
- QoS
- Edgenode WILL messages not called out to be QoS1
- Why not QoS2?
- Subscription QoS also not addressed within the spec
- bdSeq number handling is not super clear and needs to be better described
- Session state WRT to Birth/Death messages is not clear to all
- MQTT v5 Support (Issue #75):
- Ensure State messages, retained and QoS flags
- MQTT Distributor doesn’t support v5 (HiveMQ broker can be used here for validation)
- Someone with Cirrus Link can take this task and do a quick sanity test (Nathan @ Cirrus Link will pick this up)
- Flag in Paho to specify 5.0?
- TCK tests driven via spec annotations... then how do we run specific TCK tests for a specific profile against an implementation?
- Portion of TCK gets executed (via profile: edge, host, primaryhost)...
- Client would then perform operations against it as defined by some test script/scenario annotation that enforces order
- No previous work that we can follow, so therefore no hard constraints on implementation
- Assertion annotations ordered? Maybe they should be?
- We should minimize constraints on potential compatible implementations... less order is better...
- Drive order via test script/scenario annotation?
- Current Goal:
- Big push to finish up the spec
- Security & HA section needs amendments...
Thank,
Nathan
_______________________________________________
sparkplug-dev mailing list
sparkplug-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/sparkplug-dev