Will Delay Interval

[redboltz]

The example broker doesn't support Will Delay Interval yet.

The spec is ambiguous for me.

https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901062

The Server delays publishing the Client’s Will Message until the Will Delay Interval has passed or the Session ends, whichever happens first. If a new Network Connection to this Session is made before the Will Delay Interval has passed, the Server MUST NOT send the Will Message [MQTT-3.1.3-9].

Consider the following scenario:

1. c1 connected to the broker with WDI(Will Delay Interval) 10, and SEI(Session Expiry Interval) 0 (Equivalent to be omitted).
2. c1 disconnected forcibly.
3. The broker should publish the will immediately because the session ended.

I think that it is meaningless that WDI smaller than SEI because the session ends is always earlier than WDI passed.

Consider the following scenario:

1. c1 connected to the broker with WDI(Will Delay Interval) 10, and SEI(Session Expiry Interval) 20.
2. c1 disconnected forcibly.
3. c1 reconnected with CleanStart 0.
4. The broker shouldn't send the will even if WDI passed. (Sending the will is cancelled)

It is reasonable.

Consider the following scenario:

1. c1 connected to the broker with WDI(Will Delay Interval) 10, and SEI(Session Expiry Interval) 20.
2. c1 disconnected forcibly.
3. c1 reconnected with CleanStart 1.
4. The broker should publish the will immediately because the session ended. Is this right ?

"a new Network Connection to this Session is made before the Will Delay Interval has passed" is satisfied.
But "Session ends" by the new connection with CleanStart 1.
So "until the Will Delay Interval has passed or the Session ends" the latter condition is satisfied so the will should be send.
Is this right?

Non-normative comment
If a Network Connection uses a Client Identifier of an existing Network Connection to the Server, the Will Message for the exiting connection is sent unless the new connection specifies Clean Start of 0 and the Will Delay is greater than zero. If the Will Delay is 0 the Will Message is sent at the close of the existing Network Connection, and if Clean Start is 1 the Will Message is sent because the Session ends.

It is the most confusing comment.
What does "the Will Delay is greater than zero" mean?
The existing connection's WDI or the new connection's WDI?
If it is the new connection's WDI, it's contradicts the spec.

[kleunen]

Issue #340 and issue #516 are related.

Will expiry was implemented in PR #731, but this issue is related to will delay, which was not implemented in this PR.

[kleunen]

What does "the Will Delay is greater than zero" mean?

I think this relates to the Will Delay setting of the new connection that is made. So, if a client reconnects, and on the reconnect the Will Delay is specified and is > 0 ...

[redboltz]

Issue #340 and issue #516 are related.

Will expiry was implemented in PR #731, but this issue is related to will delay, which was not implemented in this PR.

Thanks. I know the issues. But the current broker design is slightly different from at that time. So WDI should be implemented form the scratch.

[redboltz]

What does "the Will Delay is greater than zero" mean?

I think this relates to the Will Delay setting of the new connection that is made. So, if a client reconnects, and on the reconnect the Will Delay is specified and is > 0 ...

From the location, it seems to be new Connection but perhaps the is for previously appeared word so it might be the previous WDI.

If it is the new connection's WDI, it is very weird. The will is the existing will in the context. I believed that the new WDI shouldn't be affected to the current (previous) will.

[redboltz]

What happened the following case?

1. c1 connected to the broker. SEI: 0, CleanStart any, WDI any.
2. Another c1 connected to the broker. SEI any, CleanStart 0 WDI 10.

https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901059

Each Client connecting to the Server has a unique ClientID.

I think that there is not enough notation about online to online transition.
The practical implementation is the new connection wins.
So the first connection is closed due to the second connection.
The first connection's SEI is 0 so session ends. Then will should be sent.

[redboltz]

Another case:

1. c1 connected to the broker. SEI: 10, CleanStart any, WDI 10.
2. Another c1 connected to the broker. SEI any, CleanStart 0 WDI 0.

In this case, should will send at the step 2 ?
The new connection's WDI is not > 0.
I think it is very weird.

[kleunen]

If it is the new connection's WDI, it is very weird. The will is the existing will in the context. I believed that the new WDI shouldn't be affected to the current (previous) will.

Yes, I think you are right.
The new WDI settings should apply to the new connection
The old WDI settings apply to the old connection

I think you should read:
Non-normative comment
If a Network Connection uses a Client Identifier of an existing Network Connection to the Server, the Will Message for the exiting connection is sent unless the new connection specifies Clean Start of 0 and the Will Delay (of the old/exiting connection) is greater than zero. If the Will Delay is 0 the Will Message is sent at the close of the existing Network Connection, and if Clean Start is 1 the Will Message is sent because the Session ends.

If the client reconnect within the period of the will delay, no will should be send.

Will delay of old connection is 10 seconds:
Reconnect within 10 seconds, Clean start = 0, No will send

New WDI settings are applied to new connection:
WDI = 0, send when new connection terminates
WDI > 0, send when new connection terminates and no reconnect within WDI

[kleunen]

But does it make sense to have SEI < WDI ?
Session expires, but will has not been send yet.
Is the will not part of a session ?

The specification says:

the Will Message is sent because the Session ends.

So the will is sent when session expires ?
So effective WDI = min (WDI, SEI) ?

Ah yes, this is stated in specification:

The Server delays publishing the Client’s Will Message until the Will Delay Interval has passed or the Session ends, whichever happens first.

[redboltz]

Implemented by #839