FIX Session Sequence Resets and Maintenance
Zerohash support a hot-hot primary and secondary FIX gateway configuration with intra-session sequence resets that allow clients to always remain connected and trade 24/7 365.
Architecture Overview
Dual FIX Gateways (HOT-HOT):
- Primary and Secondary gateways are always active.
- Clients may send/receive orders through either gateway at any time
- Orders placed on one gateway may be cancelled or modified on the other
- The same SenderCompId must be used on both primary and secondary
- Sequence numbers are expected to diverge on the primary and secondary. Responding to resend requests sent by the Zerohash FIX gateway with new order submission or order modifications is not recommended as Zerohash will process order requests in GapFill mode.
Technical Details
Automatic Daily Sequence Reset
To simplify daily operations, the FIX Gateway now performs an intrasession sequence reset each day.
| Gateway | Reset Time (EST) | Reset Type |
|---|---|---|
| Primary | 16:01 PM | Zerohash sends logon with 141=Y, MsgSeqNum=1 |
| Secondary | 18:01 PM | Zerohash sends logon with 141=Y, MsgSeqNum=1 |
- Purpose : Staggered resets ensure zero overlap, reducing the risk of message loss during client disconnects.
This process resets the FIX Gateways sequence number to 1 without requiring the client to disconnect or initiate a new session.
Clients do not need to respond with their own Logon. The existing session remains valid and open.
This reset on the primary gateway aligns with the end of the trading day when settlement prices are published and market statistics are re-published. The primary gateway reset is at 16:01 PM ET on the primary gateway is to ensure that enough time for DAY messages expiry execution reports be processed before the logon message is sent.
Dual Gateway Support
Clients can now maintain concurrent FIX sessions to both the Primary and Secondary gateways.
Both sessions use the same FIX credentials (e.g., SenderCompID, TargetCompID), but will have distinct connection urls, for example:
- Primary = f-plat01.oe.zerohash.com
- Secondary = f-plat01-secondary.oe.zerohash.com
Message Behaviour:
- Execution Reports (35=8) and Order Cancel Rejects (35=9) are sent to both sessions.
- Cross-session order management is supported — e.g., an order submitted via the Primary can be canceled via the Secondary.
- FIX Rejections (35=3) and Business Rejects (35=j) are only sent to the session where the error occurred.
- Sequence numbers will diverge between sessions based on message flow and activity (e.g., due to order flow or rejections).
Failover During Maintenance:
- Maintenance is performed on one gateway at a time.
- During maintenance on the Primary, clients can send all traffic to the Secondary.
- Once complete, clients should fail back to the Primary.
- The same procedure applies when the Secondary gateway undergoes maintenance.
Action Required
- Handle Automatic Logon-Based Reset at 4:01 PM ET and 6:01 ET
- Ensure your FIX client supports receiving a Logon message with 141=Y from the gateway, without a preceding Logout.
- Maintain the session and reset your sequence numbers to 1 as instructed — no disconnect or reconnect is required.
Optional - Establish Dual Connectivity
- Connect concurrently to both Primary and Secondary FIX gateways using the same credentials.
- During maintenance, reroute all outbound messages to the available gateway.
- Be prepared to manage message flow with asynchronous sequence numbers and session-specific behaviours
Integration Scenarios and Expected Results
| ID | Test Case | Expected Result |
|---|---|---|
| 1 | Client connects to primary and secondary gateways with the same SenderCompId and TargetCompId combination | (1) Both logon requests are accepted by the Zerohash FIX Gateways |
| 2 | Client connects to primary and secondary gateways with the same dropcopy SenderCompId and TargetCompId combination | (1) Both dropcopy session logon requests are accepted by the Zerohash FIX Gateways |
| 3 | At 16:01 EST, Zerohash primary gateway sends Logon (141=Y, MesSeqNum = 1) intra-session | (1) Client resets MsqSeqNum to 1 |
| 4 | Client sends NewOrderSingle after reset on the primary | (1) If client sends preceeding login, Order has MsgSeqNum=2 and is accepted (2) If client doesn't send preceeding login, Order has MsgSeqNum=1 and is accepted |
| 5 | At 18:01 EST, Zerohash secondary gateway sends Logon (141=Y, MesSeqNum = 1) intra-session | (1) Same reset process occurs on the secondary independently. Client resets MsqSeqNum to 1 |
| 6 | Client sends NewOrderSingle after reset on the secondary | (1) If client sends preceeding login, Order has MsgSeqNum=2 and is accepted (2) If client doesn't send preceeding login, Order has MsgSeqNum=1 and is accepted |
| 7 | Client loses connectivity to primary at 15:55 EST, reconnects at 16:05 | (1) Zerohash cannot send the Logon request with 141=Y and MsqSeqNum continues to increase once reconnected (2) Client can still trading and receive Execution Reports on secondary gateway and dropcopy Session. |
| 8 | Client sends a high rate of new order singles close to and after the primary FIX gateway reset time at 16:01 EST | (1) All Execution Reports are returned on the primary gateway (2) All Execution Reports are returned on the secondary gateway (3) All Execution Reports are returned on the dropcopy session |
| 9 | Client sends a NewOrderSingle with same client order id on primary and secondary gateways | (1) The second placed order gets rejected with "ClOrdID already in use by an open order" Note: This protection only applies to open orders. |
| 10 | Client loses connectivity to primary at 15:55 EST, sends NewOrderSingle from the secondary, reconnects to Primary at 16:05 | (1) Zerohash cannot send the Logon request with 141=Y and MsqSeqNum continues to increase once reconnected (2) Client reconnects and resets seqNum to 1 or Client reconnects and doesn't reset SeqNum. Zerohash primary gateway will request a resend. The client should not resend NewOrderSingles or Order Modifications. Order cancel requests are safe to resend as if a duplicate, the client will just receive a cancel rejection. |
Updated 2 days ago