MQTT: A Conceptual Deep-Dive • Hacker News Board

Re: MQTT: A Conceptual Deep-Dive

#31

Post by rad_gruchalski » Thu, Jul 25, 2019, 9:04 PM UTC

rad_gruchalski wrote: post #17

flipper65 wrote: post #4

Earlier quoted context omitted.

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.

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.

Re: MQTT: A Conceptual Deep-Dive

#32

Post by Arnavion » Thu, Jul 25, 2019, 9:30 PM UTC

jonquark wrote: post #29

swiftcoder wrote: post #12

Earlier quoted context omitted.

Even with the 3-phase commit, almost every production MQTT broker sacrifices the "exactly once" requirement to achieve reasonable performance.

I'm not sure this statement is accurate. Certainly the MQTT broker I work on (IBM WIoTP Message Gateway) and a number of our competitors support QoS 2 in production (though I am aware a number of brokers don't support it).

I imagine there are servers that drop QoS 1 or 2 messages that never complete the protocol after X amount of time, so that they don't keep consuming resources indefinitely.

MQTT 5 standardizes this by adding a message expiry interval field, though even there it's opt-in by the publisher and defaults to forever.

Re: MQTT: A Conceptual Deep-Dive

#33

Post by nostrebored » Thu, Jul 25, 2019, 9:43 PM UTC

blackflame7000 wrote: post #21

flipper65 wrote: post #4

Earlier quoted context omitted.

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.

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.

Re: MQTT: A Conceptual Deep-Dive

#34

Post by will0 » Thu, Jul 25, 2019, 9:50 PM UTC

Oh hey, I work with Andy Stanford-Clark

Re: MQTT: A Conceptual Deep-Dive

#35

Post by noobiemcfoob » Thu, Jul 25, 2019, 10:41 PM UTC

Can someone justify MQTT over HTTP and WebSockets?

Before you jump down my throat, I've used all three protocols to a fair degree. MQTT was the most painful, and without strong justification, what's the point? I always read a bandwidth usage justification, but if that's the case, someone should be able to tell me the number of overhead bytes saved using MQTT over WebSockets.

Re: MQTT: A Conceptual Deep-Dive

#36

Post by [deleted] » Thu, Jul 25, 2019, 10:51 PM UTC

noobiemcfoob wrote: post #35

Can someone justify MQTT over HTTP and WebSockets? Before you jump down my throat, I've used all three protocols to a fair degree. MQTT was the most painful, and without strong justification, what's the point? I always read a bandwidth usage justification, but if that's the case, someone should be able to tell me the number of overhead bytes saved using MQTT over WebSockets.

[deleted]

Re: MQTT: A Conceptual Deep-Dive

#37

Post by googlesux » Thu, Jul 25, 2019, 10:56 PM UTC

noobiemcfoob wrote: post #35

Can someone justify MQTT over HTTP and WebSockets? Before you jump down my throat, I've used all three protocols to a fair degree. MQTT was the most painful, and without strong justification, what's the point? I always read a bandwidth usage justification, but if that's the case, someone should be able to tell me the number of overhead bytes saved using MQTT over WebSockets.

Publish and subscribe method ez for small scale devices

Re: MQTT: A Conceptual Deep-Dive

#38

Post by Arnavion » Thu, Jul 25, 2019, 10:57 PM UTC

noobiemcfoob wrote: post #35

Can someone justify MQTT over HTTP and WebSockets? Before you jump down my throat, I've used all three protocols to a fair degree. MQTT was the most painful, and without strong justification, what's the point? I always read a bandwidth usage justification, but if that's the case, someone should be able to tell me the number of overhead bytes saved using MQTT over WebSockets.

(At first I thought you were asking about MQTT-over-websockets, but you're actually asking about MQTT vs websockets.)

I believe MQTT implementations tend to be smaller, which is why it's popular for IoT devices. Both HTTP and WebSockets are much more diverse specs, so a generally available implementation might have a lot of features the device never uses but still occupy disk and memory (multiple kinds of headers and their semantics, data encodings, etc).

Re: MQTT: A Conceptual Deep-Dive

#39

Post by theflyinghorse » Thu, Jul 25, 2019, 10:58 PM UTC

noobiemcfoob wrote: post #35

Can someone justify MQTT over HTTP and WebSockets? Before you jump down my throat, I've used all three protocols to a fair degree. MQTT was the most painful, and without strong justification, what's the point? I always read a bandwidth usage justification, but if that's the case, someone should be able to tell me the number of overhead bytes saved using MQTT over WebSockets.

Decoupling between publishers and subscribers is the biggest one. Being able to store messages while consumer is down. Last will messages are very convenient. Ability to authorize on topic level.

All of that is very useful in my use case (networking and IoT equipment in the middle of nowhere in rough conditions that can go down a fair amount).

Re: MQTT: A Conceptual Deep-Dive

#40

Post by blackflame7000 » Thu, Jul 25, 2019, 11:00 PM UTC

nostrebored wrote: post #33

blackflame7000 wrote: post #21

Earlier quoted context omitted.

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.