# SuperSocket 2.1.0: A .NET Socket Server Framework Built Around Pipeline Filters > SuperSocket is an Apache-2.0 C# framework for building custom TCP, UDP and WebSocket servers on modern .NET. Its pipeline filter model is the whole design, and it is also the main thing you have to learn before it pays off. **kerryjiang/SuperSocket** — SuperSocket is a high-performance, extensible socket server application framework for .NET. It provides a robust architecture for building custom network communication applications with support for multiple protocols including TCP, UDP, and WebSocket. - Repository: https://github.com/kerryjiang/SuperSocket - Stars: 4,237 · Forks: 1,163 - Language: C# - License: Apache-2.0 - Published: 2026-09-23 · Updated: 2026-09-23 · Language: en - Canonical page: https://hysenlabs.com/projects/kerryjiang-supersocket ## What SuperSocket Is For, and Who Ends Up Using It SuperSocket targets a specific gap: .NET gives you Socket and it gives you ASP.NET Core, and neither is a good fit when you need a long-lived connection speaking a protocol you define. The README lists the intended cases as real-time communication systems, IoT device connectivity, game servers and chat applications, plus "any scenario requiring custom network protocols." Those have a common shape. Connections stay open for minutes or hours, messages arrive as byte streams that must be split into frames, and the server has to track per-connection state. The audience is therefore a .NET developer who already knows what their wire format looks like. SuperSocket does not invent a protocol for you. It gives you the connection handling, the session object, the dispatch layer and the decoding pipeline, and expects you to fill in the part that turns bytes into your message type. If you are looking for a framework that ships a ready-made protocol, this is the wrong shelf. ## Pipeline Filters Are the Core Mechanism The README describes a "pipeline-based processing model that allows for efficient handling of incoming data with customizable filters." In practice the incoming byte stream passes through a chain of filters, and the filter is where protocol decoding lives. A length-prefixed protocol needs one filter; a line-delimited protocol needs a different one; a fixed-header protocol needs another. The repository's samples directory includes CustomProtocol and SwitchPipelineFilter, which suggests both the single-filter case and the case where the filter changes during a connection's life, for example after a handshake. Above the filter sits the session. SuperSocket manages "connection lifecycles from establishment to termination," so the framework owns accept, close and error paths, and your code sees a session object rather than a raw socket. Above that sits the command layer, described as a "command-based processing model to handle client requests efficiently." That is the part that makes the framework feel like a server framework rather than a socket wrapper: a decoded package can be routed to a handler by type or by name instead of a switch statement in a receive callback. The transports are pluggable. TCP, UDP and WebSocket are built in, and the NuGet package list reflects the split: SuperSocket.ProtoBase for the decoding primitives, SuperSocket.Connection, SuperSocket.Server, SuperSocket.Command, SuperSocket.Udp, SuperSocket.WebSocket.Server, plus SuperSocket.Client and SuperSocket.Client.Proxy on the outbound side. There is also SuperSocket.Kestrel, which is the package to look at if you want the WebSocket transport to ride on the ASP.NET Core server rather than a standalone listener. The dependency injection, configuration and logging integration mentioned in the README comes from that same modern .NET posture. ## Installing SuperSocket and Getting an Echo Server Running The README points at the NuGet package table rather than giving install steps, so the entry point is the SuperSocket package on nuget.org. The repository also carries a dotnet-install.sh at the top level and a global.json, which pins the SDK the solution expects. The README does not print a host-building snippet, so the reliable path is the samples directory. ConsoleEchoServer and EchoServer are the smallest starting points, and samples/samples.sln builds them together. The repository is public at github.com/kerryjiang/SuperSocket, so clone it and open that solution to see a working host before writing your own. For a protocol of your own, the CustomProtocol sample is the one to read, because it shows where the pipeline filter plugs in. For a WebSocket server, WebSocketServer and WebSocketPushServer cover the two shapes: request handling and server-initiated push. CommandServer shows the command dispatch layer, and ConfigSample shows configuration-driven setup. The README does not document a CLI or a project template, so expect to copy a sample and edit it rather than scaffold from a command. ## Where SuperSocket Stops Helping The framework's scope boundary is decoding. The README says protocol abstraction is achieved "through pipeline filters," which means the abstraction is a place to put your code, not a library of protocols. If you need Modbus, MQTT or a vendor protocol, you write the filter. That is a real cost, and it is the cost that most surprises people who read "support for multiple protocols" as a feature list rather than a transport list. The second boundary is the client side. SuperSocket.Client and SuperSocket.Client.Proxy exist, and the README calls out "proxy capabilities," but the framework's center of gravity is the server. If your work is mostly outbound connections to third-party services, you are using the smaller half of the project. The third is operational. The repository has no homepage beyond the docs site and no deployment tooling in the top-level listing beyond a .dockerignore, so containerization is your decision. There is also a legacy directory at the top level, which tells you the 1.x line still lives in the tree; the release notes and README.CN.md are worth checking before you assume a blog post about SuperSocket describes the version you are installing. Version drift between 1.x advice and the 2.x packages is the most likely source of wasted time here. ## SuperSocket Against Raw Sockets and Against ASP.NET Core The honest alternative for many readers is no framework at all. A TcpListener plus a byte buffer and a parser is perhaps a few hundred lines for a simple line protocol, and it has no dependency to upgrade. SuperSocket earns its place when you need the parts that are tedious to write correctly: session tracking across thousands of connections, graceful shutdown, command routing, and the buffer pooling the README mentions for memory efficiency. Write the raw version once and you will understand why the framework exists; write it twice and you will understand why people adopt it. The second alternative is ASP.NET Core itself. If your protocol is HTTP or WebSocket-over-HTTP, Kestrel already handles it, and SuperSocket.Kestrel exists precisely because the two worlds overlap. The difference in approach is that ASP.NET Core is request-oriented: a connection maps to a request and then usually ends. SuperSocket is session-oriented: the connection is the unit, and messages are events on it. Choose by which of those two shapes matches your traffic. ## Licence, Release Cadence and Upgrade Cost SuperSocket is Apache-2.0, which permits commercial use and modification, and the LICENSE file sits at the repository root. Apache-2.0 includes an explicit patent grant and requires that you preserve notices; if you redistribute a modified framework, that obligation follows you. This is a description of the licence text, not legal advice, and if you are shipping in a regulated environment your counsel should read it rather than this paragraph. The release history is short and legible: v2.0.1 on 2025-05-24, v2.0.2 on 2025-07-10, and v2.1.0 on 2026-04-04. The last push to master was on 2026-04-04, the same date as the v2.1.0 release. That is roughly a release every few months, and the jump from 2.0.2 to 2.1.0 rather than 2.0.3 signals that minor versions can carry behaviour changes. Pin the package version in your project file and read the releaseNotes directory before moving between them. The MyGet feed in the README's package table is where pre-release builds land, so it is useful for testing an upcoming change and a bad idea for production. ## Conclusion Adopt SuperSocket if you are writing a .NET server for a protocol you control or must implement, and you want session lifecycle, command dispatch and pipeline-based decoding handled for you rather than assembled from raw Socket code. Do not adopt it if your traffic is plain HTTP request/response, since ASP.NET Core already covers that, or if you need the framework to supply a wire protocol for you, because the README's protocol list is about transports and the decoding layer is yours to write. Before committing, verify the sample that matches your transport (ConsoleEchoServer, WebSocketServer or the CommandServer sample) builds against the current package set, and check whether the pipeline filter you need exists or has to be authored. The last push to master was on 2026-04-04, the same day v2.1.0 was released. ## FAQ ### What is SuperSocket? It is an Apache-2.0 socket server application framework for .NET, written in C#, with built-in support for TCP, UDP and WebSocket and a pipeline-based model for decoding custom protocols. ### How do I install SuperSocket in a .NET project? The README points to the NuGet packages rather than giving steps, listing SuperSocket.Server, SuperSocket.WebSocket.Server, SuperSocket.Udp and others in its package table. ### Does SuperSocket support WebSocket servers? Yes. The README lists full WebSocket protocol implementation with extensions such as compression, and there are SuperSocket.WebSocket and SuperSocket.WebSocket.Server packages plus WebSocketServer and WebSocketPushServer samples in the repository. ### How do I write a custom protocol decoder in SuperSocket? Protocol decoding goes in a pipeline filter, which the README describes as the customizable filter stage of the pipeline model. The samples/CustomProtocol and samples/SwitchPipelineFilter directories show how a filter is wired in. ### Is SuperSocket actively maintained? The repository is not archived, and the last push to master was on 2026-04-04, the same day v2.1.0 was released. The prior release, v2.0.2, was on 2025-07-10. ## Sources - [Issues](https://github.com/kerryjiang/SuperSocket/issues) - [kerryjiang/SuperSocket on GitHub](https://github.com/kerryjiang/SuperSocket) - [License: Apache-2.0](https://github.com/kerryjiang/SuperSocket/blob/master/LICENSE) - [README](https://github.com/kerryjiang/SuperSocket/blob/master/README.md) - [Releases](https://github.com/kerryjiang/SuperSocket/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/kerryjiang-supersocket