Hi Ian,
I agree, that it’s probably too hard for client configurations to set a static bandwidth throttling at deployment time. Maybe reconfiguration at runtime would be the way to go for bandwidth throttling. I’m not sure how useful this is for real world scenarios. Dynamic bandwidth throttling on the broker side is something we know many people are doing in real world scenarios, but I’m not sure if anyone does this on the client side, though.
My personal experience is, that many people struggle with the in-flight window concept so it would be great to give developers examples how to throttle clients by utiliizing the in-flight window on the client side. If there is a document / wiki page with an concrete example I could point interested people to, that would help at least me a lot.
Thanks for your insights on this topic, I am sure a lot of people reading this mailing list thread can profit from the discussion!
Best, Dominik
On 18 Sep 2015 at 11:42:57, Ian Craggs (icraggs@xxxxxxxxxxxxxxxxxxxxxxx) wrote:
Hi Dominik,
if it works, I can envisage throttling definitely being
useful. I am wondering if anyone has practical experience of
using this feature, because it strikes me that it might be
difficult to choose a suitable read or write rate. Is
there an example of a problem that has been solved with this
approach, and how was the best rate selected?
Where an inflight window is used, that is generally for outbound
messages, although some client libraries do that for inbound
messages too. If you use an asynchronous API with
notifications, like the asynchronous C or Python libraries, the
application can largely be in control of the sending and receiving
of messages and acks, and so apply a degree of throttling itself,
and in a natural way for the application.
Ian
On 09/17/2015 07:51 PM, Dominik
Obermaier wrote:
Hi Ian,
thanks for bringing the topic to attention. Since I’m involved in
this blog series I’m very glad for the feedback and this must
indeed be clarified since your point of view on throttling is also
valid.
The idea for adding throttling was inspired by the fusesource
mqtt-client. I’ll copy the relevant part of their documentation
below:
-
setMaxReadRate : Sets the maximum bytes per second that
this transport will receive data at. This setting throttles reads
so that the rate is not exceeded. Defaults to 0 which disables
throttling.
-
setMaxWriteRate : Sets the maximum bytes per second
that this transport will send data at. This setting throttles
writes so that the rate is not exceeded. Defaults to 0 which
disables throttling.
So the idea is to limit the maximum bytes for reading and writing
operations on the client side. With that options it’s possible to
guard the client from receiving more messages than it can handle
(you can try it out with high-throughput public brokers and
subscribe to ‘#’). This of course adds backpressure on the broker
and this will probably result in load shedding for the subscriber
if the broker supports that. This option is also very useful if you
are on constrained devices with very limited memory.
While an in-flight window is also good for throttling (outgoing)
QoS 1 and 2 messages, my understanding is, that this in-flight
feature is useful to guarantee the Ordered Topic requirements of
the MQTT 3.1.1 specification. I’m not too familiar with the
implementation details of Paho, but I guess the in-flight window is
only implemented for the publishing API?
I’d like to hear your opinion on that and if you think the
throttling (as in limiting bandwidth) would be useful for
Paho.
Nevertheless, we will add a short explanation to the HiveMQ blog
post series for throttling soon so readers don’t get
confused.
Thanks,
Dominik
On 17 Sep 2015 at
16:45:55, Ian Craggs (icraggs@xxxxxxxxxxxxxxxxxxxxxxx)
wrote:
Hello all,
one of the features of MQTT client libraries listed on the HiveMQ
blogs
is "throttling". In most, if not all of the client libraries we
can
"throttle" outgoing QoS 1 and 2 flows by waiting for acks before
sending
new messages, but this does not work for QoS 0. I thought that
our
current approach might qualify as throttling - but apparently not
:-)
Is there a definition of throttling for MQTT clients that we can
all
agree on, and works for any MQTT broker implementation? I'd
be
interested in implementing that in various libraries, if it seemed
to be
useful.
--
Ian Craggs
icraggs@xxxxxxxxxx IBM United
Kingdom
Paho Project Lead; Committer on Mosquitto
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev
--
Ian Craggs
icraggs@xxxxxxxxxx IBM United Kingdom
Paho Project Lead; Committer on Mosquitto
|
