Keep-Alive

The KEEP_ALIVE message proves link liveness when no other message has been transmitted recently. Together with the session lease, it enables timely detection of failed or silent peers.

Wire Format

Flags:
  Z  If Z==1, extension chain follows.

 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+
|Z|X|X| KALIVE  |   ID = 0x04
+-+-+-+---------+
~  [KAliveExts] ~   if Z==1
+---------------+

No mandatory body fields. The message consists of only the header byte (and optional extensions).

Lease and Keep-Alive Interval

During OPEN, each side proposes a lease duration. The effective lease is the minimum of the two proposed values.

Sending Rule

A node MUST transmit at least one message (any type, including KEEP_ALIVE) every lease / 4 milliseconds on each active link.

Using lease / 4 as the sending interval ensures that at least four messages are emitted within each lease window. A keep-alive is only required when no other message (FRAME, FRAGMENT, DECLARE, etc.) has been sent within that interval; if data is flowing, explicit keep-alives may be omitted.

Receiving Rule

If a node receives no message from its peer within the effective lease period, it MUST declare the session dead and initiate teardown:

  1. Close the underlying transport link.

  2. Propagate U_SUBSCRIBER, U_QUERYABLE, and U_TOKEN messages for all entities declared by the lost session.

  3. Notify the application layer.

Multilink Behaviour

In a multilink session, the lease applies independently to each link. If one link’s lease expires, that link is closed. The session remains alive as long as at least one link is active.

Relationship to JOIN (Multicast)

On multicast transports there is no unicast link; liveness is maintained by periodic JOIN messages instead of KEEP_ALIVE. A peer that stops sending JOIN messages within the JOIN lease period is considered offline.