LiteNetLib: reliable UDP for .NET and Unity without the weight of a full game networking stack

What LiteNetLib actually replaces

Raw UDP gives you a socket and nothing else. Packets arrive out of order, duplicates appear, and anything larger than the path MTU is silently dropped or fragmented by the network in ways you cannot observe. LiteNetLib sits between your game logic and that socket. It keeps a connection state machine, tracks sequence numbers, retransmits what you mark as reliable, and hands you an event when a peer connects, disconnects or sends data.

The README describes the packet overhead plainly: 1 byte for unreliable packets and 4 bytes for reliable ones. That number matters when you are sending position updates at 30 Hz to a dozen peers. A library that wraps every datagram in a large header forces you to think about bandwidth before you have written any game code.

The intended audience is narrow and identifiable. The topics list names Unity, Godot, MonoGame and .NET, and the README's platform list covers Windows, Mac and Linux on .NET Framework, Mono, .NET Core and .NET Standard, plus Lumin OS, Unity desktop, Android, iOS and Switch. If you are shipping a C# multiplayer game on those targets, this is the layer you would otherwise write yourself.

Delivery methods, channels and the polling loop

The core abstraction is DeliveryMethod. The README lists five: reliable with order, reliable without order, reliable sequenced (only the last packet is kept), ordered but unreliable with duplication prevention, and plain UDP with no order or reliability. Picking one is a per-message decision, not a global setting, so a chat message and a position update travel through the same connection under different guarantees.

Channels are separate from delivery methods. Multiple data channels mean a large reliable file transfer does not block a small unreliable update, because head-of-line blocking applies within a channel rather than across the whole connection.

The API is poll-driven. Both the client and server samples end in a loop calling PollEvents() with a short sleep. There is no background receive thread imposed on you, which means the library does not decide your frame timing. It also means that if you forget to poll, nothing is processed. That is a real design constraint, not a footnote.

Around that core, the README lists automatic small packet merging, automatic fragmentation of reliable packets, automatic MTU detection, optional CRC32C checksums, UDP NAT hole punching, NTP time requests, connection statistics, multicasting for local host discovery, and packet loss and latency simulation. The simulation feature is the one worth calling out: it lets you reproduce bad network conditions without a proxy or a second machine.

Installing LiteNetLib and sending your first reliable packet

The README points to three distribution channels: the NuGet package, release builds on GitHub, and a DLL built from master on AppVeyor. It warns that the master branch can be unstable, so the release or NuGet route is the one to take unless you are deliberately testing unreleased changes.

For Unity, the README is explicit: use library sources or the OpenUPM package rather than precompiled DLL files, because there are platform-specific #ifdefs and workarounds for Unity bugs. It also states that the minimum supported Unity version is 2021.2, and that older versions should use the 1.x branch.

A minimal server starts a NetManager on a port, accepts connections by key, and polls. This is the README's own sample, trimmed to the connection path:

var listener = new EventBasedNetListener();
var server = new NetManager(listener);
server.Start(9050 /* port */);

listener.ConnectionRequestEvent += request =>
{
    if(server.ConnectedPeersCount < 10 /* max connections */)
        request.AcceptIfKey("SomeConnectionKey");
    else
        request.Reject();
};

while (!Console.KeyAvailable)
{
    server.PollEvents();
    Thread.Sleep(15);
}
server.Stop();

The port 9050 and the string "SomeConnectionKey" come from the README, not from a configuration file. The connection key is a shared secret of sorts: the client must pass the same value in Connect, or the request is not accepted. It is not encryption, and the README does not present it as one.

On the client side, the same pattern applies. You create a listener, a NetManager, call Start, then Connect with host, port and key. Incoming data arrives through NetworkReceiveEvent, and the sample calls dataReader.Recycle() after reading. That call is easy to overlook and the README shows it inside the handler, which suggests it is expected rather than optional cleanup.

Where LiteNetLib stops and you start

LiteNetLib does not serialize your objects by default. The README does list a fast packet serializer with a separate usage manual, and NetDataWriter and NetDataReader helper classes for reading and writing messages, but the mapping from your game state to bytes is your responsibility. There is no schema, no code generation step in the core path, and no compatibility guarantee if you change a field order between client versions.

There is also no matchmaking, lobby, relay or NAT traversal service. UDP NAT hole punching is listed as a capability, which means the library provides the mechanism, but you still need a way for two peers to learn each other's addresses. That is usually a rendezvous server you write and host.

The README does not document rollback, and it does not describe a built-in lag compensation or prediction system. If your game needs those, they are layers above this one. LiteEntitySystem is linked as the high-level API part, which is where that kind of work would live.

The polling model is the other boundary. A dedicated server loop that sleeps 15 ms between polls works, but any long operation inside an event handler stalls every peer on that NetManager. The library gives you the socket and the event queue; it does not give you a scheduler.

How LiteNetLib differs from a full engine transport

The closest comparison is a game engine's own networking layer. Unity's built-in transport and its newer alternatives bundle connection management with a service layer: relays, matchmaking, and in some cases a hosted backend. LiteNetLib is the opposite trade. You get the transport, the delivery methods and the peer bookkeeping, and you supply everything above it. The difference shows up in your deployment: with LiteNetLib you are running your own server process, and with a managed service you are not.

ENet is the other natural reference point for people arriving from C or C++. Both are reliable UDP libraries with channels and delivery modes, and the concepts map closely. The practical difference here is the ecosystem: LiteNetLib targets .NET Standard 2.1 and ships as a NuGet package with Unity and Godot integration notes, while ENet is a C library you bind to. The README also notes support for .NET 8 optimized socket calls with much less garbage collection, which is a runtime-specific advantage a C library cannot offer on the managed side.

Neither comparison is a verdict. If you want a hosted backend, LiteNetLib is the wrong shape. If you want a socket layer you control and can debug, it is the right one.

Maintenance, licensing and upgrade cost

The repository is not archived, and the last push was on 2026-09-22. The most recent release listed is 2.1.4 from 2026-05-19, preceded by 2.1.3 on 2026-04-18 and 2.1.2 on 2026-03-25. That is a steady release cadence through 2026 rather than a burst followed by silence.

The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are included. That is the standard reading of the text in LICENSE.txt; it is not legal advice, and if you are shipping in a regulated context you should have counsel look at your dependency list.

The upgrade cost is concentrated in two places. First, the 1.x branch is still maintained separately, and the README tells Unity users below 2021.2 to stay on it. That means a Unity upgrade can force a networking library migration. Second, the master branch is described as potentially unstable, so pinning to a release version rather than tracking master is the lower-risk path. The README does not document a rollback procedure, so treat version pinning as your rollback plan.

Editorial conclusion

Adopt LiteNetLib if you are building a multiplayer client or server in C# and want reliable UDP semantics without a full engine-level networking stack, especially on Unity 2021.2 or newer, Godot or MonoGame. Do not adopt it if you need matchmaking, lobbies, relay servers or a serialization format chosen for you; LiteNetLib gives you sockets and delivery methods, not a game backend. Before committing, verify that your target platform is covered by the supported list in the README, confirm whether you need the 1.x branch for Unity versions older than 2021.2, and check the NuGet package page for the version that matches your runtime.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. RevenantX/LiteNetLib on GitHub