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.

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

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

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?

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?

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.

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

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,

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?

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

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.