Session Messages
Session messages manage the lifecycle of a TCP connection to a Starbase gateway, including authentication, heartbeating, and sequence number recovery.Sequence numbers
SBE order-entry sequence numbers are persisted across reconnects unless the client or the exchange resets them. They are not recovered like a full FIX session: the gateway never sendsResendRequest (20) to the client.
Logon with resetSeqNum=0
On reconnect, the sequenceNum in the LogonRequest header must continue from the previous session. A discontinuous inbound sequence is handled as follows — the two cases are not symmetric:
To recover outbound events the client missed, send
ResendRequest (20) after a successful logon to the same gateway host.
Logon with resetSeqNum=1
Both sides reset sequence numbers to 1. Use this after an exchange-initiated reset (see below), or whenever the client wants a fresh sequence.
Weekly sequence reset
The exchange resets SBE order-entry sequence numbers weekly on Saturday at approximately 12:00 US Central (the same default as INTX). All sessions are disconnected with reasonSEQUENCE_RESET. Clients must reconnect with resetSeqNum=1.
The weekly reset also applies to FIX Drop Copy — reconnect there with ResetSeqNumFlag (Tag 141) = Y.
The weekly reset tears down the TCP session. Cancel on Disconnect therefore applies as for any other disconnect: CoD-covered orders and quotes on that session are cancelled and are not restored on reconnect.
LogonRequest (1)
First message sent by client after establishing TCP connection.LogonResponse (2)
Response toLogonRequest on successful logon.
Schema version negotiation (schema version
12 and later): schemaVersion on LogonRequest acts as a gate — it determines whether new messages and new versions of existing messages are sent to the client. A value outside the gateway’s accepted range is rejected at logon. The gateway echoes the accepted version in LogonResponse.There are two version numbers on the wire, and they are not equal:- Session ceiling — the
schemaVersionsent at logon: the highest schema version the client can accept. One number per session, echoed back inLogonResponse.schemaVersion. This is the authoritative negotiated version for the session. - Per-message stamp — the
versionfield in the header of each message the gateway sends: the newest schema version at which that particular message last changed, never above the session ceiling. If a message did not change between schema versions, its stamp is not bumped.
15, LogonResponse arrives with header version = 12 because LogonResponse has not changed since version 12. This is expected — always read the negotiated version from the schemaVersion field, never from per-message header stamps.LogoutRequest (4)
Request by client to gracefully terminate a connection.LoggedOut (5)
Sent in response toLogonRequest if logon failed, or in response to LogoutRequest, or unsolicited for other reasons.
Heartbeat (10)
Sent by client or server periodically in the absence of other messages.TestRequest (11)
Request aHeartbeat message. Can be sent by either client or server.
ResendRequest (20)
Sent by the client to request resend of a limited number of missed outbound events. Works only when reconnecting to the same gateway host. The server never sends this message — inbound sequence gaps at logon are ignored, not filled. See Sequence numbers.GapFill (21)
Sent by server in lieu of admin/session messages while handling a resend request.Reject (30)
Sent by the server in response to an unrecognized or malformed message from the client.
The table below lists all possible values of the
reason field.