[jhallenworld]

He says:

"Unfortunately, MQTT defines this assurance model only for the publish gesture and not for its own, inherent operations.."

OK, but then says:

"That means the client is forced to retry under any such circumstances. The specification already anticipates this with making subscriptions effectively idempotent and requiring that a subscribe command matching an existing subscription must be replaced by a new subscription and that the message flow must not be interrupted. "

So what exactly is the problem? If the client doesn't get the SUBACK it retries. The server has to deal with it. If the server gets a SUBSCRIBE, it has to be durable because the client might have received the previous SUBACK.

Why add one more turn around by acking the ack? This seems like extra complexity for no reason.

Also he talks about lack of flow control:

"Not having any flow control can get fairly dicey when there is significant work to do for processing a message and there might be several different subsystems on the receiving end of the MQTT connection where the work differs."

But there is flow control: it's TCP. Do not read from the TCP stack unless you can handle the message, then the flow control will work. On the other hand there is no concept of trying to multiplex multiple streams over one connection (where then you start to worry about head of line blocking). If you need this, open a different TCP connection for each stream. This is not an unreasonable design choice to make...

[Groxx]

How do you know if you can handle the message, until you read the message? Or is MQTT's flow control inherently insufficient for cases like that?

Basic example, say for a chat client: to ensure delivery, you probably want to read the message, save it to a database, then confirm receipt. Is that possible, or would that delayed-ack have to be done via some other means?

[jhallenworld]

That's the normal use case for QoS 1 and 2 messages: the client must acknowledge each received message otherwise the server will try to resend it. From the MQTT V3.1 Protocol Spec: http://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/mq...

What you don't want to do is read everything offered into memory faster than you can write it to disk / database. You could potentially fill the memory until you run out and crash. Instead control the flow by not reading until you are finished with the previous message (or better, allow N unacknowledged messages to be read, where N is just enough so that the application is as fast as it can be).