Multicast Feed Handler

A high-performance multicast feed simulator & handler written in modern C++20.

The handler ingests timestamped messages over UDP multicast, applies a reordering window with gap/out-of-order/duplicate detection, and computes calibrated latency percentiles over time. The simulator emits a configurable message stream with optional impairments (bursts, drops, reorders).

This project exercises low-latency ingestion, sequence management, jitter measurement, and fault injection in a contained environment suitable for benchmarking.

Overview

The system consists of two components:

FeedSimulator

Synthetic multicast publisher that sends a timestamped, sequence-numbered message stream at a fixed rate. Optional impairments include:

• burst_ratio: emits bursts of messages with no inter-message spacing
• drop_ratio: randomly omits messages from the stream
• reorder_ratio: delays messages by a bounded number of sequence IDs

FeedHandler

UDP multicast consumer that performs:

• Timestamp calibration (subtracts steady_clock offset to measure jitter)
• Reordering window (buffered in-order delivery with gap/out-of-order/duplicate detection)
• Per-interval latency percentiles (p50, p95, p99, p99.9)
• CSV output (one row per stats interval)

The handler does not block on missing packets; impairments affect ordering, not timing, so latency primarily reflects calibrated jitter on localhost.

Build & Run (Visual Studio 2022)

Prerequisites

• Visual Studio 2022
• MSVC v143 toolset
• Windows SDK 10/11

Building

• Open the repository as a Visual Studio solution (.sln)
• Select configuration: x64 | Release
• Build Solution (Ctrl+Shift+B)

Running

Executables are produced under:

vs/bin/x64/Release/
    FeedSimulator.exe
    FeedHandler.exe

Example usage:
FeedSimulator.exe --config configs/simulator.json
FeedHandler.exe --config configs/handler.json

Example Configuration

Simulator:

{
  "group": "239.10.10.10",
  "port": 5001,
  "send_rate_msgs_per_sec": 10000,
  "duration_seconds": 25,
  "drop_ratio": 0.001,
  "reorder_ratio": 0.01,
  "reorder_delay_cap_msgs": 8,
  "stats_interval_ms": 2500
}

Handler:

{
  "group": "239.10.10.10",
  "port": 5001,
  "reorder_window_msgs": 128,
  "gap_timeout_ms": 2,
  "stats_interval_ms": 2500,
  "csv_path": "data/results.csv"
}

Results (summary)

Testbed: Windows 11 (24H2)
CPU: Intel Core i7-11800H (8c/16t)
Compiler: MSVC 19.44 (Visual Studio 2022 17.10), /O2 /GL
Transport: Localhost UDP multicast

Clean Run:
Message rate = 10,000 msg/s, duration = 25 s. No drops, no reorders.

• gaps / ooo / dup / overflow: all zero
• latency percentiles: extremely stable
• p50 ≈ 1 µs (post-calibration jitter)
• p95 ≈ 48 µs, p99 ≈ 192 µs

Impaired Run:
drop_ratio=0.001, reorder_ratio=0.01, reorder_delay_cap_msgs=8

• gaps: steadily increasing
• ooo: minimal but non-zero
• duplicates / overflow: remain near zero
• latency percentiles: nearly identical to clean run (impairments change ordering, not timing)

Charts

Throughput (Clean vs Impaired)

These plots show that the handler keeps pace with the simulator and does not fall behind under load.

Latency Percentiles Over Time (Clean vs Impaired)

Latency percentiles stay stable across intervals because localhost jitter is low and measurements are bucketized.

Integrity Counters (Clean vs Impaired)

Integrity counters reflect impairments: gaps rise with drops, OOO appears with reordering, and dups/overflow stay near zero.

Notes

• Latency numbers represent incremental jitter, not absolute NIC or network delay.
• The reordering window is designed to recover small bounded reorders; overflow indicates packets arriving too far ahead to buffer.
• This project intentionally omits matching, book-building, or trading logic: it focuses on feed ingestion, normalization, and measurement.