Session Management (CLOB)

zerohash's CLOB uses the FIX 5.0 protocol for session-level message sequencing and recovery. This page covers how sequence numbers work, what happens during a session disruption, and how Platforms must handle resend scenarios to avoid unintended order submissions.

Sequence Numbers

Every FIX message carries an incrementing MsgSeqNum (34). Both sides maintain independent counters. If a gap is detected on either side, the receiving party will issue a ResendRequest (35=2) to recover missing messages.

Sequence numbers are scoped to a session — the period between Logon and Logout. A session reset can occur in two ways:

Platform-initiated: Reconnecting with ResetSeqNumFlag(141)=Y on Logon.
Gateway-initiated: The gateway's sequence state is reset as part of a recovery procedure.

📘
Note
The gateway's sequence state can be reset independently of any action by the Platform (e.g., following infrastructure maintenance), and the gateway may not always notify the Platform in advance. In either case, upon reconnection, the gateway may detect a sequence gap and issue a ResendRequest covering the full missing range, which may span the Platform's entire session history since their last reset.

Session Connectivity and Reliability

Cancel on Disconnect: This feature is disabled by default and must be enabled per session by contacting zerohash. If enabled, all open DAY orders are automatically canceled upon session termination (including graceful logout), while GTC/GTD orders continue to rest. Upon reconnection, missed messages — including execution reports for any canceled orders — will be replayed, and Platforms must process these reports to accurately reconstruct their order state.
Graceful Logout: Platforms are recommended to schedule a graceful logout before any planned maintenance window. If no logout is received, the gateway will eventually initiate the logout procedure.
Heartbeat: If no heartbeat is received within the HeartBtInt, the gateway will proactively drop the TCP connection rather than passively waiting.

Responding to a ResendRequest

Platforms must respond for every message in the requested sequence range, regardless of which side initiated the reset.

Replay the message: For orders that remain open and actionable, retransmit using the original MsgSeqNum (34) from when the message was first sent, with PossDupFlag(43)=Y and the original sending time in OrigSendingTime(122).
GapFill the message: For any message that should not be reprocessed — including NewOrderSingle (35=D), OrderCancelRequest (35=F), and OrderCancelReplaceRequest (35=G) messages for any order that has reached a terminal state (filled, cancelled, or expired), regardless of order type or time-in-force — respond with a SequenceReset-GapFill:

FIX Field	Value
`MsgType (35)`	`4`
`GapFillFlag (123)`	`Y`
`NewSeqNo (36)`	Next sequence number after the skipped range
`PossDupFlag (43)`	`Y`

Administrative messages: Administrative messages (such as Heartbeat and Logon) that fall within a resend range should be GapFilled to prevent confusion during session recovery.

⚠️
Warning
PossDupFlag(43)=Y does not prevent duplicate executions for terminal orders. The FIX gateway enforces ClOrdID (11) uniqueness against active orders only. Once an order of any type reaches a terminal state, its ClOrdID is released. Any subsequent application message — such as NewOrderSingle (35=D), OrderCancelRequest (35=F), or OrderCancelReplaceRequest (35=G) — carrying that ClOrdID, including messages sent in response to a ResendRequest, will be treated as a new message submission or may fail to resolve the intended order. Always use GapFill for any order that should not result in a new execution.

Terminal Orders and ClOrdID Scope

ClOrdID (11) uniqueness is enforced for active orders only. Once an order reaches a terminal state (filled, cancelled, or expired), its ClOrdID is released, and any subsequent application message — such as NewOrderSingle (35=D), OrderCancelRequest (35=F), or OrderCancelReplaceRequest (35=G) — carrying that ClOrdID — including messages sent during a ResendRequest — will be processed as a new or unresolvable message. This enforcement behavior applies in all ResendRequest scenarios, including those triggered by a session reset. Platforms should always verify open order state via the gateway after a session disruption and use GapFill for any terminal order to avoid unintended new executions.

Support

For questions about FIX session configuration or integration support, contact [email protected].