LibHFTFlavors.NET FIX engine

Two flavors for C#

.NET FIX engine for C#.

The LibHFT .NET FIX engine comes in two flavors for C# applications. .NET Pure is a managed session and codec implementation with no native provider; .NET Native puts a managed application boundary over the hftnet / C++ provider and its state machine.

.NET Pure · 87/87 API.NET Native · 86/87 API27/27 session behaviors eachHP · 19–20 Sep 2026

Managed or native-backed

Where your C# session actually runs.

.NET PURE

Independent C# engine

Session lifecycle, sequence recovery, connectivity and durable state are implemented in C#. 87 of 87 tracked API capabilities (3 recorded n/a) and all 27 session behaviors. Runs on ordinary sockets.

.NET Pure scope and results →
.NET NATIVE

C# API over hftnet / C++

A managed application boundary over the native provider: those behaviors deliberately delegate to the C++ core, and 13 of the 27 session behaviors are recorded as inherited. 86 of 87 tracked API capabilities (1 absent, 3 n/a).

.NET Native scope and results →

Both load the bundled QuickFIX-format dictionaries for FIX 4.0 to FIX 5.0 SP2 and FIXT 1.1 at runtime, carry typed builders and views for the same 17 message families, and record writer-lock arbitration, standby retry, promotion and sequence restore for high availability. FAST 1.1 differs: .NET Pure has generated whole-message codecs, while .NET Native binds native stop-bit and presence-map primitives and keeps its whole-message codecs managed. FIX versions supported and binary-protocol scope →

.NET Pure

A managed FIX engine, no native provider.

Because .NET Pure uses ordinary sockets, kernel bypass reaches it through preload only:

  • Solarflare Onload and Mellanox VMA: available beneath .NET Pure as interposers.
  • TCPDirect and SocketXtreme: not available; they need a vendor SDK and a native transport.
  • ef_vi / ibverbs raw receive: not available.

HP reference campaign, collected 19 September 2026 and recorded 20 September 2026 on the HP reference host (Intel Xeon Gold 6254): one session at a sustained 50,000 requests per second, response time from the intended send slot, so scheduler delay is included.

Transportp50p99p99.9Maximum
Kernel TCP20.794 µs24.811 µs28.828 µs60.730 µs
Solarflare Onload11.473 µs11.873 µs12.004 µs30.937 µs
Mellanox VMA11.999 µs12.231 µs12.368 µs32.406 µs

In the diagnostic SCAN sweep of 29 September 2026 (kernel TCP, one session), .NET Pure held 50,000 requests per second at 34.050 µs p50 and first saturated at 75,000 per second. .NET Pure FIX engine benchmarks →

.NET Native

C# on top of the native engine.

.NET Native trades an independent implementation for the native transport integrations of the C++ FIX engine: Onload and VMA by preload, TCPDirect and SocketXtreme with initiator and acceptor routes, and raw receive through the vendor-neutral facade.

Same HP reference campaign, 19–20 September 2026, 50,000 requests per second:

Transportp50p99p99.9Maximum
Kernel TCP15.481 µs16.537 µs19.042 µs73.840 µs
Solarflare Onload6.788 µs7.203 µs7.310 µs48.914 µs
Mellanox VMA7.483 µs7.753 µs8.316 µs49.963 µs
Solarflare TCPDirect6.347 µs6.516 µs6.610 µs46.143 µs
Mellanox SocketXtreme7.393 µs7.971 µs9.310 µs51.054 µs

In the diagnostic SCAN sweep of 29 September 2026, .NET Native held 75,000 requests per second at 27.221 µs p50 and first saturated at 100,000 per second. .NET Native FIX engine benchmarks →

Each HP percentile is the mean of three 30-second runs after a 5-second warm-up; the maximum is the mean of the three maxima. The SCAN sweep ran with BrokerForge housekeeping processes on other cores and stays labelled diagnostic. How the campaign was measured · capacity brackets · .NET codec microbenchmarks · .NET engine comparison

QuickFIX/n counterpart

Coming from QuickFIX/n.

Both .NET flavors are LibHFT’s counterparts of QuickFIX/n ↗. Reuse its XML dictionaries after validation; classify each QuickFIX/n setting as direct, semantic translation, application-owned, unsupported or sensitive; then port callbacks against the chosen flavor and prove reconnect, resend, gap fill and durable-write refusal before cutover.

Migrating from QuickFIX to LibHFT →

Selection

Picking a .NET flavor.

  • Choose .NET Pure when a standalone managed engine is the architectural requirement.
  • Choose .NET Native when the C# application should reuse the C++ engine and its native transports, TCPDirect and SocketXtreme included.
  • The same split exists for the JVM: Java FIX engine (Java Pure or Java/JNI). The Rust FIX engine is independent.
  • Benchmark the exact flavor, transport, message path and deployment hardware you will operate.