# NetCoreServer: a socket library that ships its own benchmark suite

> A C# library covering TCP, SSL, UDP, multicast, Unix domain sockets, HTTP and WebSocket behind a common session model, with twenty example projects and a benchmarks directory that the README treats as a first class feature.

**chronoxor/NetCoreServer** — Ultra fast and low latency asynchronous socket server & client C# .NET Core library with support TCP, SSL, UDP, HTTP, HTTPS, WebSocket protocols and 10K connections problem solution

- Repository: https://github.com/chronoxor/NetCoreServer
- Website: https://chronoxor.github.io/NetCoreServer
- Stars: 3,132 · Forks: 629
- Language: C#
- License: MIT
- Published: 2026-10-06 · Updated: 2026-10-06 · Language: en
- Canonical page: https://hysenlabs.com/projects/chronoxor-netcoreserver

## One session base class per transport, twenty example projects

The feature list is short enough to state exactly. Supported transports are TCP, SSL, UDP, UDP multicast and Unix domain sockets. Supported web protocols are HTTP, HTTPS, WebSocket and secure WebSocket. On top of that the library claims Swagger OpenAPI iterative documentation support and integration with Fast Binary Encoding, a higher level message protocol written by the same author and linked as a separate repository.

The examples directory carries one client and one server project per case, twenty in total: `TcpChatServer` and `TcpChatClient`, `SslChatServer` and `SslChatClient`, `UdpEchoServer` and `UdpEchoClient`, `UdpMulticastServer` and `UdpMulticastClient`, `UdsChatServer` and `UdsChatClient`, `WsChatServer` and `WsChatClient`, `WssChatServer` and `WssChatClient`, plus the HTTP, HTTPS and Proto pairs.

That one-to-one pairing is the clearest statement of the library's shape. Every protocol is demonstrated as a matched pair, so you can read the server side and the client side of a protocol side by side rather than piecing it together from documentation. The `ProtoClient` and `ProtoServer` pair is the one that uses Fast Binary Encoding rather than raw text.

The rest of the tree follows the same pattern: `source/` for the library, `tests/`, `performance/` for the benchmarks, `proto/` for the message protocol definition, `tools/`, `build/` for the build scripts, and `www/` for the documentation site that publishes to `chronoxor.github.io`.

## Building from source needs cmake, 7-Zip and a shell script

The install story is unusually demanding for a library that also ships on NuGet, and it is worth reading before you decide how to consume it. Cloning and building is three commands:

```shell
git clone https://github.com/chronoxor/NetCoreServer.git
cd NetCoreServer
```

On Linux and MacOS the build is a script in the `build/` directory:

```shell
cd build
./unix.sh
```

On Windows you either open `NetCoreServer.sln` in Visual Studio or run the batch script:

```shell
cd build
vs.bat
```

The requirements list behind that is Linux, MacOS or Windows, .NET 6.0, 7-Zip, cmake, git and Visual Studio, with Rider named as optional. So even the macOS and Linux path expects Visual Studio in the list, which suggests the list covers all platforms collectively rather than each one.

What the build produces is stated as a `release` directory with three zip files: the server assembly, the benchmarks, and the examples. Building three separate archives rather than one package is a small thing that tells you the project is organised by deliverable, which is also how the repository tree is arranged.

There is a `global.json` in the root, which pins the SDK the project expects, and the CI badges in the README cover Linux, MacOS and Windows separately through three workflow files.

## The session subclass is the whole API surface

The TCP chat server example is the shortest way to understand the library. You subclass `TcpSession`, override two lifecycle methods, and the base class handles the socket:

```csharp
class ChatSession : TcpSession
{
    public ChatSession(TcpServer server) : base(server) {}

    protected override void OnConnected()
    {
        string message = "Hello from TCP chat! Please send a message or '!' to disconnect the client!";
        SendAsync(message);
    }
}
```

The session takes its server in the constructor, `Id` identifies the session, and `SendAsync` writes to it. The example as described in the README handles multiple client sessions, multicasts any received message out to all of them, and can send an admin message directly from the server.

Everything else in the library is the same idea under a different base class: `SslSession`, `UdpSession`, `UdsSession`, `WsSession` for WebSocket, and the HTTP server with its own handler style. That consistency is the main argument for the library, because a service that speaks TCP today and WebSocket tomorrow, or that needs Unix domain sockets for local IPC and TCP for remote, does not have to rewrite its protocol handling.

The cost is that you are writing against this library's model rather than against ASP.NET's. If your application is primarily request and response HTTP, Kestrel with minimal API endpoints is the more natural fit, and this library earns its place when the transport is the interesting part.

## Benchmark coverage is organised by scenario, not by protocol alone

The `performance/` directory is given enough room in the README's table of contents that the benchmark structure is visible even without the numbers, and the structure is the interesting part.

Round-trip benchmarks cover TCP, SSL, UDP, Unix domain socket, the simple protocol, WebSocket and secure WebSocket. Multicast benchmarks repeat that same list, so you can compare point to point against broadcast on the same transports. Web server benchmarks are separate again, with HTTP and HTTPS trace servers.

