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
|