Class FixSession

java.lang.Object
com.quantfinlib.fix.FixSession
All Implemented Interfaces:
AutoCloseable

public final class FixSession extends Object implements AutoCloseable
FIX 4.4 session over TCP — initiator or acceptor — implementing the session protocol needed to trade: Logon handshake, Heartbeats with TestRequest probing and staleness disconnect, sequence-number tracking with gap detection, Logout handshake, and the application flow NewOrderSingle out / ExecutionReport in (or the reverse, on the venue side). Zero dependencies.

Gap recovery: inbound gaps trigger a ResendRequest(2) and out-of-order messages are dropped until redelivered; inbound ResendRequests are serviced from an in-session message store — application messages are replayed with PossDupFlag(43)/OrigSendingTime(122) and admin runs are coalesced into SequenceReset-GapFill(4). Duplicates (PossDup below the expected seqnum) are suppressed; a too-low seqnum without PossDup disconnects the session.

Persistence: sessions default to an in-memory FixSessionStore (sequence numbers reset per connection); pass a FileSessionStore to the initiate/accept overloads for sequence-number continuation across restarts, with ResendRequests serviced from messages sent before the reconnect.

ResetSeqNumFlag(141): FixSession.Config.withResetOnLogon() makes the initiator send 141=Y and restart both counters at 1; receiving a Logon with 141=Y (and 34=1, per spec) resets the inbound expectation to 1 and — on the side that did not initiate the reset — the outbound counter too, persisted, with the acceptor confirming 141=Y back. This is the standard escape hatch when the two sides' stores have diverged: without it a fresh peer's seq 1 reads as "too low" against a durable store and the session dies on sight. One stated caveat: the message store is not wiped on reset, so until an old sequence number is naturally overwritten, a post-reset ResendRequest could replay a pre-reset message stored under it — reset into a fresh store when replay purity matters.