A protocol for secure client/server connections over UDP

Build status

netcode

netcode is a simple connection based client/server protocol built on top of UDP.

It has the following features:

  • Encrypted and signed packets
  • Secure client connection with connect tokens
  • Connection based protocol built on top of UDP

and protects your game server from the following attacks:

  • Zombie clients
  • Man in the middle
  • DDoS amplification
  • Packet replay attacks

netcode is stable and production ready.

How does it work?

Please refer to the second half of this whitepaper: Why can't I send UDP packets from a browser?

For a complete technical specification, read the netcode 1.02 standard.

Source Code

This repository holds the reference implementation of netcode in C.

This is the primary implementation of netcode, and is always up to date with the latest features.

Other netcode.io repositories include:

Contributors

These people are awesome:

Thanks for your contributions to netcode!

Author

The author of this library is Glenn Fiedler.

Other open source libraries by the same author include: yojimbo and reliable

Glenn is now the founder and CEO of Network Next. Network Next is a radically new way to link networks together. A new internet where networks compete on performance and price to carry your traffic. Check it out at https://networknext.com

Sponsors

netcode was generously sponsored by:

And by individual supporters on Patreon. Thank you. You made this possible!

License

BSD 3-Clause license.

Owner
The Network Protocol Company
The Network Protocol Company
The Network Protocol Company
Comments
  • Rust implementation

    Rust implementation

    I've started on a wrapper of netcode for Rust located at https://github.com/vvanders/netcode-rust (until we can figure out best way to merge).

    Right now only client functions are hooked up and nothing is tested but it's a bit of a start. Currently it bootstraps netcode via "gcc" crate which shells out to msvc pretty cleanly on windows. Still need to sort out linux.

    I'll update this issue once I've got something more stable, this is mostly a placeholder to discuss ongoing integration and related items.

  • Go server implementation usage

    Go server implementation usage

    I'm doing some tests with netcode, specifically with Go's server implementation and I'm struggling a little bit.

    The C implementation exposes a very nice API to send/receive packets to a single client.

    The Go implementation only exposes Server.SendPayloads (source) which sends something to all connected clients. Am I missing something?

    /cc @wirepair

  • Have Client<->Server agree cipher rather than hardcoded

    Have Client<->Server agree cipher rather than hardcoded

    As per https (TLS) have the client and server agree what cipher suite to use rather than hardcode it as ChaCha20/Poly1305

    This will allow platform encryption libraries to be used (e.g. native Win/macOS, and chosen Linux); which will be updated with the natural flow of OS security patches - rather than having a game lib dependency which relies on the developer to release patched versions. (though could still use libsodium if preferred)

    Also allows for new ciphers and old ciphers to be depreciated; or prioritized by OS security updates rather than requiring game updates.

  • Native C# Implementation

    Native C# Implementation

    Native implementation of netcode.io in C#. Question, what language specification can we target? I think there are enough language features to warrant supporting C#7 at this point. Were you planning on supporting netcore, netstandard, or the full dotnetframework (or target against all of them). NET core 1.1, Net Standard 1.5 (eventually 2?) and NET 462.

  • usage guide?

    usage guide?

    All of the documentation referenced in the readme are geared torwards protocol implementors and people looking for details on how it works internally.

    Are there any documentation/guides on how to use the netcode.io interface?

  • Both IPv6 and IPv4 IP addresses in a single connect token?

    Both IPv6 and IPv4 IP addresses in a single connect token?

    After working through some mobile networking trouble, we found that some cell providers work better with IPv6 while some work better with IPv4.

    In testing, we found that IPv6 connect tokens only work properly when the Yojimbo client is initialized with an IPv6 address to bind to.

    // Will not work with an IPv6 address as the only server address in the connect token.
    Client* client = new Client(GetDefaultAllocator(), Address("0.0.0.0"), config, adapter, time);
    vs:
    // Works with an IPv6 address in the connect token.
    Client* client = new Client(GetDefaultAllocator(), Address("0:0:0:0:0:0:0:0"), config, adapter, time);
    

    We then tracked this down to netcode_socket_create in netcode.c, the address the client binds to must match the protocol (IPv4 vs IPv6) of the address container in the connect token. While the address that's used for sendto is being handled as IPv6 correctly, it fails if the socket wasn't created for an IPv6 client.

    At the moment, we're unsure whether this is a bug, or by design. Should netcode/yojimbo be able to handle connect tokens with both IPv4 and IPv6? Is it possible we're doing something wrong here? Is this a bug with one of these two libraries?

    If this isn't a supported feature, would you have any suggestions for this? If it is, and seems to be working as expected, is it possible we're not binding the client address correctly?

  • Settings #define's

    Settings #define's

    Hi, Glenn I'm a little confused in the macros, there are too many of them and they all have similar names. I have a few questions, hope you can give me a detailed answer.

    1. If the game client cannot send a packet of more than 6000 bytes in length, then what #define should I change? Me need change #define NETCODE_MAX_PACKET_SIZE in .c and .h file netcode? My game client use 2 byte for proto ID and 5998 for data, example packet: [00 65][00 00 00 00] where [00 65] - it's proto id, [00 00 00 00] - data

    Why is #define NETCODE_SERVER_MAX_RECEIVE_PACKETS 64 * NETCODE_MAX_CLIENTS? It's mean, 1 client can't send more 64 byte or how much packets he can accept?

    It's correct? NETCODE_MAX_PACKET_BYTES = NETCODE_MAX_PAYLOAD_BYTES + 100 ?

    My head is torn from the fact that macros are not commented out Can you tell that each of these macros is doing, as well as how are the two of them interconnected?

    Honestly, it would be easier if I contacted you directly so that you could help me set up netcode according to my project.

    I hope you have a couple of minutes for me.

  • How to deal with matcher restart/multiple matchers?

    How to deal with matcher restart/multiple matchers?

    Hi there,

    I've been reading your netcode spec and I got some questions about the matchers: they're using a nonce (incremented for every token generated) and a private key (known by the game server). As far as I know, a nonce and a key should be used together only once to prevent security breaches.

    So what about matchers restart (after a system/application crash)? Is it a big deal its nonce restarts at 0 (which means it already have been used)? Should the key be regenerated?

    How about multiple matchers (for load balancing/failover/etc)? Should each matcher gets its own private key? How does the game server should handle this?

    Thank you

  • JavaScript or C# impl / wrapper

    JavaScript or C# impl / wrapper

    This project looks really interesting. Me and a colleague are interested in something which can send and receive UDP in the browser from either a JS or C# backend for game development.

    I will have a look over the code and concepts to see if we can make use / fork this and add our work to help the project,

  • Connect Token Sniffing

    Connect Token Sniffing

    Say a valid, but malicious, client records their own list of valid dedicated server IP addresses. They then want to DoS another player, or steal another player's session. They sniff the other player's packets and get access to the opaque connect token. They then make an attempt to connect to a dedicated server by using their own personal IP address collection, and send the token to each server to try and connect before the sniffed client.

    This causes two problems:

    1. The sniffed player can have their identity stolen, as another player has connected with their token before they do.
    2. The sniffed player might have to retrieve a new token and try to connect to other servers. In the case where no other servers are available, they are in a DoS scenario.

    What is the idea for netcode regarding this strategy?

  • Clarification about first condition in replay protection implementation

    Clarification about first condition in replay protection implementation

    From the implementation:

    int netcode_replay_protection_packet_already_received( struct netcode_replay_protection_t * replay_protection, uint64_t sequence )
    {
        netcode_assert( replay_protection );
    
        if ( sequence & ( 1ULL << 63 ) )
            return 0;
        ...
    }
    

    Could someone explain what this first if statement is doing? It looks to me like if the least significant (?) bit of the sequence number is non-zero we say the packet has not been received already. Why would this be desired?

    I'm probably misunderstanding something here but it's also not mentioned in the standard as far as I can tell.

    Thanks

    • Stef
  • Assert on NULL user_data in netcode_generate_connect_token()

    Assert on NULL user_data in netcode_generate_connect_token()

    Just a minor issue I ran into: netcode_generate_connect_token() and netcode_generate_connect_token_private() assert on user_data, but the latter checks for a null pointer, so the asserts can possibly be removed.

