Evaluate LibHFT.

In the first terminal, build and start the simulator:

make -j2 libhft-sim libhft-sim-client
./bin/libhft-sim --profile order --execution book --port 9880 --quiet

In a second terminal, from the same C++ root:

./bin/libhft-sim-client --host 127.0.0.1 --port 9880 --timeout-ms 5000

The client sends eight orders, consumes execution reports and cancels resting orders. Success is exit status 0 with orders_sent=8, rejects=0 and ok=1. This is a framing/socket simulator exercise; the package’s C++ user guide covers the session-owner API.

Start the executor below first. Compile the shared Java client once:

example_dir=$(mktemp -d)
mkdir "$example_dir/classes"
find src/main/java -name '*.java' > "$example_dir/sources.txt"
javac --release 8 -d "$example_dir/classes" \
  @"$example_dir/sources.txt" examples/OrderClient.java
java -cp "$example_dir/classes" OrderClient pure-java examples/order-client.cfg

For Java/JNI, restart the executor with a fresh store, then build and load the matching native library:

make HFTJAVA_OPEN=1 TARGET_DIR="$example_dir/native" native
java -Djava.library.path="$example_dir/native" -cp "$example_dir/classes" \
  OrderClient jni examples/order-client.cfg

Set JAVA_HOME to the full JDK. In a development checkout also set LIBHFT_CPP_ROOT to the exact oss/cpp tree; a standalone package uses its pinned native headers. The client prints order accepted and ExecutionReport received and exits 0.

With a fresh executor running, select the managed provider:

dotnet run -c Release --project examples/OrderClient -- \
  managed examples/OrderClient/client.cfg

For .NET Native, restart the executor with a fresh store, then select the exact native build:

native_dir=$(mktemp -d)
make -C src/native HFTNET_PRIVATE=0 OUTDIR="$native_dir"
LIBHFTNET_LIBRARY="$native_dir/libhftnet.so" \
  dotnet run -c Release --project examples/OrderClient -- \
  native examples/OrderClient/client.cfg

In a development checkout set LIBHFT_CPP_ROOT to the exact oss/cpp tree before either build. The client prints order accepted and ExecutionReport received and exits 0. A native request fails if its library cannot load.

With a fresh executor running and the Rust toolchain installed:

cargo run --offline --example order_client -- examples/client.cfg

The client logs on, sends one order through a typed builder, consumes an ExecutionReport and sends Logout. Success is exit status 0 with Rust: order accepted and ExecutionReport received. The Rust client needs no C++ library; the example peer is a separate C++ process.

From the C++ package root, in a separate terminal:

make quickfix-filestore-executor-example
trial_dir=$(mktemp -d)
mkdir "$trial_dir/store"
sed "s|FileStorePath=./quickfix-filestore-executor|FileStorePath=$trial_dir/store|" \
  examples/quickfix_filestore_executor.cfg > "$trial_dir/executor.cfg"
./bin/quickfix_filestore_executor "$trial_dir/executor.cfg"

The executor listens at 127.0.0.1:9877 as LIBHFT_EXECUTOR, with peer COUNTERPARTY. The client configurations mirror those identities. It acknowledges orders with a NEW ExecutionReport; it does not fill them.

Run one client at a time. Stop the executor with Ctrl-C and use a new trial directory before each provider run. The supplied clients reset their local demo sessions; retain production stores and agree reset policy separately. Stop both processes before removing their trial files.