Question: Disabling STATE from non-Primary Host Applications

jbrzozoski commented 1 week ago

What do you want to know?

As of right now, the spec includes this requirement: "Sparkplug Host Applications MUST publish STATE messages denoting their online and offline status."

But there are many instances when a host application would need to disable STATE publication. This needs clarification in some way. I think breaking that one requirement into two, something like:

Sparkplug Host Applications MUST support the ability to publish STATE messages denoting their online and offline status.
Sparkplug Host Applications SHOULD support the ability to disable STATE message publication.

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

None

Accept EFTL Terms

[X] I agree to the terms of EFTL

SteveBeadle commented 5 days ago

I agree with this issue.

Additional/alternative:

Change:

[tck-id-intro-sparkplug-host-state] Sparkplug Host Applications MUST publish STATE messages denoting their online and offline status.

to:

[tck-id-intro-sparkplug-host-state] Sparkplug Primary Host Applications MUST publish STATE messages denoting their online and offline status.

joshwolf-canary commented 5 days ago

@jbrzozoski - could you elaborate on situations in which host applications should not publish their state?

joshwolf-canary commented 5 days ago

@SteveBeadle - On a server with multiple hosts (subscribing clients) and multiple publishing clients (data producers), the host that is "primary" could be different for each publishing client. By having each host application publish its state by default, the user configuring the publishing client can simply designate the host that is primary for that publisher.

jbrzozoski commented 5 days ago

I see at least two cases where not publishing STATE is useful.

As much as I know it's a client issue and not a server issue, there are Sparkplug edge nodes that only care if they see a host ID, but provide no way to filter on which host ID. We have to support a (thankfully decreasing) number of those in our MQTT cloud and as a safe-guard we setup an MQTT ACL that only allows our preferred host applications to publish STATE. Long term, this requirement should decrease as more edge nodes implement the ability to specify a host ID to look for, but it may always linger.
For debug monitoring or backup systems, host applications would want to monitor Sparkplug traffic without affecting store-and-forward behavior and with a "minimal interference" implementation. This ties into into the often-requested "data diode" concept, where you could make a host application that has NO publish permissions on a broker. (Yes, I know that has issues with not being able to request BIRTH messages, but we can tackle that issue separately from this.)

eclipse-sparkplug / sparkplug