Ultra fast and low latency asynchronous socket server & client C++ library with support TCP, SSL, UDP, HTTP, HTTPS, WebSocket protocols and 10K connections problem solution
Ultra fast and low latency asynchronous socket server & client C++ library with support TCP, SSL, UDP, HTTP, HTTPS, WebSocket protocols and 10K connections problem solution

CppServer Ultra fast and low latency asynchronous socket server & client C++ library with support TCP, SSL, UDP, HTTP, HTTPS, WebSocket protocols and

Aug 8, 2022
Wrapper for linux TCP/UDP/unix/USB socket connections

Socket Connection wrapper shared library Shared library that realize sockets connections and could transfer data-packages. Navigation Navigation Insta

Dec 21, 2021
(Test assignment) Transfer files over the network using a homegrown UDP protocol

Требования Linux x86_64 gcc >= 4.9 (C++11) Сборка $ make Запуск $ make run -j5 -j5 позволяет серверу и четырём клиентам запуститься одновременно. В

Dec 18, 2021
Windows named pipe server that forwards connections to given TCP server

PipeTcp An asynchronous Windows named pipe server that forwards connections to given TCP server. Pre-built binaries can be found in Releases. Invocati

May 23, 2022
Dohd is a minimalist DNS-over-HTTPS daemon that redirects all DoH queries to a local DNS server running on localhost:53 (UDP)

