4.5 million messages
Recorded for each transport—not a one-off trace.
The evidence-led FIX protocol engine
LibHFT
The shortest, most defensible path from FIX message to market.
LibHFT is an evidence-led low-latency FIX engine family across six language/runtime flavors: C++, Java Pure, Java/JNI, .NET Pure, .NET Native, and Rust Pure. Performance claims stay tied to measured workloads and stated conditions.
Public simulator access: username atrekes_demo · password demo_password.
Language surfaces
C++, Java Pure, Java/JNI, .NET Pure, .NET Native, and Rust Pure.
Tail evidence
Measured transport results and percentile markers stay tied to the stated benchmark setup.
Visible operations
The read-only Workbench makes fleet health, session state and conformance evidence inspectable locally.
$ bench_roundtrip --scenario nos_er --load 50000
TCPDirect p504.285 µsmeasured at sustained load
p994.412 µsconsistent through the tail
p99.94.595 µs4.5 million recorded messages
In the retained September reference campaign, the C++ engine sustained a 50,000-message-per-second NewOrderSingle → ExecutionReport load with fixed client and server cores. The distribution below shows the measured behaviour of kernel TCP, TCPDirect and SocketXtreme. See the latest codec results and per-language CDFs →
Performance you can interrogate
Fast at the median. Controlled at the tail.
Latency is only valuable when the measurement contract is credible. LibHFT records the message path, transport, cores, samples, percentile tails and comparable work—not just a convenient headline.
MEASURED LATENCY DISTRIBUTIONC++ engine at sustained load
lower is better
50,000 every second
The load remains constant throughout each measurement.
Three transport paths
Kernel TCP, TCPDirect and SocketXtreme, shown separately.
MEASURED C++ TRANSPORTS
One active FIX session at a sustained 50,000 messages per second. Latency in microseconds; lower is better.
| Transport | p50 | p99 | p99.9 |
|---|---|---|---|
| Kernel TCP | 15.448 | 17.610 | 20.800 |
| TCPDirect | 4.285 | 4.412 | 4.595 |
| SocketXtreme | 5.331 | 5.995 | 7.183 |
Architecture freedom without a FIX rewrite
Six engine flavors. One shared FIX capability set.
Choose the language and integration model that fits your team. Each flavor is built around the same core LibHFT FIX capabilities, with implementation details tailored to C++, Java Pure, Java/JNI, .NET Pure, .NET Native, or Rust Pure.
6surfaces in the generated parity matrix
27/27session behaviours across all six surfaces
17/17tracked typed FIX message types across those surfaces
CHOOSE YOUR ENGINE FLAVOR
Six ways to build your FIX stack.
All six flavors belong to one LibHFT engine family. Choose a standalone implementation or a language API over the C++ core to match your team's architecture.
Native reference engine
For teams that own the native execution path and want direct control of the core deployment and performance work.
Independent JVM engine
For Java estates that want the FIX engine implemented in Java, without using the C++ engine through JNI.
Java API, C++ core
For Java applications that need a familiar JVM-facing API while reusing the native C++ engine beneath it.
Independent C# engine
For .NET teams that want the FIX engine implemented in C#, without using the C++ engine as the provider.
C# API, native provider
For .NET applications that want a managed boundary over the hftnet / C++ provider path.
Independent Rust engine
For Rust teams that want the FIX engine implemented in Rust, without using the C++ engine as the provider.
| Surface | Implementation ownership | Tracked API capability | Session protocol |
|---|---|---|---|
| C++ | Native C++ reference | 78/791 absent · 11 n/a | 27/27 |
| Java Pure | Independent Java session and codec engine | 88/902 absent | 27/27 |
| Java/JNI | Java API over the C++ engine | 88/891 absent · 1 n/a | 27/2713 inherited from engine |
| .NET Pure | Independent C# session and codec engine | 87/873 n/a | 27/27 |
| .NET Native | C# API over hftnet / C++ engine | 86/871 absent · 3 n/a | 27/2713 inherited from engine |
| Rust Pure | Independent Rust session and codec engine | 79/7911 n/a | 27/27 |
Modernise without a capability downgrade
The source-derived inventory checks portable API coverage separately from protocol behavior. Review its explicit absences and n/a rows before selecting a runtime; the headline totals are not a claim that every surface is identical.
Make ownership explicit
Independent managed engines and C++-backed providers are labelled separately. Inherited protocol behaviour is visible, never implied by a generic “supported” badge.
Build for the failure path too
The 27-behaviour protocol ledger covers logon, heartbeat, resend, gap fill, rejects, reconnect, durable sequence state and controlled recovery—not only happy-path sends.
The capability inventory is generated and checked against source in conformance runs. “n/a” is an intentionally recorded scope decision, not a hidden gap. Inspect the binding coverage summary
Protocol breadth, without a reinvention project
Bring the QuickFIX dictionary. Choose the better engine.
LibHFT loads QuickFIX-format XML dictionaries at runtime, so the protocol asset your counterparties already speak can move with you. Standard versions are bundled, generated-table paths stay distinct from runtime loading, and the proof is kept in the source tree.
STANDARD FIX DICTIONARIESFIX 4.0 → FIX 5.0 SP2
Bundled QuickFIX-format inputs for FIX 4.0, 4.1, 4.2, 4.3, 4.4, 5.0, 5.0 SP1, 5.0 SP2 and FIXT 1.1—runtime-loadable on every LibHFT surface.
9bundled standard dictionary inputs
6runtime surfaces that load them
Whole-message codec paths with explicit provider boundaries.
Generated FAST codecs are available in C++, Java Pure and .NET Pure. Java/JNI and .NET Native bind native stop-bit and presence-map primitives; their whole-message codecs remain managed. Real captured-frame evidence is not venue certification.
Codec, bus and venue evidence—not one vague label.
Generated SBE codecs, framing and UDP/multicast/mapped-memory paths are available across native and managed implementations. The native venue lane capture-replays CME MDP 3.0 market data; CME iLink 3/FIXP and B3 Entry Point remain explicitly scoped framing or schema slices, not completed venue session runners.
Fail over without silently resetting sequence state.
Instances arbitrate one durable store with an OS file lock. A standby retries with backoff; after promotion it restores sequence numbers before reconnecting. This is active/passive—not replication or hot/hot HA—and depends on a shared filesystem with working lock semantics. Scenario depth differs by provider; see the HA evidence before deployment.
EXCHANGE-PROTOCOL EVIDENCE
Named feeds. Independently sourced packets. Exact boundaries.
LibHFT’s native venue library does not stop at generic binary framing: its decoder and framing slices are replayed against independently sourced packet captures, so a self-consistent parser cannot certify itself.
Capture replay exercises actual packet structure alongside the implementation and marks the exact protocol/message boundary. That is stronger evidence than a hand-built fixture, while still remaining distinct from exchange certification.
SELECTED CAPTURE-REPLAYED PROTOCOL FAMILIES
Evidence boundary: the native venue inventory includes decoder/framing slices at protocol-specific scope. “Capture-replayed” is not a claim of a production session runner, counterparty onboarding, certification or venue support for every message in a family.
QUICKFIX MIGRATIONKeep your protocol assets. Prove the engine change.
Start with the QuickFIX-format XML dictionaries LibHFT can load at runtime. Assess C++, QuickFIX/J and QuickFIX/n settings, resolve configuration differences, then verify session and recovery behaviour with replay and readiness checks before cutover.
Read the settings assessment and migration guide
QUICKFIX IMPLEMENTATIONS
QuickFIX/C++ ↗
QuickFIX/J ↗
QuickFIX/n ↗
External open-source projects; not affiliated with Atrekes.
Protocol coverage is generated from checked-in artefacts and conformance-checked. FAST, SBE and venue scopes are deliberately qualified above; limited capture evidence is not venue certification. Read the FIX Trading Community standards Inspect protocol coverage Inspect venue evidence Inspect HA evidence
Hardware-aware networking
Solarflare and Mellanox: three different acceleration paths.
“Kernel bypass” is not one feature. LibHFT separates socket interposers, vendor user-space TCP stacks, and raw NIC receive APIs—each has different runtime, build, and evidence boundaries.
Solarflare Onload / Mellanox VMA
Preload onload or vma to accelerate ordinary BSD sockets beneath the application—no FIX-engine socket rewrite or vendor-specific session API. This path works beneath C++, Java, and .NET flavors, including Java Pure and .NET Pure. LibHFT verifies that the requested interposer is mapped before labeling a run with that transport; a loaded library alone does not prove acceleration.
Measured caveat: VMA was loaded but showed no acceleration on the pure-Java NIO path in one test; Onload did accelerate that same path. Validate the exact runtime, driver, and host.
TCPDirect / VMA SocketXtreme
Solarflare TCPDirect (zf) and Mellanox VMA SocketXtreme are dedicated user-space TCP stacks, not preload modes. LibHFT provides initiator and acceptor routes in C++, Java/JNI, and .NET Native; the matching vendor SDK and build option are required. Java Pure and .NET Pure use ordinary sockets instead.
The exact integration depends on the flavor, vendor SDK, build options, and initiator/acceptor role; use the coverage matrix to verify a target deployment.
Solarflare ef_vi / Mellanox ibverbs
Solarflare ef_vi and Mellanox raw-packet ibverbs receive Ethernet frames directly from the NIC, bypassing the TCP/IP stack. LibHFT exposes them through one vendor-neutral receiver API for native-backed C++, Java/JNI, and .NET native applications, so packet consumers can select hardware without changing their ingest interface.
Raw-verbs latency is a lower-layer reference measurement and must not be compared as if it were a FIX order round trip.
SOLARFLARE TCPDIRECT2.964 µs p50
p99 3.48–3.80 µs
MELLANOX SOCKETXTREME3.469 µs p50
p99 7.27–8.13 µs
MELLANOX VMA PRELOAD2.07× p50
3.80× p99 vs kernel baseline
RAW IBVERBS REFERENCE1.06 µs
Raw Ethernet latency; not a FIX session result
These figures are from a separate 5,000-sample-per-run networking campaign, not the sustained-throughput CDF above. TCPDirect and SocketXtreme shared a round-trip harness; percentiles vary across runs, and hardware, pinning, software versions, and topology matter. Read the transport comparison and coverage matrix Inspect the measured evidence
Operational visibility and recovery
See the fleet. Understand the limits.
LibHFT includes an operator-facing read-only Workbench alongside the engine. It helps inspect live health and evidence without turning the dashboard into an unreviewed control plane.
Local active/passive continuity
- One primary owns the durable store through file-lock arbitration.
- Standbys retry with backoff and refuse traffic until promoted.
- Promotion restores sequence state before reconnect.
- Implemented across all six runtime surfaces; evidence depth varies.
Not replicated state, cross-datacentre failover, or a guarantee for unverified network filesystems. Cross-host/shared-filesystem proof must match the deployment’s actual mount and lock behavior.
Review HA scenarios and constraintsFleet health, sessions, and conformance in one view
- Fleet and target health with degraded, faulted, and unknown states kept distinct.
- Session inspection for connection/sequence, availability, validation, and store facts.
- Conformance results and selected real simulator/fault scenarios.
- Manifest-owned targets; the browser cannot enter arbitrary hosts or ports.
The Workbench does not send session controls. Remote fleets need a local collector or trusted deployment-owned proxy; it is not an arbitrary network fetcher.
Open LibHFT WorkbenchThe demonstration Workbench is read-only and its displayed coverage is scenario-specific—not a promise that every fault or metric is equally verified on every provider. Inspect the Workbench design and verification boundaries
Proof, not performance theatre
Every claimed win has to do the work.
The latest qualified codec campaign compares 25 adapters across five languages, including all six LibHFT flavors. Checked numeric field work and 320 isolated mutation probes keep the work comparable; per-language CDFs show the top five engines by p50, with full ranked tables.
25codec adapters
5benchmark languages
320isolated field-work probes
0tolerance for skipped field work
The engineering advantage
Choose the engine that makes the critical path visible.
For firms where a few microseconds, a recovery edge case or an unmeasured tail can change an outcome, LibHFT turns the FIX stack into an engineering advantage. Start with the documentation, inspect the evidence, then design the deployment around your own hardware and market workflow.
Plan a LibHFT architecture session