Changelog #1 - HearthSim/Firestarter GitHub Wiki

28/07/2018

Stats:

  • It has been 3 days since the first commit on master;
  • At the time of writing, the latest commit is 7851d2b.

This post will outline what has been implemented so far. At the end you'll find some ideas about functionality that will be implemented soon.

Log

The Firestarter library implementation started with the creation of a crate dubbed firestarter. Located at firestarter/ it (will) contain all code necessary to communicate with HS client build 6898 (v1.3). So far code and documentation is written to make it work asap.
There is a "protocol" module for BNet packet encoding/decoding, session types and hard-coded logic to handle a client handshake.
The "rpc" and "service" modules mostly contain skeleton code at the moment. These modules will hold a definition of an RPC system as well as RPC services for both the BNet and Pegasus protocol abiding to that definition.
The "server" module contains a lobby server configuration. This server accepts incoming client connections and forces them to complete the handshake procedure. Any client causing an error or timeout will be dropped.

The firestarter-generated crate is used as a container for auto-generated code (during compilation). Currently it holds the compiled proto schemas which are exposed through the 'firestarter_generated::proto' namespace.
The protobuffer schema files themselves are located at firestarter_generated/proto_schemas/ and were extracted from both the client's .NET-dlls and BNet native-dll.

Up next

The most pressing task to complete is the design of the RPC system. The system will be formulated as a set of types (like Request and Response) and traits (like CreatesService and Invokable) to force correct behaviour. Using this system as guidance will certainly speed up implementation of new services.
The exact behaviour this system must enforce is still being worked at;

  • it should allow for accepting external protocol-specific requests;
  • it should allow for internal request routing;
  • the service itself must have an exposed functionality to absolutely verify that a request/response is legal for that service.

Please help, thinking about this on my own is tough..

(Related) Using tower as dependancy is out of the question because of its unstable frontend but understanding if/why it's valuable will make our implementation probably easier. We could adapt their traits into something relevant to Firestarter.

Another task is building out a binary entry point for our library (firestarter/src/bin/vanilla_server.rs). This entry point will initialise the library and allow clients to connect. Having this implemented is important because it shows that the library actually works. It's a sanity check, next to the tests of course.

This is an easy task and provides a nice introduction to the project. If you're interested in doing the implementation I can provide you with examples and guidance via our discord server.

Looking ahead even further there is implementing the bnet client session, request/response routing, implementing database connections, processing environment variables. Still a lot to do!

Bert


Come talk to us! You're free to open issues, create pull requests and chat about the project.