java-Kcp ports the KCP reliable UDP protocol to Netty and adds forward error correction

KCP trades bandwidth for lower tail latency, which is the whole point

The protocol choice is what everything else follows from, and the documentation states the trade explicitly. KCP is a fast reliable protocol based on UDP, a reliable UDP, and it exchanges an extra 10% to 20% of bandwidth compared with TCP for an average latency reduced by 30% to 40% and a maximum latency reduced by a factor of three. That third number is the one that matters for interactive traffic. Average latency is what a throughput graph shows you, and a transfer can have a good average while its worst moment is bad. For a game where the player acts on what they see, the worst moment is the moment that decides whether the game feels fair. The java-Kcp project is the Netty-based version of this protocol, and it adds an FEC implementation on top, with the project description naming games, video and acceleration as the intended business uses. The repository is Apache-2.0 licensed and is structured as a Maven multi-module project.

The artifact you depend on is kcp-base, and it comes from Maven Central

Getting the library onto your classpath is a single dependency declaration, and the coordinates are specific:

<dependency>
  <groupId>com.github.l42111996</groupId>
  <artifactId>kcp-base</artifactId>
  <version>1.6.2</version>
</dependency>

The group id is the GitHub-style namespace, the artifact is `kcp-base`, and the version documented is 1.6.2, which is worth noting because the only tagged release in the repository history is 1.0 from 2019-09-19, so the artifact version and the git tag do not track each other. The repository root shows the module layout: `kcp-base/` holds the library itself, `kcp-example/` holds the runnable server and client samples, `kcp-fec/` is the forward error correction module, and `kcp-lockStepSynchronization/` is a separate module for lockstep synchronisation, which is a distinct technique for keeping multiplayer clients in step rather than a transport feature. There is also a `pom.xml` at the root, an `AGENTS.md`, and three documents worth reading before you commit: `QA.md` collects the problems the author encountered, `Benchmark.md` holds the project's own performance test results, and `RELEASE.md` sits alongside them.

The examples cover RTT measurement, C# interop and a Go client

The documentation points you at concrete example files rather than at a tutorial, and the set of them tells you what the library is expected to be used for. There is a server example and a client example in `kcp-example/src/main/java/test/`, named `KcpRttExampleServer.java` and `KcpRttExampleClient.java`, which are the round trip time examples, so the first thing the library is measured on is latency rather than throughput. There is a server example for the C# side, `Kcp4sharpExampleServer.java`, paired with a C# client in a separate repository, and the documentation describes the C# implementation as fully compatible and aimed at quickly building a game front end and back end network library. There is also a client example for the Go implementation, `Kcp4GoExampleClient.java`, described as compatible with kcp-go including FEC compatibility, and the compatibility list states that it is compatible with the original C version of KCP. So the interoperability story is the deliberate design constraint: a Java server that has to talk to a Unity client in C# and a Go backend is a normal deployment shape, not an edge case.

FEC is a separate module built on Backblaze's Reed-Solomon library

The forward error correction layer is not a reimplementation, and the documentation says so. The FEC implementation is based on the JavaReedSolomon project from Backblaze, and the repository holds it in its own `kcp-fec/` module. The reason FEC belongs in a low latency transport is arithmetic rather than magic. With plain KCP, a lost packet has to be detected and then repaired, and the repair is a round trip to the sender. With FEC, the receiver can reconstruct the missing packet from parity data it already holds, so the loss costs nothing in time. The trade is bandwidth, because parity blocks have to be sent, and the documentation lists including FEC as one of the optimisations precisely because it lowers latency. The Go client example is described as FEC compatible as well, so the parity scheme has to line up across implementations, which is a real constraint if you mix languages. The related projects list also points at the Backblaze JavaReedSolomon repository directly, and at the C version of KCP and kcp-go as the reference implementations.

The optimisations are aimed at many connections and no GC pauses

