A protocol for secure client/server connections over UDP

Overview

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.

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.

    opened by vvanders 89
  • 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

    opened by toqueteos 21
  • 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.

    opened by benaadams 20
  • 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.

    opened by SProst 17
  • 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?

    opened by mreinstein 15
  • 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?

    opened by MattFoley 15
  • 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.

    opened by ghost 14
  • 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

    opened by SirLynix 14
  • 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,

    opened by dougajmcdonald 14
  • 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?

    opened by RandyGaul 11
  • 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
    opened by StefDevs 8
  • 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.

    opened by code-disaster 1
Releases(v1.2.1)
  • v1.2.1(Apr 17, 2019)

    This release includes a security fix for a vulnerability discovered in replay attack protection.

    Without this fix, an attacker can craft a packet with high sequence number to a client or server, and stop all future packets in the connection from being received.

    Please update to this release ASAP!

    Source code(tar.gz)
    Source code(zip)
  • v1.1(Aug 16, 2017)

    Changes in this release:

    1. Per-client timeouts can now be specified in the connect token
    2. Negative timeout values disable timeout (useful for debugging)
    3. Negative expire seconds disables token expiry (useful for debugging)
    4. Added netcode_client_get_port and netcode_server_get_port to get the bound socket ports when the bind address has port 0.
    5. Golang and Rust implementations have been moved out to their own repositories so they can have different release cycles.
    6. To implement per-client timeouts the code has been updated to NETCODE 1.01 spec.
    Source code(tar.gz)
    Source code(zip)
  • v1.0(Jul 24, 2017)

    This is the initial release of netcode.io

    Features:

    1. Secure client connection based around connect tokens
    2. Challenge/response for protection against spoofed client IP headers
    3. Protection against being used in DDoS packet amplification attacks in request/response
    4. Encrypted and signed UDP packets once connection is established.
    5. Replay protection so attackers can't intercept and replay old packets.
    6. Support for user overrides for allocator, logging functions and assert function.
    7. Support for loopback client connections with server, for example for local client/server or singleplayer in Call of Duty, Titanfall style.

    This code has been extensively unit tested, soak tested as well as having been successfully integrated into yojimbo for several months now.

    netcode.io is now production ready!

    Source code(tar.gz)
    Source code(zip)
Owner
The Network Protocol Company
The Network Protocol Company
The Network Protocol Company
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

Ivan Shynkarenka 931 Nov 19, 2022
(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 позволяет серверу и четырём клиентам запуститься одновременно. В

Alexander Batischev 2 Dec 18, 2021
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

Dmitry Golgovsky 7 Dec 21, 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

Jinoh Kang 5 Nov 3, 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

Dyne.org 15 Nov 1, 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 / Embedded Networking Library Mongoose is a networking library for C/C++. It implements event-driven non-blocking APIs

Cesanta Software 8.9k Nov 21, 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.

null 1 Jun 22, 2022
Ole Christian Eidheim 741 Nov 2, 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

QuestDB 25 Nov 18, 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

Devsisters Corp. 1.7k Nov 14, 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

Valve Software 6.3k Nov 29, 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.

null 53 Nov 20, 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

null 65 Aug 29, 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

ExpressVPN 22 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.

ExpressVPN 376 Nov 28, 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

Jonathan Bastien-Filiatrault 3 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

null 33 Nov 6, 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

Benjamin Reigner 1 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

null 48 Oct 13, 2022