[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[mosquitto-dev] Flow Control / Flow Limiting
|
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