Hacker News Reader

Comment by cbluth | Hacker News Reader

Hi, interesting article.

Anyone care to expound on this part:

>>> and without any way to distinguish a deliberate disconnection from a transient network issue

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.

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.

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?

Yes, but that is not defined by the protocol. MQTT does not have such a mechanism. That’s a custom solution.

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.

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 :)

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.

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.

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.

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.

Reply on news.ycombinator.com