|
Denis,
just to check that you know that you can use the
cleansession=true connect option, and that will cause any in
flight messages to be discarded when the connection is broken?
Also, QoS 0 messages will not be resent at all.
Ian
On 18/01/2018 11:16, Denis Barbuse
wrote:
Ian,
thank you for your fast
response.
What I need is to avoid
paho to store any outgoing message in case the connection is
lost and be sure that, on reconnect, it never tries to send
any queued message.
That would mean I can
handle transmission failures using different policies
depending on the type of message I was sending before failing.
An example of usefulness
of such behaviour is when trying to send a "counter" value via mqtt.
Why sending old counter values, accumulated when
device was disconnected, when we have the last value at
disposal? We can avoid sending such data keeping low cost of
data trasmissions.
One of the possibilities
I'm thinking is to destroy the client, when detecting
disconnection, and re-create a new client before retrying to
connect again.
That would ensure the
behaviour we need, but it seems to be too much drastic.
Meanwhile I'll take a
look at the persistence feature you mentioned.
Cheers,
Denis,
a quick answer to your main question. There is no current
way to get detailed access to the outboundMsgs list. However,
all those messages are stored via the persistence interface,
so you could hook into that to get the information you need.
A simple persistence mechanism is supplied so you could use
that as a base.
If you use the "reliable" setting, then only the last single
message is stored, and that is only for QoS 1 or 2 while the
relevant MQTT packet exchange completes.
These considerations only apply assuming you are using QoS
> 0 and cleansession=False, because otherwise on a network
break there will be no state to continue with on reconnect.
Ian
On 17/01/2018 10:07, Denis
Barbuse wrote:
Hi all,
for one of our
projects we're using paho-c on a linux based device and it
is working as expected, except for a small aspect.
When the connection
is missing, paho pretends to store outgoing messages into
a list and manages the list by it's own.
The number of max
messaged to be inserted seems to be ruled by MQTTClient_SSLOptions.reliable
evaluation and if it's "true" the max number of messages
is 1, else 10.
That means if we
have 15 messages to send and MQTTClient_SSLOptions.reliable
== "false", when connection is missing only the oldest
10 messages are stored.
Our device is an
IoT device and what we would achieve is to be able to
decide what to do with unsent data.
We'd
like to apply policies based on the type of data we're
going to send because some type of data needs just last
valid value and, in this case, it's a waste of
traffic data to send old data.
So here's my
question:
How can we control
the destiny of unsent data?
Is there a way to
manipulate the outboundMsgs list from public APIs?
Thank you for the
attention and best regards,
Confidentiality Notice: This message (including attachments)
is a private communication solely for use of the intended
recipient(s). If you are not the intended recipient(s) or
believe you received this message in error, notify the sender
immediately and then delete this message. Any other use,
retention, dissemination or copying is prohibited and may be a
violation of law, including the Electronic Communication
Privacy Act of 1986.
_______________________________________________
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
_______________________________________________
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
|
