Monday, September 16, 2024 8:01:10 AM
> settings

Customize


Authenticate

> posts
ESM devlog: The connection server rewrite
Published on
Written by Bryan

I Have Done It... I Have Finally Done It

The connection workflow between the bot and the Arma 3 servers has been released. It took three months of my free time to complete, which isn’t bad for me given that the version I had from a year ago took about double that. Whereas it was a good first step, but I wasn't satisfied with it. Here’s what bothered me:

  • It required running a separate Rust process to act as a middleman between the bot and the TCP connection from the Arma 3 (A3) server.
  • The message protocol was too strict in the wrong ways, relied on callbacks, and was difficult to test.
  • The communication between the Ruby process (running the bot) and the Rust process (running the TCP server) was overly complex and caused weird bugs.

Using what I learned from writing redis_ipc, I created a Ruby-based TCP server to replace the Rust one, simplifying a significant portion of the communication lifecycle. Instead of using an asynchronous callback-based system, I moved to a system that appears synchronous from the implementation perspective but functions asynchronously internally. The usefulness of this simple change became clear when I ported the server_territories command and realized that I no longer needed to use the #on_response callback. Check out the V1 vs V2 implementations.

While implementing the new workflows, I also switched to using Hash/HashMap to store key/value pairs in the data and metadata fields of ESM::Message and its Rust counterpart. This change removes some guarantees provided by Rust's structs, but the flexibility it offers saves me from using my previously implemented attribute macro, which was intended to reduce the amount of Rust boilerplate code required to function with arma-rs and serde.

The last major change I made was to reworked the encryption process to occur as early as possible, ensuring no unencrypted data is sent to the client. Additionally, I added gzip compression and base64 encoding to keep the data small and prevent data loss. I will create a separate post detailing the networking lifecycle at a later point.

What’s Next?

My next focus will be on migrating the remaining SQF command functions to the new mod and improving them as needed. I’m also working on enhancing the reliability and usability of XM8 notifications and have some treats in store for the reward command. More on those when I get there :)

All opinions represented herein are my own
- © 2024 itsthedevman
- build 3c15a1b