Start here
One engine family, explicit implementation boundaries.
LibHFT exposes a common FIX capability model through six deployment flavors. Independent Java, C# and Rust engines sit alongside native C++ and managed APIs over the C++ core. The documentation keeps those ownership models visible so “supported” never hides where behavior actually runs.
Per-language overviews: C++ FIX engine · Java FIX engine · .NET FIX engine for C# · Rust FIX engine. New to the topic? Read what a FIX engine does.
Documentation map
Follow the question you need to answer.
Evaluate LibHFT
Choose a package, check prerequisites and complete a local FIX exchange in your runtime.
Start evaluating →Language flavors
Compare native, independent managed and native-backed deployment models, with generated API and session coverage.
Compare all six flavors →Protocol coverage
FIX/FIXT dictionaries, typed messages, FAST, SBE, FIXP and the boundary between codecs, sessions and venue certification.
Inspect protocol scope →Low-latency architecture
Session ownership, reusable buffers, managed-runtime boundaries and the cost of validation, stores and networking.
Explore the FIX engine architecture →Performance methodology
Understand workloads, hardware disclosure, percentiles, parity gates and what each published latency number includes.
Read the methodology →Benchmarks by flavor
Compare C++, Java Pure, Java/JNI, .NET Pure, .NET Native and Rust under one common FIX order workload.
Compare all six flavors →FIX microbenchmarks
Compare parsing, field extraction and building across 25 licensed adapters, with message selectors, top-five CDFs per language and same-host percentile tables.
Explore codec microbenchmarks →Engine comparison
Compare LibHFT with llfix, QuickFIX and the complete tracked engine roster using detailed percentile profiles and explicit evidence grades.
Compare FIX engines →Every compact benchmark result
Filter all stored result cells by machine, method, engine variant and scenario. Inspect CDFs, grades and original JSON.
Browse all compact results →Kernel bypass
Separate Onload/VMA interposition, TCPDirect/SocketXtreme user-space TCP and ef_vi/ibverbs raw receive paths.
Compare acceleration paths →Recovery and HA
Sequence state, resend, durable stores, promotion and the precise boundary of active/passive continuity.
Review recovery →Monitoring
Read-only fleet and session visibility through a source-neutral telemetry contract and allowlisted target manifest.
Operate with the Workbench →QuickFIX migration
Reuse QuickFIX-format dictionaries, assess settings, expose compatibility gaps and prove behavior before cutover.
Plan a migration →LibHFT overview
Return to the engine family, the measured C++ latency, the read-only Workbench and the evaluation path.
Explore the LibHFT FIX engine →Evidence model
Coverage is classified, not flattened.
The public documentation distinguishes source-symbol coverage, conformance behavior, measured performance and explicitly scoped boundaries. A generated codec is not automatically a complete venue connector; a raw NIC measurement is not a FIX round trip; a local active/passive test is not cross-datacentre replication.
Coverage summaries reflect the committed LibHFT evidence at publication time. Deployment decisions should be checked against the version and target environment being evaluated.