Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mosquitto-dev] A Few Questions about mosquitto.conf File

Hash: SHA1

Devil Here <heredevil008@xxxxxxxxx> wrote:
> Hi Mosquitto Team,
> I have recently started working on a project which is based on Mqtt and
> I have chosen Mosquitto v1.4.2 installed on centOS 6.6 as the broker. I
> had a few doubts regarding options available in the mosquitto.conf file.
> 1. The field "max_inflight_messages" does it specify the number of
> messages which are in transit for one client or is it the total number
> of messages that are in transit from the broker ??

I agree that the actual man page is unclear on this, but the
mosquitto.conf.example file shipped mentions this is per client...

# The maximum number of QoS 1 and 2 messages currently inflight per 
# client.
# This includes messages that are partway through handshakes and 
# those that are being retried. Defaults to 20. Set to 0 for no 
# maximum. Setting to 1 will guarantee in-order delivery of QoS 1 
# and 2 messages.
#max_inflight_messages 20

This could probably be clarified :)

> 2. The field "max_queued_messages", if I put a count of 10 on this field
> and lets suppose I am sending the messages to a offline device where
> messages could not be delivered then what will happen if I try to
> publish a 11th message to the same client  using a QoS level of 2.

Remember, you're not sending messages to an offline device, and you're
not sending messages to a client.  You're publish messages to a topic,
for which there may or may not be subscribers.  Publishing keeps
succeeding, and remember that QoS only affects the conversation between
client and broker, not client and all possible subscribing clients.

It is true that the man page doesn't clarify whether it's tail drops or
head drops, but I think it's generally safe to assume tail drops unless
it's explicitly mentioned.

> 3. I am working on sending push notifications to android devices, if I
> submit a notification to a device which is not going to come online
> again to receive the notification then how can I delete that request
> from my broker so that it does not continuously retries sending the
> message to the same client for an indefinite period of time.

I don't know what you're talking about here.  What are these continuous

> 4. What is the implementation of field "store_clean_interval" as I was
> not able to properly understand this field.

It means you don't need to touch it then :)  This has no impact on
delivery, qos or reliability, only the tradeoff of memory vs cpu for
internal housekeeping tasks.

> 5. The field "persistent_client_expiration" when I set it to 10m (10
> minutes) and a client does not connects with in this time duration then
> also the messages that were to be transferred to this client are not
> removed from the broker queue.

You should reread the man page one more time.  Hint, m stands for
something other than minutes.  Further, you probably don't really want
persistent client expiratation of 10 minutes anyway.  If you want them
that short, you probably just don't want persistent clients at all. 
Read the archives of this list for further discussion on this topic
recently, and consider carefully what you're trying to achieve with

Karl P

Version: GnuPG v1.4.11 (GNU/Linux)


Back to the top