Three dimensions rather than one is the right way to benchmark a socket library. A library can win on round trip latency and lose badly on fan out, and a number quoted without saying which of these you are looking at tells you very little.

The project's own description says ultra fast and low latency, and its repository description adds a 10K connections problem solution as a goal. Those are marketing claims, and the README does not state the hardware, the operating system or the message sizes the benchmarks were run on, which are the three details you would need to compare them against your own workload. Treat the benchmark section as a reason to go and read the numbers in the documentation site rather than as a result to quote.

There is also an `images/` directory in the tree, which is where the benchmark charts live, and the documentation site at `chronoxor.github.io/NetCoreServer` is linked as the place for downloads and further reading.

## Two unusual root files and a release history that stopped in 2023

Two files in the repository root are unusual enough to call out. `CLAUDE.md` is instructions written for an AI coding assistant, which tells you the author uses one and has committed the guidance to the repository rather than keeping it private. `TODO.md` is a live task list in the root, which is unusual for a library at this level of adoption and gives a rare direct view of what is unfinished.

The release history is short and recent entries are small. Version 8.0.1 and 8.0.3, both on 2023-11-19, fixed the WebSocket close status frame. Version 8.0.4 on 2023-12-08 fixed a bug in the HTTP server file cache update logic, referenced as issue 276, where the cache was not being updated.

That is the entire published release list in this repository view, and the last push was on 2026-09-16, which means work has continued in the repository without producing new NuGet releases. That gap is the single most important practical fact for anyone considering the library: check whether the commit history since 8.0.4 contains what you need before you take a dependency on the packaged version.

There are 184 open issues against 3,132 stars, which is a high absolute number for a socket library. Some of that is normal for a project with this many protocol combinations, but it is worth sampling the tracker to see whether open questions go unanswered.

## How this compares to the usual .NET socket alternatives

Against Kestrel, the comparison is about what you are building. Kestrel wins if you are serving HTTP, because it is Microsoft maintained, it is integrated with the framework, and its diagnostics are first class. NetCoreServer wins if your traffic is not HTTP, or if you need UDP, multicast or Unix domain sockets with the same API as your TCP paths, or if you want explicit control over the session lifecycle.

Against other socket libraries in the ecosystem, the usual comparison is against SuperSocket and WebSocketSharp, both of which appear in the related searches for this project. SuperSocket is the closer analogue in scope. The differentiator here is the sibling Fast Binary Encoding project, which gives you a typed message layer without inventing a serialisation format, and the fact that the same author maintains both.

Against a Rust or Go implementation, this library will lose on raw throughput and win on operational fit. If your team is a .NET shop and the service is a socket server rather than a web service, staying in one language and one deployment artefact is usually worth more than the last increment of latency.

One caveat on all of the above: the README page here stops after the first example, so the benchmark numbers, the production and development OpenSSL sections and the certificate authority instructions are documented on the project site rather than in the repository README.

## Conclusion

NetCoreServer is worth considering when you need raw socket throughput rather than a web framework, and the session model is the reason: the same `TcpSession` shape covers TCP, SSL, UDP, Unix domain sockets and WebSocket, so a protocol change is usually a base class change. The costs are equally concrete. You need cmake and 7-Zip to build from source, the examples are tied to a session subclass style rather than ASP.NET middleware, and the newest release is 8.0.4 from 2023-12-08, so check the commit log against the NuGet package you are considering. Start with `examples/TcpChatServer/` to see the shape of the API, then read `TODO.md` and `CLAUDE.md`, which are unusual files to find in a library repository and both hint at where the author thinks the work is unfinished.

## FAQ

### Can I write an HTTP server in C#?

Yes, and this repository includes one. NetCoreServer ships HTTP and HTTPS server and client examples under `examples/HttpServer/` and `examples/HttpClient/`, alongside an HTTPS pair, and the feature list claims Swagger OpenAPI documentation support. For a plain web API, ASP.NET Core's Kestrel is the more conventional choice.

### Which protocols does NetCoreServer support?

TCP, SSL, UDP, UDP multicast and Unix domain sockets on the transport side, and HTTP, HTTPS, WebSocket and secure WebSocket on the web side. A higher level message protocol based on Fast Binary Encoding is also supported, demonstrated by the `examples/ProtoServer/` project.

### How do I build NetCoreServer from source?

Clone the repository, then run `cd build` followed by `./unix.sh` on Linux or MacOS, or `vs.bat` on Windows, or open `NetCoreServer.sln` in Visual Studio. The build needs .NET 6.0 plus cmake, 7-Zip and git, and it produces a release directory with assembly, benchmark and example archives.

## Sources

- [chronoxor/NetCoreServer on GitHub](https://github.com/chronoxor/NetCoreServer)
- [License: MIT](https://github.com/chronoxor/NetCoreServer/blob/main/LICENSE)
- [Project website](https://chronoxor.github.io/NetCoreServer)
- [README](https://github.com/chronoxor/NetCoreServer/blob/main/README.md)
- [Releases](https://github.com/chronoxor/NetCoreServer/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/chronoxor-netcoreserver