Sessions, keep alive and Will

A TCP connection and an MQTT session are different things. A connection can drop and come back, while a session can outlive the connection on both the broker and the client.

Session state

MQTT 5.0 §4.1 defines what a session holds:

Where	State
Broker	The client’s subscriptions, unacknowledged QoS 1 and QoS 2 messages, messages queued while the client was offline, the Will message
Client	QoS 1 and QoS 2 messages that the broker hasn’t acknowledged yet, QoS 2 messages received from the broker but not yet completed

When the session survives, a reconnecting client doesn’t need to subscribe again, and it receives the QoS 1 and QoS 2 messages that arrived while it was away.

Clean Session and Session Expiry

MQTT 3.1.1 and 5.0 express the lifetime of a session differently:

Version	Field	Meaning
3.1.1	Clean Session = 1 (§3.1.2.4)	Discard any previous session on connect, and discard the session on disconnect.
3.1.1	Clean Session = 0	Resume the previous session, and keep the session after disconnect.
5.0	Clean Start (§3.1.2.4)	1 discards any previous session on connect. It only controls the start.
5.0	Session Expiry Interval (§3.1.2.11.2)	How many seconds the session outlives the connection. 0 or absent ends the session with the connection; 0xFFFFFFFF means it never expires.

In MQTT 5.0, the equivalent of Clean Session = 1 is Clean Start = 1 with a Session Expiry Interval of 0. The Session Present flag of CONNACK (§3.2.2.1.1) tells the client whether the broker resumed a previous session.

Keep alive

Keep Alive (§3.1.2.10) is an interval in seconds that the client puts in CONNECT.

When the client has nothing to send for that long, it sends PINGREQ, and the broker answers with PINGRESP.
When the broker receives no packet for one and a half times the interval, it closes the connection.
0 turns keep alive off.
An MQTT 5.0 broker can override the value with the Server Keep Alive property of CONNACK (§3.2.2.3.14), and the client must then use the broker’s value.

For example, with max_keepalive 4 in Mosquitto, the PDComm simulator connects with a keep alive of 30 seconds but sends a PINGREQ every 4 seconds:

Received PINGREQ from pdcomm-opcua-sim-98736-17
Sending PINGRESP to pdcomm-opcua-sim-98736-17

Will messages

A Will message (§3.1.2.5) is a message the client leaves with the broker in its CONNECT packet. The broker publishes it on the client’s behalf when the client disappears without sending DISCONNECT.

A normal DISCONNECT (reason code 0x00) doesn’t trigger the Will.
A keep-alive timeout, a network failure or a killed process does.
The MQTT 5.0 Will Delay Interval (§3.1.3.2.2) postpones the Will. If the client reconnects in time, the broker doesn’t publish it.
An MQTT 5.0 client can also disconnect with reason code 0x04 (Disconnect with Will Message) to have the broker publish its Will on purpose.

A common way to report whether a device is online:

Right after connecting, publish online to factory/line1/status as a retained message.
Leave offline on the same topic as the Will message, with RETAIN set to 1.
If the device fails, the broker publishes offline, which also replaces the retained message.

Client Identifier conflicts

The broker finds a session by its Client Identifier. When a second client connects with an identifier that’s already connected, the broker closes the existing connection (§3.1.4). An MQTT 5.0 broker sends that client reason code 0x8E (Session taken over). Two clients that share an identifier keep disconnecting each other, so give every client its own identifier.

What the PDComm simulator uses

Setting	Value
Client Identifier	`pdcomm-opcua-sim-<process ID>-<DataSetWriterId>`
Clean Start	1
Session Expiry Interval	Not sent (same as 0)
Keep Alive	30 seconds; a Server Keep Alive from the broker takes precedence
Will	Not used
When the connection drops	No automatic reconnect. PubSub stops and its status keeps the last error.