Income buffer is to small for a payload sent with QoS1

[Jenkins]

Hello!

I cam currently thinking about the scenario, when income buffer is to small to get whole payload. If I understand currently, if message is being sent with QoS1we cannot just ignore it, because broker would eventually republish it again.

Friends, do you have any information how to deal with it?

[Dustin Sallings]

Specify your receive maximum to prevent messages that are too large from being sent to you.

--
To learn more about MQTT please visit http://mqtt.org
---
You received this message because you are subscribed to the Google Groups "MQTT" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mqtt+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mqtt/476973b0-81d4-4c36-a22a-c8e8f35d31a4n%40googlegroups.com.

[Jenkins]

Thanks for answering!

It makes sense, you are right, but I still want to include human error and a fact that broker will send something to big.

Of course whenever I decode header, I can "rewind" socket's buffer and get all the data, but it seem wrong since broker will republish payload.

Maybe someone knows about mechanism that would actually allows to "reject" message? So broker will be happy with received notification and app doesn't send puback, since it would be kind of a a lie.

[k...@dreamweasel.ca]

You don't say which version of MQTT you are using.

If you're using MQTT 3.1.1, you're kind-of stuck. MQTT 3.1.1 provides no "maximum packet size", and it provides no way to reject a QoS 1/2 PUBLISH packet. You're forced to disconnect and reconnect with "Clean Session = 1", to purge the too-big message (and everything else) from the broker's session state for your client.

If you're using MQTT 5, you can specify the "Maximum Packet Size". (Not the "Receive Maximum": the Receive Maximum controls the *number* of QoS 1/2 PUBLISH packets the broker is allowed to send to you before acknowledgment, not the packet *size*.) If the broker then insists on sending you a packet larger than the Maximum Packet Size, you're supposed to disconnect the connection with Reason Code 0x95 (packet too large). But, at that point, you're dealing with a non-conformant broker, so all bets on broker behaviour are off.

In MQTT 5, you can also reject individual PUBLISH by sending PUBACK (QoS 1) or PUBREC (QoS 2) for the Packet Identifier with a Reason Code ≥ 0x80, in which case the broker is not supposed to ever retransmit the PUBLISH of those messages. But, 0x95 is not an allowed Reason Code for PUBACK or PUBREC.

[Jenkins]

Thank you so much for your reply.

I am using https://github.com/eclipse/paho.mqtt.embedded-c/blob/master/MQTTClient-C/src/MQTTClient.c right no, so MQTT 3.1.1, and it seem that only one possibility is the one you mentioned.

Reconnect with the clean session. I don't know if this C library was updated to newer version, but very thanks for replying.

[Andy Stanford-Clark]

Very good answer :)

Just to note that for 3.1.1, another option is to receive the incoming bytes, but drop them on the floor (you could do this one byte at a time if necessary, so no big buffers required), then PUBACK it as if it was received OK. 

Then find some way of notifying the sender (or the person who wrote the application!) and telling them why you haven’t done anything useful with their message.

Not an ideal answer, but it does stop the broker retrying forever, and keeps the connection open for other messages up and down.

Andy

To view this discussion on the web visit https://groups.google.com/d/msgid/mqtt/11c1cba5-ec5c-4478-8823-15f467e10fe5n%40googlegroups.com.