MQTT: A Conceptual Deep-Dive
ably.io
MQTT: A Conceptual Deep-Dive
1–10 of 61 posts
Re: MQTT: A Conceptual Deep-Dive
#2Hi, interesting article.
Anyone care to expound on this part:
>>> and without any way to distinguish a deliberate disconnection from a transient network issue
Re: MQTT: A Conceptual Deep-Dive
#3Hi, 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.
Re: MQTT: A Conceptual Deep-Dive
#4Hi, 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.
Re: MQTT: A Conceptual Deep-Dive
#5"Designed for at most once, at least once and exactly once message delivery"
Exactly once message delivery cannot be guaranteed from a theoretical point of view (if it does exist then the Two Generals Problem can be solved, which has been proven to not have a solution). I don't know how MQTT can get around that, especially in an environment where transient network issues are expected.
Re: MQTT: A Conceptual Deep-Dive
#6"Designed for at most once, at least once and exactly once message delivery" Exactly once message delivery cannot be guaranteed from a theoretical point of view (if it does exist then the Two Generals Problem can be solved, which has been proven to not have a solution). I don't know how MQTT can get around that, especially in an environment where transient network issues are expected.
Well, there's a confirmation sequence that's basically a three-phase commit.
Re: MQTT: A Conceptual Deep-Dive
#7One of the best features of MQTT that is often overlooked is that the topics are created on the fly and also destroyed on the fly. The protocol does not require the server to maintain topics lists (assuming no retained messages). The server therefore scales based on the throughput and the number of clients (and their subscriptions) but not the size of the topic tree. The topic tree designer is therefore free to use enormous topic spaces with billions of topics if they so desire.
Re: MQTT: A Conceptual Deep-Dive
#8"Designed for at most once, at least once and exactly once message delivery" Exactly once message delivery cannot be guaranteed from a theoretical point of view (if it does exist then the Two Generals Problem can be solved, which has been proven to not have a solution). I don't know how MQTT can get around that, especially in an environment where transient network issues are expected.
Clients can choose to ignore multiple deliveries of the same message. They keep the message id around until they get an acknowledgement from the server that it won't be sending any more of that message. This is part of the protocol.
What it doesn't really guarantee is the order, which requires even more clever programming and more network exchanges.
Re: MQTT: A Conceptual Deep-Dive
#9Earlier quoted context omitted.
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?
Re: MQTT: A Conceptual Deep-Dive
#10"Designed for at most once, at least once and exactly once message delivery" Exactly once message delivery cannot be guaranteed from a theoretical point of view (if it does exist then the Two Generals Problem can be solved, which has been proven to not have a solution). I don't know how MQTT can get around that, especially in an environment where transient network issues are expected.
MQTT may take infinite time to deliver a message on an unreliable network, plus you assume error detection is perfect. I think this is why it doesn't violate two generals.