The optimisation list in the documentation is where the engineering detail sits, and most of it is about running many connections rather than moving a lot of bytes. The implementation is event driven, which is what lets it use multiple cores, and the fastack logic has been optimised to reduce traffic by 10%. There is a time wheel in use, optimised to lower CPU usage when there are many connections, and direct buffers plus object pooling are used to avoid GC pressure, which is the standard Netty answer to allocation churn in a long-lived server. A CRC32 checksum is bundled in, and the check function and the collection iterators have also been worked on. Two entries are specifically about mobile and NAT behaviour, and they are the ones a game developer will care about most. One adds the ability to determine channel uniqueness by conversation id or by ip plus port, with a recommendation to use the conversation id and configure TCP accordingly, and another adds the property that a change of outbound IP, such as switching between 4G and wifi during use, does not drop the connection. The second one is a real problem for mobile clients that a plain UDP socket cannot solve.

Reading QA.md and Benchmark.md before you trust a number

Two documents in the repository root are more useful than the feature list, and the documentation links to both. `QA.md` is the collection of problems the author ran into, and it is linked under the heading of problems encountered. That is the honest place to look for a library like this, because the failure modes of a custom reliable UDP stack are exactly the things that do not show up in a benchmark. `Benchmark.md` holds the project's own performance test results, and it is linked under the heading of performance test results. The documentation also points at the KCP best practices page in the original C project, which is the closest thing to a tuning guide, and at the original KCP repository itself under a heading that points to a lot of background reading. For a protocol that has been ported across at least four languages, the original author's wiki is where the accumulated operational knowledge sits, and the Java project's own documentation leans on it rather than duplicating it. There is also a separate issue list file, `QA.md`, and a QQ contact address given for questions, which tells you how support actually happens for this project.

Where KCP is the wrong transport

The failure cases follow from the design rather than from bugs. The first is that KCP is not TCP. It gives you reliable, ordered delivery, but it does not give you TCP's congestion control story, and the protocol was written for a network where packets are lost rather than filtered. On a network that throttles or drops UDP deliberately, such as some corporate or carrier networks, a reliable UDP stack can end up worse than TCP, because TCP backs off and KCP does not. The second is bandwidth. The documented trade is 10% to 20% more bandwidth, which is cheap on a fixed broadband line and expensive on a metered mobile connection carrying video. The third is the operational surface. This is a library you embed in your own Netty pipeline, with your own channel lifecycle, your own timeouts and your own reconnection logic, and the documentation's own example set is round trip time measurement rather than a framework that handles those things for you. The alternative to weigh against is TCP with Nagle's algorithm disabled, which is the standard way to reduce latency without changing transport, at the cost of head-of-line blocking. The difference in approach is that TCP gives you a stream and you deal with framing, while KCP gives you message boundaries and you deal with the reliability trade-offs. If your workload is a request-response API on a well-behaved network, TCP is the smaller decision. If it is a game or a live stream with a real loss rate, this library is the one that was built for it.

Editorial conclusion

java-Kcp is worth adopting when you are writing a Java game or streaming service on Netty and need a transport that trades a little bandwidth for much lower tail latency, since the implementation is battle-tested enough to be described in the project documentation as a stable version with several shipped products using it, and the FEC layer lets you recover losses without a round trip. It is a poor fit if you need TCP semantics, ordered delivery with retransmission and no surprises, because KCP is deliberately a different transport contract, and a poor fit if you are deploying across a network that throttles or reshapes UDP, since the whole design assumes UDP delivery is fast and lossy rather than filtered. Before adopting it, read QA.md, which collects the problems the author actually hit, and Benchmark.md for the project's own performance measurements, and note that the last push to the repository was on 2026-08-12 with the only tagged release being 1.0 from 2019-09-19.

Frequently asked questions

Official sources

1. Issues
2. l42111996/java-Kcp on GitHub
3. License: Apache-2.0
4. README
5. Releases