HRMR (Hot reloadable module router)

HRMR is a utility to allow you to make a fully modular server using modules that can be reloaded at runtime.

You can make a module with many functions and set your function to handle a TCP request to it if the first bits of it match.

For example a static HTTP server module is included to get you started and if a request starts with "GET" the entire thing will be shipped to the module bound to it.

The included HTTP server module will serve static files from /static_html It is not safe or secure or complete.
It is just an example of the module system

Modules can be hot reloaded at runtime and the code will be updated, and new modules should get loaded as well.
If a module is being reloaded it will give an HTTP 503 message to whatever client is attempting to use it.

Module functions can also be run on a thread pool to not block the main thread eg with file IO

This software is not designed to be exposed to the web and built in commands can be run by anything connected to it.
This software is designed to be part of your internal system for many apps to talk to this server and for this server to talk to other things to get a response for your other services.

Example being if you need multiple discord bot instances to have the same interface to many different kinds of database or to be able to have them share a SQLite based database.
This would be useful to lessen the burden on database queries and processing from NodeJS to a more performant implementation in C++

Modules are loaded as if they were compiled in so if they cause a runtime error they may take down the entire server.
Be careful with the modules you make

Built-in commands

• RELOAD Reloads all modules (Won't complete until)
• CLOSE Closes the current connection
• SHUTDOWN Shuts down the server

Configuration

You can pass in the following CLI arguments -port {X} The server will use port X (Default: 8080) -threads {X} The server will spawn X threads for the worker pool (Default: 4)

Building

You should be able to use make with the included makefile, and it will build the server and every .cpp file in /module_src is treated as a seperate module and compile to a .so file inside /modules

Making Modules

Making modules is quite simple. Take a look at /module_src/http.cpp which has comments for custom module specifics
They should be compiled to a .so file and be made in C++ but other languages may work but support will not be given.
Module .so files should be in /modules

Known Wont-Fix Issues

The server will segfault if you delete a module RELOAD and then put it back and RELOAD
This should not hurt normal operations of the server and adding new modules at runtime still works and deleting and replacing the moduke and then reloading still works. If this hurts your usage of the software feel free to make a PR.

When running under valgrind the server can drop requests due to running VERY slow. Running an HTTP stress test without valgrind shows no issues however.

Licensing

This project is under licensed under the LGPLv3 for all code except for code in /src/deps or in /shared_src

Code inside /src/shared_src are under the MIT licence as in /src/shared_src/SHARED_SRC_LICENCE.txt to allow for making modules closed source without as many licensing burdens

Code inside /deps are not part of this project and are external dependencies and are under their own licenses

• /deps/concurrentqueue.h Simplified BSD license | (SRC)
• /deps/blockingconcurrentqueue.h Simplified BSD license | (SRC)
• /deps/lightweightsemaphore.h zlib Licence | (SRC)
• /deps/spinlock.h CC0 1.0 | (Made by me. No external link to source)

Why LGPL

The LGPL licence is used becase changes to the core could should be shared publicly but your own modules are your own code to keep private if you wish.