Re: [mosquitto-dev] Flow Control / Flow Limiting

[Roger Light <roger@xxxxxxxxxx>]

Hi Christoph,

If you'd have asked me, I would have said that the broker implement
rate limiting on its outgoing messages but not incoming, and the same
for the client library. It looks as though this isn't true for the
broker, I'm not sure why. I agree it's the correct behaviour, please
file a bug and we'll get it on the list for 1.5.

Cheers,

Roger


On Fri, May 8, 2015 at 11:06 AM, Christoph Krey
<krey.christoph@xxxxxxxxx> wrote:
> 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 suchsituations. 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
>
>
> _______________________________________________
> mosquitto-dev mailing list
> mosquitto-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/mosquitto-dev