Session resumption

Session resumption allows a client to reconnect and continue the same logical session after connection loss.

Core idea

When resumption succeeds, server restores the session state from before the disconnect, including initialization/auth context and packet-processing continuity.

How it works

1. On connection accept, server includes Resume-Id in response headers.
2. Client stores this Resume-Id.
3. On reconnect, client sends the same Resume-Id request header.
4. If resume is valid, server restores previous session state instead of creating a fresh one.

What the client should do

• Persist latest Resume-Id per active session.
• Reuse it only for reconnecting that same session.
• After reconnect, re-send packets that were not acknowledged by your client. Server preserves packet continuity and avoids duplicate business execution for already-processed unacknowledged packet IDs.

When resumption is possible

• Connection was interrupted by client/network side (for example: internet drop, app restart, device sleep, local process crash).
• Reconnect happens before resume state expires.
• Provided Resume-Id is valid.

When resumption is not possible

Resumption is not available when disconnect was initiated by server.

Example: server closes session with 4101 (application paused). In this case, client must start a new session lifecycle (new connect + initialize + authorize flow when allowed).

Resume-related close codes