Clean Session with respect to LWT.

[cogitoergosum]

Suppose a client has connected with the clean session as true. As per spec on clean session (http://ibm.co/NfUqTM) - emphasis mine - :
"If set (1), then the server must discard *any* previously maintained information about the client and treat the connection as "clean". The server must also discard any state when the client disconnects."

So, when a client connects with clean session set, should/must the Last Will and Testament (LWT) information be discarded ?

Consider a case when client C0 had connected with clean session set, LWT information provided and Will Retain flag also set. C0 dies abruptly. Then, the broker publishes to the Will Topic with Will Retain flag set. Assume that, C0 is now reconnecting with the clean session set and the former LWT information is not discarded. Now, if C1 connects and subscribers to the same Will Topic, then it will get the LWT message even when C0 isn't dead.

Consider a case when client C0 had connected with clean session set and Will Retain flag also set. Suppose, C0 issues a DISCONNECT explicitly. At this point, the LWT is not published by the broker; nor is the LWT information discarded because these are not triggered by DISCONNECT. Assume that, C0 is now reconnecting with the clean session set and the Will Topic is not discarded. However, in this reconnection, a new set of LWT information is provided. Certainly, this LWT information should "over write" the formerly maintained LWT information ?

[Nicholas O'Leary]

> So, when a client connects with clean session set, should/must the Last Will
> and Testament (LWT) information be discarded ?

The clean session flag has no effect on the LWT behaviour.

When a client disconnects abnormally, the Will is published. When a
client disconnects cleanly, the Will is discarded without being
published.

If the Retain flag is set on the Will message, then it will be
retained like any other retained message.

> Consider a case when client C0 had connected with clean session set, LWT
> information provided and Will Retain flag also set. C0 dies abruptly. Then,
> the broker publishes to the Will Topic with Will Retain flag set. Assume
> that, C0 is now reconnecting with the clean session set and the former LWT
> information is not discarded. Now, if C1 connects and subscribers to the
> same Will Topic, then it will get the LWT message even when C0 isn't dead.

The LWT only indicates that the client disconnected abnormally. If it
is being used to maintain a record of whether the client is connected
or not, then the client needs to publish a 'connected' message when it
reconnects. This pattern is described on the wiki:
http://mqtt.org/wiki/doku.php/presence

> Consider a case when client C0 had connected with clean session set and Will
> Retain flag also set. Suppose, C0 issues a DISCONNECT explicitly. At this
> point, the LWT is not published by the broker; nor is the LWT information
> discarded because these are not triggered by DISCONNECT. Assume that, C0 is
> now reconnecting with the clean session set and the Will Topic is not
> discarded. However, in this reconnection, a new set of LWT information is
> provided. Certainly, this LWT information should "over write" the formerly
> maintained LWT information ?

The LWT information is discarded when the client disconnects,
regardless of the clean session flag, so this scenario is invalid.

Regards,
Nick

> --
> To learn more about MQTT please visit http://mqtt.org
>
> To post to this group, send email to mq...@googlegroups.com
> To unsubscribe from this group, send email to
> mqtt+uns...@googlegroups.com
>
> For more options, visit this group at
> http://groups.google.com/group/mqtt

[cogitoergosum]

Hello Nick,

>>The LWT information is discarded when the client disconnects, regardless of the clean session flag, so this scenario is invalid.

I don't see that mentioned explicitly in the spec for DISCONNECT : http://ibm.co/MeaEf5

I re-read the parts on clean session and DISCONNECT in the spec. So the clean-up happens from two "directions"; CONNECT with clean session and DISCONNECT of a client that had connected with clean session set.

I guess, what I intended to know was, isn't LWT in the category of "all previously maintained information about the client" ? The 'presence' pattern exists probably because the answer to the question is no. OTOH, with the earlier LWT still lingering, the client (with clean session set) reconnects with a clean slate; albeit, with a tiny speck of chalk on a corner somewhere. ;)

ನಾಗೇಶ್

[Roger Light]

On Sun, Jul 8, 2012 at 6:23 AM, cogitoergosum <nages...@gmail.com> wrote:

> Consider a case when client C0 had connected with clean session set, LWT
> information provided and Will Retain flag also set. C0 dies abruptly. Then,
> the broker publishes to the Will Topic with Will Retain flag set. Assume
> that, C0 is now reconnecting with the clean session set and the former LWT
> information is not discarded. Now, if C1 connects and subscribers to the
> same Will Topic, then it will get the LWT message even when C0 isn't dead.

In addition to what Nick has said, I think it might make it clearer if
you take the view that once the LWT has been published it is no longer
a LWT, it is just a message. If it has retain=true then it is no
different from any other message with retain=true.

Cheers,

Roger

[cogitoergosum]

>>In addition to what Nick has said, I think it might make it clearer if  you take the view that once the LWT has been published it is no longer  a LWT, it is just a message. If it has retain=true then it is no different from any other message with retain=true.

I agree.

It is just that, a scenario is possible where a subscriber gets the retained publication even when the client (that published the LWT) is up and running. This leads to some 'second guessing'. But, upon a clean session connection, if the former LWT was nulled out, then it is completely clear. No retained message, no publication; which informs a subscribing client that the said publisher is up and running.

ನಾಗೇಶ್

[Nicholas O'Leary]

> This leads to some 'second guessing'. But, upon a clean session connection,
> if the former LWT was nulled out, then it is completely clear. No retained
> message, no publication; which informs a subscribing client that the said
> publisher is up and running.

Removing the message might help future subscribers, but it does
nothing to help current subscribers know that the client is back
online.
The only way to satisfy both current and future subscribers is for the
client to publish a new retained message when it connects to replace
the one put in place by the LWT.

Nick

[cogitoergosum]

Actually, re-reading my earlier post, I think, the point I was trying to make was, a subscriber needn't know whether a client has *reconnected*. The subscriber receives publication only when the original client died.

If a subscriber has connected and subscribed to the LWT topic and the original client is dead, then this subscriber receives the LWT information. Instead, if the original client was up (regardless, if it was a reconnection or the original connection is still live), then this subscriber does not (need/must not) receive the LWT information. On top of this, it is up to the reconnecting client to publish "I am alive" message to the LWT topic, so that, some other subscriber is aware that, this publisher is back again. This is how I interpreted the protocol specification.