Game communication for .NET

One port.
Six delivery semantics.

A game-focused protocol and library built directly on QUIC. Match each message to the transport behavior it needs without maintaining separate networking stacks.

Explore the modes Inspect the source

Development status: under construction

transport.map

GAME CLIENTQuiclyPeer

GAME SERVERQuiclyServer

6 modesLossy, reliable and bulk delivery

1–6 byte headerCompact application framing

1 UDP portDatagrams and streams together

.NET 10 + 11Windows, Linux and macOS targets

Delivery vocabulary

Use the right guarantee
for every message.

Positions should not queue behind stale positions. Chat must arrive in order. Large world data needs progress and resume. QUICLY expresses each case as a channel mode.

QUIC DATAGRAM

Unreliable Sequenced

Deliver only messages newer than the last accepted sequence. Intended for positions, aim and rapidly changing state.

QUIC DATAGRAM

Unreliable Unordered

Send independent lossy events without ordering overhead: bullets, effects and disposable signals.

PERSISTENT STREAM

Reliable Ordered

Preserve every message in sequence for RPC, chat, inventory and matchmaking.

GROUP STREAMS

Reliable Unordered

Deliver every message while independent flush groups avoid application-level head-of-line blocking.

DATAGRAM + RETRY

Reliable Latest

Keep the newest value per key and retry until that version arrives. Obsolete versions disappear from the queue.

DEDICATED STREAM

Bulk

Move files, assets and snapshots of any size. Split into ranges, each checksummed and re-sent on its own, with progress, cancellation and resume.

Hot-path architecture

Built around the game loop.

The session layer is designed for explicit ownership, predictable polling and caller-controlled memory. MsQuic supplies encrypted transport; QUICLY supplies game-oriented semantics.

Data-oriented state with struct arrays and cache-local tables
Explicit buffer ownership for send and receive paths
Poll and drain control at the cadence of the host loop
Deterministic simulation for protocol and failure testing

APPLICATIONGame systems

state · events · RPC · assets

TEDD.QUICLYChannels + session

framing · scheduling · retries

HOST SERVICESServer + HTTP

admission · ACME · HTTP/3

TRANSPORTMsQuic

QUIC · TLS 1.3 · UDP

Declarative channels

Describe intent once.
Validate at startup.

Both peers use the same immutable channel table. IDs, names, modes and options are validated before a session starts.

Channels.cs

var channels = ChannelTable.Create()
    .Add(2, "state",  ChannelMode.UnreliableSequenced)
    .Add(3, "events", ChannelMode.ReliableUnordered)
    .Add(4, "world",  ChannelMode.Bulk)
    .Build();

CANONICAL TABLE HASHPEER COMPATIBILITY CHECKFAIL-FAST VALIDATION

Motivation

Why this library
exists.

QUICLY began as a replacement for a stack that had served well for years. The goal was a standardised, encrypted protocol that still speaks the game loop's language.

For years I have been using the lidgren-network-gen3 library, which I truly love. A great piece of software. But partially due to less updates lately, and partially that I wanted a standardized protocol with encryption, I developed a new version under QUIC with aim for HTTP/3 and WebAssembly standards. With benchmarks on my game engine, Tedd.Quicly shows promising results.

Tedd HansenAuthor, Tedd.QUICLY

12.8× – 122×More payload delivered per second across four workloads

≈ 99.9%Fewer managed bytes allocated per delivered MiB

TLS 1.3Encrypted throughout, while Lidgren ran unencrypted

Delivered payload

MiB per second — higher is better

32 KiB unordered chunk batches 16.8×

Lidgren7.096.62–7.17

QUICLY119.39115.59–122.28
Equal 64 KiB ordered messages 27.7×

Lidgren7.977.51–8.65

QUICLY220.63215.98–224.29
File slices, 1,374 B → 64 KiB 122.0×

Lidgren1.801.06–1.81

QUICLY219.92219.05–221.76
Complete 20 MiB objects, bulk mode 12.8×

Lidgren9.218.46–9.69

QUICLY118.32115.73–136.61

060120180240

Median of three fresh-process runs, with the observed min–max beneath each value. Loopback, one sender and one receiver in one process.

Managed allocation

.NET bytes allocated per delivered MiB — lower is better

32 KiB unordered chunk batches −99.60%

Lidgren3,518,177

QUICLY14,185
Equal 64 KiB ordered messages −99.88%

Lidgren3,050,849

QUICLY3,723
File slices, 1,374 B → 64 KiB −99.86%

Lidgren2,855,585

QUICLY3,872
Complete 20 MiB objects, bulk mode −99.86%

Lidgren3,125,505

QUICLY4,244

01 MB2 MB3 MB4 MB

Not native allocation, retained memory, peak memory, or proof of end-to-end zero-copy transfers.

CPU cost

Milliseconds of process CPU per delivered MiB, both endpoints — lower is better

32 KiB unordered chunk batches +16%

Lidgren7.306.08–13.91

QUICLY8.488.19–9.12
Equal 64 KiB ordered messages +8%

Lidgren7.466.10–7.54

QUICLY8.027.92–8.05
File slices, 1,374 B → 64 KiB −49%

Lidgren15.4112.29–21.54

QUICLY7.937.81–7.98
Complete 20 MiB objects, bulk mode +75%

Lidgren6.254.43–7.03

QUICLY10.919.69–10.97

0481216

QUICLY spends more CPU per second while delivering far more data per second. No profile here separates encryption cost from packet processing, copies or scheduling.

How to read these numbers

Transport only. These measure payload moved between two endpoints. Not frame rate, world generation or rendering.
Loopback, one machine. AMD Ryzen 9 5950X, Windows 11 Pro, .NET 11 preview, IPv4 loopback, one sender and one receiver in a single process. Not the internet, not packet loss, not many clients.
Three runs per case. Medians of three fresh-process runs. Three samples is not a narrow confidence interval, particularly for CPU.
Not a like-for-like security comparison. Lidgren ran unencrypted; QUICLY ran TLS 1.3 throughout.
The 122× file case is not pure QUIC. It also uses larger slices and drops a temporary allocation and copy. The equal-size ordered-message row isolates the transport difference.
Optional bulk checksums are close to free. Disabling the range checksum moved 20 MiB object throughput from 118.32 to 119.49 MiB/s, inside run-to-run variation.

Measured 20 September 2026 against QUICLY 7b2688c, on a game engine using both libraries in turn. Full method, raw samples and reproduction notes live with the benchmark harness.

Project status

Core systems are merged.
The end-to-end suite is next.

Core, transport, HTTP/3, the WebTransport carrier, testing, ACME, server, client, HTTP and replication modules are present. Real-MsQuic session end-to-end work, serving raw QUIC and HTTP/3 on one port, and browser support remain on the roadmap.

Read implementation status Browse the repository

MERGEDCore + channel engines

MERGEDMsQuic transport

MERGEDClient + server hosts

MERGEDHTTP, HTTP/3 + ACME

MERGEDWebTransport over HTTP/3

NEXTReal-session end-to-end suite

LATEROne port for QUIC + HTTP/3, browser transport

One port.Six delivery semantics.

Use the right guaranteefor every message.