Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] Outgoing message queue

Hi,

As Ian said, developing your own persistence method is a good option. It's easy and can be a great way of integrating the client into your backend.

Regards.

El 18/1/2018 12:17, "Denis Barbuse" <dbarbuse@xxxxxxxxxx> escribió:

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 Brachet Barbuse
Firmware Developer
Tierra S.p.A.
Via Lombardore, 223
10040 Leini TO
ITALY
dbarbuse@xxxxxxxxxxxxxxxxxxxx
dbarbuse@xxxxxxxxxx
www.tierratelematics.com


From: paho-dev-bounces@xxxxxxxxxxx <paho-dev-bounces@xxxxxxxxxxx> on behalf of Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxx.uk>
Sent: 18 January 2018 11:49:07
To: paho-dev@xxxxxxxxxxx
Subject: Re: [paho-dev] Outgoing message queue
 

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,


Denis Brachet Barbuse
Firmware Developer
Tierra S.p.A.
Via Lombardore, 223
10040 Leini TO
ITALY
dbarbuse@xxxxxxxxxxxxxxxxxxxx
dbarbuse@xxxxxxxxxx
www.tierratelematics.com

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

Back to the top