[mosquitto-dev] Flow Control / Flow Limiting

[Christoph Krey <krey.christoph@xxxxxxxxx>]

I came across the following situations:





a) Client overflows Server

A client stored a large number of messages while off-line from the network.

When reconnecting to mosquitto, it transmits the messages with qos > 0.

Because mosquitto was configured with max_inflight_message 20 (default), a lot of messages were ignored.

The client repeated the messages b/c no PUBACK was received.

The whole situation lasted for quite a while until all messages were eventually transmitted and acknowledged.

b) Server overflows Client

A client subscribes to a topic which receives a few hundred messages per hour with qos > 0 and cleansession = NO.

The client goes off-line for a while.

When the client reconnects to mosquitto, mosquitto publishes those hundreds of messages to the client.

The client cannot PUBACK to all of the messages in a timely manner.

This causes the majority of the messages to be retransmitted after retry_interval 20 (default) seconds.

Depending on the number of queued messages, the message size and the available band-with both situation lead to:

- unneccessary multiple transmissions

-  a waste of possible expensive band-with (mobile data plans)

- possibly memory overflows

- connection aborts




On the mosquitto side, raising the parameter settings for max_inflight_messages and max_queued_messages may avoid such

situations. As long as the available bandwith is big enough ignoring messages is a valid approach.




On mobile clients with limited bandwidth, a flow control or flow limiting approach seems appropriate to me.

The MQTT standard does not address this topic. As far as I know mosquitto does not implement such functionality.

In the client library, I implemented a window size (n) for outgoing PUBLISH messages.

When qos > 0, only n messages are sent before the corresponding acknowledge is received (PUBACK or PUBREC/PUBREL/PUBCOMP)

Any thoughts or plans?

Cheers

   Christoph

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail