Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] Offline buffering of QoS 0 Messages

I feel like it should be a configurable part of the client, but that could cause problems for users as that could mean that the client is accepting messages but just throwing them away.
 
One question from me R.E. the Java client: Currently only QoS 1 & 2 messages are persisted. In the case of Offline Buffering, I'm planning on persisting at least QoS 1 & 2 messages to disk, but should I persist QoS 0 messages as well? I guess the problem boils down to: At what point are we happy to say that we don't care if the message arrives or not? If we have the power to still send a message that we know has never attempted to have been sent, should we persist it? Or should we assume that if it's QoS 0 then it's loss is not an issue?
 
Kind regards,
 
James Sutton
Software Engineer - IoT Foundation - MQTT Open Source Projects
Technical Trojan - Wimbledon Project

Phone: 01962 815438 | Extension: x372454
E-mail: 
Personal Website: www.jsutton.co.uk
Find me on:      
IBM

Hursley Park
HursleySO212JN
United Kingdom
 
IBM United Kingdom Limited Registered in England and Wales with number 741598 Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
 
 
----- Original message -----
From: Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx>
Sent by: paho-dev-bounces@xxxxxxxxxxx
To: General development discussions for paho project <paho-dev@xxxxxxxxxxx>
Cc:
Subject: [paho-dev] Offline buffering of QoS 0 Messages
Date: Thu, Feb 18, 2016 11:18 AM
 
Hello all,

an issue was raised on the Go client, saying that buffering of QoS 0
messages when not connected was contrary to the MQTT spec:

https://github.com/eclipse/paho.mqtt.golang/issues/2

I don't think it's clear at all that QoS 0 messages ought not to be
buffered.  It hangs on whether you consider the attempt to send the
messages after a reconnect to be a "retry".

I think this behaviour probably ought to be configurable in the client
implementations of offline buffering, with a default of... well I would
go for "do buffer".   What does anyone/everyone else think?

--
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

 
 
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


Back to the top