Session Management

Logon (MsgType = A)

The Logon message initiates a FIX session and authenticates the client.

Client → Server

Example

8=FIX.4.4|9=126|35=A|49=CLIENT1|56=BROKERET|34=1|52=20260312-14:30:00.000|98=0|108=30|553=client1|554=MyP@ssw0rd|141=Y|10=185|

Server → Client (Acknowledgment)

If authentication succeeds, the server responds with a Logon message confirming the session parameters.

Logon Failure

If authentication fails, the server sends a Logout (5) message with the rejection reason in Tag 58 (Text):

8=FIX.4.4|9=82|35=5|49=BROKERET|56=CLIENT1|34=1|52=20260312-14:30:00.500|58=Invalid credentials|10=201|

Logout (MsgType = 5)

Gracefully terminates a FIX session.

Initiating Logout

Either side can initiate a logout:

Logout Sequence

1. Initiator sends Logout message
2. Counterparty responds with Logout message
3. Both sides close the TCP connection

Heartbeat (MsgType = 0)

Heartbeat messages ensure the connection is alive. Both sides send heartbeats at the agreed interval.

Heartbeat Rules

• Each side sends a Heartbeat if no messages have been sent within the HeartBtInt interval
• If no message is received within HeartBtInt + reasonable delay, send a TestRequest
• If no response to TestRequest within HeartBtInt, consider the connection lost and disconnect

TestRequest (MsgType = 1)

Forces the counterparty to send a Heartbeat. Used to verify the connection is still active.

Example

8=FIX.4.4|9=68|35=1|49=CLIENT1|56=BROKERET|34=15|52=20260312-14:35:00.000|112=TEST123|10=144|

The server responds with a Heartbeat containing TestReqID=TEST123.

ResendRequest (MsgType = 2)

Requests retransmission of messages when a sequence gap is detected.

Example — Request Messages 5 Through 10

8=FIX.4.4|9=72|35=2|49=CLIENT1|56=BROKERET|34=4|52=20260312-14:35:30.000|7=5|16=10|10=156|

Gap Fill

The server may respond with a SequenceReset-GapFill for administrative messages that don't need resending:

8=FIX.4.4|9=78|35=4|49=BROKERET|56=CLIENT1|34=5|52=20260312-14:35:30.500|123=Y|36=8|10=170|

SequenceReset (MsgType = 4)

Resets the expected sequence number. Two modes:

GapFill Mode (Tag 123 = Y)

Used during resend to skip administrative messages:

Reset Mode (Tag 123 = N or absent)

Used for emergency sequence number reset:

Reject (MsgType = 3)

Session-level rejection when a message cannot be processed.

Session Reject Reason Codes

Sequence Number Management

Best Practices

• Persist sequence numbers to disk to survive application restarts
• Use ResetSeqNumFlag=Y on Logon only when explicitly agreed with Brokeret
• Monitor for sequence gaps and issue ResendRequests promptly
• Keep a message store for potential resend requests from the server

Sequence Reset on Daily Rollover

Brokeret performs a daily sequence number reset at 00:00 UTC. Clients should expect:

1. Server sends Logout at approximately 23:59:59 UTC
2. Client acknowledges with Logout
3. Both sides reset sequence numbers to 1
4. Client reconnects with MsgSeqNum=1

Connection Recovery

Reconnection After Disconnect

1. Reconnect TCP with the same SenderCompID and TargetCompID
2. Send Logon with the next expected outgoing sequence number
3. If server detects a gap, it sends a ResendRequest
4. If client detects a gap, it sends a ResendRequest
5. Once synchronized, normal messaging resumes

Clean Start

To start fresh without resynchronizing:

1. Send Logon with ResetSeqNumFlag=Y (Tag 141)
2. Set MsgSeqNum=1
3. Server acknowledges and resets its own sequence numbers

Next Steps

• Market Data — Subscribe to streaming quotes
• Order Execution — Submit and manage orders