Code Structure

The code is written in order to be as readable as possible with no side effects and no global objects/variables.

We (try to) follow a functional programming paradigm where all the methods take immutable inputs and returns new outputs; this has great benefits:

  • Given the highly parallel nature of Wolf, we can easily share immutable data structures to multiple threads without having to deal with race conditions.

    • This gives us the power to support multiple concurrent users effortlessly.

  • Code can easily be re-used by other projects since every part is highly decoupled.

  • Enables testing most of the implemented methods in isolation.

We are also trying to isolate the Moonlight protocol from the actual implementation so that we can create a portable C++ library of stateless methods, where possible, the code has been separated in logical modules.

Modules

src/core

High-level utilities and re-usable libraries, not strictly tied to Moonlight or Wolf:

  • docker.hpp: using libcurl and boost json to interrogate the Docker socket and provide an easy to use interface to most methods.

  • input.hpp: an easy to use virtual input device library; supports mouse, keyboard, joypads and more!

  • virtual-display.hpp: a simple abstraction on top of games-on-whales/gst-wayland-display in order to create and control virtual desktops.

  • audio.hpp: a simple abstraction on top of libpulse to create and control virtual audio devices.

src/fake-udev

A little standalone CLI tool that enables us to generate udev events. You can read more about the rationale behind it in Hotplug in Docker.

src/moonlight-protocol

Here we define core Moonlight functions in order to create the foundation for a platform-agnostic portable library. It currently hosts the followings:

src/moonlight-server

This is where the final Wolf executable will be built, contains all the additional code and logic required to run the full Moonlight server.
In order to keep modules decoupled most of the logic revolves around reacting to events in a shared event bus (implemented using DeveloperPaul123/eventbus).

tests

Unit tests will live under tests/ and are written using the Catch2 framework.
We are implementing unit tests for most of the methods and (where possible) also mocking packets/requests seen during real Moonlight sessions.

Some of them are platform/HW specific; they are all enabled by default, you should disable them based on your platform. Checkout the options in the tests/CMakeLists.txt