5 ms·

Hi, interesting article. Anyone care to expound on this part: >>> and without any way to distinguish a deliberate disconnection from a transient network issue

• blackflame7000 7y ago
  Because MQTT is optimized for low-bandwidth environments, it only has a limited number of error responses. Therefore, when a connection has been established, there is no way to distinguish a network issue from a forced disconnect.
  • flipper65 7y ago
    that is not strictly true for the statement in the article. Deliberate disconnects can be identified by implementing tombstoning, in which a connected node sends an epitaph message to the channel prior to disconnecting.
    • bdamm 7y ago
      Are you referring to the "will" feature of the protocol (as in 'last will and testament') in which the server sends a message to a topic on the client's behalf because it disconnected, or are you referring to the client simply sending a message before disconnecting as a definition of the client's behavior?
    • rad_gruchalski 7y ago
      Yes, but that is not defined by the protocol. MQTT does not have such a mechanism. That’s a custom solution.
      • deleted 7y ago
        [deleted]
      • rad_gruchalski 7y ago
        To clarify on the last will, as there was a comment here (and a downvote to my parent comment, thanks for that, by the way...), comment since then deleted. Last will is given to the broker at connect time. It doesn’t tell the broker that a disconnect is / isn’t deliberate. Last will has nothing to do with the reasoning for disconnect. It tells the broker what to do in case of a disconnect.
        • blackflame7000 7y ago
          It's highly annoying when you get downvoted so close to 500 where you earn the coveted ability. Furthermore, you are correct so enjoy some karma :)
    • blackflame7000 7y ago
      You are talking on the phone. The line goes dead. Were you hung up on or was the call dropped? Either way, you aren't talking to anyone anymore so your messages aren't getting through.
      • nostrebored 7y ago
        This isn't a great analogy. Telephony has a well defined way to determine disconnect origin. Using SIP it's quite easy to determine the direction a bye comes from.
        • blackflame7000 7y ago
          I think you missed the point because it's irrelevant if Telephony has the capability. MQTT does not and there is no way to send a message once disconnected (Telephony included). The best you can do is preemptively say, "Do X if I get disconnected". X could be "Reconnect if not intentional" but if it was a network issue, you might perceive the lack of reconnects as an intentional hangup when really its network issues. Going back to the OP, MQTT has no way to distinguish intentional vs unintentional disconnects from the client(subscriber) prespective.
• Arnavion 7y ago
  Clients can optionally send a DISCONNECT packet to signal that they intend to disconnect. However there is no equivalent for the server. So if a server drops the connection, the client will only find out when it sends its next PING or other packet. Edit: Also, it's worth noting that MQTT 5 greatly expands on the error reasons that the server can send to the client if it wants to indicate precisely why it's dropping the client.