Discuss the disconnection changes

[amoss]

Summary

• Meet with the cloud team.
• Discuss https://github.com/netdata/docs/pull/143/files
• Check implementation is available in libmosquitto.
• Create issues to implement.

[amoss]

It looks like the appropriate call on the agent side is https://mosquitto.org/api/files/mosquitto-h.html#mosquitto_will_set. The relevant part of the comments seems to be:

This must be called before calling mosquitto_connect

This implies that we need to know the topic in advance so we need to decide on naming for fixed topics.

[amoss]

A consequence of setting the LWT before making the connection is that we cannot flip the message between graceful disconnection and unexpected as described in the docs PR.

[underhood]

Should be possible... LWT is sent only on ungraceful disconnect. If we are going to disconnect because we want to we send manually the disconnect_grateful message and LWT is not sent.

I am basing this of this documentation:

In MQTT, you use the Last Will and Testament (LWT) feature to notify other clients about an ungracefully disconnected client. Each client can specify its last will message when it connects to a broker. The last will message is a normal MQTT message with a topic, retained message flag, QoS, and payload. The broker stores the message until it detects that the client has disconnected ungracefully. In response to the ungraceful disconnect, the broker sends the last-will message to all subscribed clients of the last-will message topic. If the client disconnects gracefully with a correct DISCONNECT message, the broker discards the stored LWT message.

You are right about we need to know topic in advance of connection for LWT message.

[underhood]

I checked also MQTT 5 docu and it seems to remain same:

If the Will Flag is set to 1 this indicates that a Will Message MUST be stored on the Server and associated with the Session [MQTT-3.1.2-7]. The Will Message consists of the Will Properties, Will Topic, and Will Payload fields in the CONNECT Payload. The Will Message MUST be published after the Network Connection is subsequently closed and either the Will Delay Interval has elapsed or the Session ends, unless the Will Message has been deleted by the Server on receipt of a DISCONNECT packet with Reason Code 0x00 (Normal disconnection) or a new Network Connection for the ClientID is opened before the Will Delay Interval has elapsed [MQTT-3.1.2-8].

Situations in which the Will Message is published include, but are not limited to:

An I/O error or network failure detected by the Server.
The Client fails to communicate within the Keep Alive time.
The Client closes the Network Connection without first sending a DISCONNECT packet with a Reason Code 0x00 (Normal disconnection).
The Server closes the Network Connection without first receiving a DISCONNECT packet with a Reason Code 0x00 (Normal disconnection).

If the Will Flag is set to 1, the Will Properties, Will Topic, and Will Payload fields MUST be present in the Payload [MQTT-3.1.2-9]. The Will Message MUST be removed from the stored Session State in the Server once it has been published or the Server has received a DISCONNECT packet with a Reason Code of 0x00 (Normal disconnection) from the Client [MQTT-3.1.2-10].

The Server SHOULD publish Will Messages promptly after the Network Connection is closed and the Will Delay Interval has passed, or when the Session ends, whichever occurs first. In the case of a Server shutdown or failure, the Server MAY defer publication of Will Messages until a subsequent restart. If this happens, there might be a delay between the time the Server experienced failure and when the Will Message is published.

[cosmix]

Hello guys. We do know the topic. It's /agent/<ID>/outbound/meta.

[cosmix]

A consequence of setting the LWT before making the connection is that we cannot flip the message between graceful disconnection and unexpected as described in the docs PR.

@amoss Could you please explain why you think that's the case?

[cosmix]

Should be possible... LWT is sent only on ungraceful disconnect. If we are going to disconnect because we want to we send manually the disconnect_grateful message and LWT is not sent.

That's correct @underhood ! I clarified the point in the docs repo, lest it causes more confusion.

[amoss]

A consequence of setting the LWT before making the connection is that we cannot flip the message between graceful disconnection and unexpected as described in the docs PR.

@amoss Could you please explain why you think that's the case?

I think you are working from outdated comments - as I commented in the docs repo this has already been explained and resolved.

[cosmix]

There's no indication of 'outdated' anywhere, so that'd be impossible to know. Good to hear it's resolved!

[amoss]

How about this for the expected case:

{ "type":"disconnection", version=1, "reason":"shutdown" }

and this for the LWT:

{ "type":"disconnection", version=1,"reason":"unexpected" }

?

[cosmix]

@amoss outdated comments etc. See the docs repo for the JSON structure. :)

[amoss]

Meeting cancelled, we have an agreement about how to implement this.