A network library for client/server games written in C++
This is the stable release
This release updates to the latest netcode.io and reliable.io libraries.
This fixes several bugs and resolves a security vulnerability in relay protection.
You should update to this release!
New features in this release:
In order to implement the timeouts, this release updates to NETCODE 1.01 spec.
Yojimbo is now ready for production use.
New features:
This release incorporates all bugfixes since 0.4.0
This release adds doxygen documentation for yojimbo.
To build and view the documentation, install doxygen then run:
premake5 docs
It also fixes two critical security issues:
Please upgrade immediately or you risk an attacker being able to discover your private key.
This is a significant new release and contains major new features and bugfixes. I recommend everybody using libyojimbo update to this release right away. Please be aware that the API is slightly changed in this release.
New features:
The nature of these new features and bugfixes required changes to the API. Please refer to shared.h and client.cpp, connect.cpp and server.cpp for examples showing how to setup yojimbo client and server classes with the new API.
This release fixes an issue where client connect via matcher failed with this error on Windows:
error: request match failed. is the matcher running?
Which seemed to be caused by the matcher.go HTTPS response getting MTU split somewhere in the networking stack from a recent version of Docker on Windows, whereas in previous versions of Docker on Windows it was not.
The fix was to extend the mbedtls example code I derived from in yojimbo_matcher.cpp so it properly handles responses that require multiple calls to mbedtls_ssl_read. This bug seem did not affect MacOS or Linux platforms, but if for some reason the HTTPS response was MTU split, it would have broken there too.
I also added a workaround on MacOS for the clock getting out of sync in the docker VM instance, which was causing client connects through matcher.go running in docker to fail to connect when pointed to a server instance outside of docker:
For example, the following sequence of commands worked:
premake5 matcher
premake5 docker // run server on port 40000 inside docker
premake5 connect
Because both matcher and server were running inside docker with the same skewed clock, but the following sequence failed:
premake5 matcher
premake5 server // run server on port 40000 *outside* docker
premake5 connect
because matcher.go generated connect tokens wrt. skewed time, which were then passed to a server running outside of docker (with correct, unskewed time), causing the server to deny these connection requests because they were stale (connect tokens are only valid for a short 30 second window...). I'm not 100% sure, but I suspect these issues are new with the latest MacOS Sierra release. I recently upgraded, and didn't notice any clock skew before this.
The solution in production environments is of course to always make sure your matcher and dedicated server instances are synced to the same time via NTP. For development on MacOS, I added the following workaround to sync up the docker VM clock to local time:
docker run --rm --privileged alpine hwclock -s
Which is described here:
https://docs.docker.com/docker-for-mac/troubleshoot/#issues
Docker... sigh :)
This release adds per-client silos for allocators, packet factories and message factories on the server. This is a security measure so a malicious client can exhaust only their own resources (leading to disconnection) and cannot affect resources for other clients. Previously, allocators and factories were shared by all clients on the server. This release also includes a bunch of fixes to get libyojimbo passing Coverity with zero defects. See this page for details.