Skip to content

Reliable message preview 9

Pre-release
Pre-release
Compare
Choose a tag to compare
@gafferongames gafferongames released this 21 Oct 15:40
v0.3.0-preview9
87262e3

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 :)

Assets 5
Loading