Re: [paho-dev] Offline Buffering

[Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx>]

Hi Mike,

thanks for starting this discussion.  You are asking about the _javascript_ client in particular, correct?  We also should bear in mind the other client libraries that need updating, so it would be good to get a (fairly) consistent approach, or at least, not wilfully inconsistent :-)

As the Paho Python client implements automatic reconnect and I believe "offline buffering", it would be a good to take a look at the approach Roger has taken there, and see whether that answers any of your questions. 

One option is that the buffering layer could be optional, above the existing client, potentially providing a simpler interface.

Buffer or not to buffer

So, we shouldn't alter the behaviour of existing applications.   So we can't use an existing flag.  There is also the question of whether we should allow an application to publish before attempting to connect.  If we allow publishing before connect, we won't know the state of the clean session flag because that is in the connect options.

QoS

I think that people will expect QoS 0 to be buffered as well.  Even QoS 0 messages should be attempted to be sent at least once!

Resend

Only if the messages really are being resent should the DUP flag be used.  I don't think this needs any change to the existing behaviour of a client. 

Max messages

Should be configurable.  When the buffer is full, I think that new messages should be rejected with an appropriate code.  We could provide an API which allows old messages to be deleted, so the application can take control.

Persist buffered messages

The _javascript_ client is meant for web browsers.  I don't think the current client persists the inflight state, just in memory.  The same could go for these buffered messages.... maybe.   What makes sense for a web browser?

Ian

On 10/29/2015 04:22 PM, Mike Tran wrote:

Hello all,

As Ian listed Client offline buffering (ability to send while not connected) in Paho release roadmap, I would like to start design discussion before implementation.

Here are some items to consider and my opinion, please let me know your thoughts and provide comments..

* Buffer or not buffer
   - Use cleanSession flag
       ++ cleanSession=false indicates to buffer
       ++ cleanSession=true incicates not to buffer messages, clear buffer if exists

* QoS
    - Since MQTT protocol does not requires servers to forward publication at QoS=0 to a client, QoS=0 messages are not buffered
    - QoS=1 and QoS=2 messages are buffered.

* Resend
    Buffered messages are sent again with DUP flag set
 
* Max messages
    - The maximum number of messages to keep for a session (per connection)
        ++ Default is 5000 ???
    - The behavior applied when the buffer is full. That is, when the number of messages in the buffer reaches the Max Messages value.
        ++ Reject new messages:  While the buffer is full, new messages are rejected.
        ++ Discard old messages:  When the buffer is full and a new message arrives, the oldest un-delivered messages are discarded.

* Persist buffered messages
   - Have a flag for this??  Default is true. If persist flag is false, create buffer in memory




Regards,
Mike Tran

_______________________________________________
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