dohd Dohd (pron. doh-dee) is a minimalist DNS-over-HTTPS daemon that redirects all DoH queries to a local DNS server running on localhost:53 (UDP). Fe

Jun 26, 2022
Mongoose Embedded Web Server Library - a multi-protocol embedded networking library with TCP/UDP, HTTP, WebSocket, MQTT built-in protocols, async DNS resolver, and non-blocking API.
Mongoose Embedded Web Server Library - a multi-protocol embedded networking library with TCP/UDP, HTTP, WebSocket,  MQTT built-in protocols, async DNS resolver, and non-blocking API.

Mongoose - Embedded Web Server / Embedded Networking Library Mongoose is a networking library for C/C++. It implements event-driven non-blocking APIs

Aug 8, 2022
Built a client-server application using TCP and UDP sockets, in which the clients can subscribe/unsubscribe to various topics.

Built a client-server application using TCP and UDP sockets, in which the clients can subscribe/unsubscribe to various topics.

Jun 22, 2022
Aug 16, 2022
C and C++ client for QuestDB Input Line Protocol over TCP

c-questdb-client QuestDB - InfluxDB Line Protocol - Ingestion Client Library for C and C++ This library makes it easy to insert data into QuestDB. Thi

Aug 9, 2022
QUIC, a multiplexed stream transport over UDP

QUIC, a multiplexed stream transport over UDP QUIC is an experimental protocol aimed at reducing web latency over that of TCP. On the surface, QUIC is

Aug 7, 2022
Reliable & unreliable messages over UDP. Robust message fragmentation & reassembly. P2P networking / NAT traversal. Encryption.

GameNetworkingSockets GameNetworkingSockets is a basic transport layer for games. The features are: Connection-oriented API (like TCP) ... but message

Aug 15, 2022
Winpcap-based network packet capture tool, support TLS (part), UDP, ICMP, TCP, ARP, DNS and other protocol analysis, interface reference wireshark.
Winpcap-based network packet capture tool, support TLS (part), UDP, ICMP, TCP, ARP, DNS and other protocol analysis, interface reference wireshark.

Winpcap-based network packet capture tool, support TLS (part), UDP, ICMP, TCP, ARP, DNS and other protocol analysis, interface reference wireshark.

Aug 5, 2022
Portable, single-file, protocol-agnostic TCP and UDP socket wrapper, primarily for game networking

Documentation This is a header-only library, as such most of its functional documentation is contained within the "header section" of the source code

Jul 25, 2022
Lightway Core is a modern VPN protocol by ExpressVPN, to deliver a VPN experience that’s faster, more secure, and more reliable.

Lightway Core NOTE: This is a preview snapshot of the Lightway repository used for both our client and server. We will be publishing a live, actively

Feb 17, 2022
Lightway Core is a modern VPN protocol by ExpressVPN, to deliver a VPN experience that’s faster, more secure, and more reliable.

Lightway Core is a modern VPN protocol by ExpressVPN, to deliver a VPN experience that’s faster, more secure, and more reliable.

Aug 6, 2022
GnuTLS implements the TLS/SSL (Transport Layer Security aka Secure Sockets Layer) protocol

GnuTLS implements the TLS/SSL (Transport Layer Security aka Secure Sockets Layer) protocol

Jun 3, 2021
Realtime Client/Server app for Linux allowing joystick (and other HID) data to be transferred over a local network

netstick What is it? Netstick enables HID devices to be remotely connected between a "client" and "server" over a network connection. It allows the ke

Jul 24, 2022
The project consists in a client/server architecture voice over IP application, similar to Skype or TeamSpeak.

Babel The project consists in a client/server architecture voice over IP application, similar to Skype or TeamSpeak. Build and Run the Project First y

Jan 17, 2022
LAppS - Lua Application Server for micro-services with default communication over WebSockets. The fastest and most vertically scalable WebSockets server implementation ever. Low latency C++ <-> Lua stack roundtrip.

LAppS - Lua Application Server This is an attempt to provide very easy to use Lua Application Server working over WebSockets protocol (RFC 6455). LApp

Apr 25, 2022