Quilkin is a non-transparent UDP proxy specifically designed for use with large scale multiplayer dedicated game servers deployments, to ensure security, access control, telemetry data, metrics and more.
It is designed to be used behind game clients as well as in front of dedicated game servers.
What is Quilkin?
Quilkin on open source is a non-transparent UDP proxy specifically designed for use with large scale multiplayer dedicated game servers deployments, to ensure security, access control, telemetry data, metrics and more.
It is designed to be used behind game clients as well as in front of dedicated game servers.
Quilkin's aim is to pull the above functionality out of bespoke, monolithic dedicated game servers and clients, and provide standard, composable modules that can be reused across a wide set of multiplayer games, so that game developers can instead focus on their game specific aspects of building a multiplayer game.
Why use Quilkin?
Some of Quilkin's advantages:
1. Lower development and operational costs for securing, monitoring and making reliable multiplayer game servers and their communications.
2. Provide entry-point redundancy for your game clients to connect to - making it much harder to take down your game servers.
Multiple integration patterns, allowing you to choose the level of integration that makes sense for your architecture.
3. Remove non-game specific computation out of your game server's processing loop - and save that precious CPU for your game simulation!
Major Features
Quilkin incorporates these abilities:
1. Non-transparent proxying of UDP data, the internal state of your game architecture is not visible to bad actors.
2. Out of the box metrics for UDP packet information.
3. Composable tools for access control and security.
4. Able to be utilised as a standalone binary, with no client/server changes required or as a Rust library depending on how deep an integration you wish for your system.
5. Can be integrated with C/C++ code bases via FFI.
How to use Quilkin?
There are two choices for running Quilkin:
1. Binary
2. Container image
For each version there is both a release version, which is optimised for production usage, and a debug version that has debug level logging enabled.
Usage of Binary
The release binary can be downloaded from the Github releases page.
Quilkin needs to be run with an accompanying configuration file, like so:
quilkin --filename="configuration.yaml"
If you require debug output, you can run the same command can be run with the quilkin-debug binary.
You can also use the shorthand of -f instead of --filename if you so desire.
Usage of Docker Container Registry
For each release, there are both a release and debug container image built and hosted on Google Cloud Artifact Registry listed for each release.
The production release can be found under the tag:
us-docker.pkg.dev/quilkin/release/quilkin:{version}
Whereas, if you need debugging logging, use the following tag:
us-docker.pkg.dev/quilkin/release/quilkin:{version}-debug
Mount your configuration file at /etc/quilkin/quilkin.yaml to configure the Quilkin instance inside the container.
A default configuration is provided, such the container will start without a new configuration file, but it is configured to point to 127.0.0.1:0 as a no-op configuration.
Sources
Github repo for the quilkin Sources!