I play a lot of game with my friends, and due to my technical expertise I also provide hosting for some games. As interests from one game changes to a different game, there has always been a need for me to change the server manually.
Two years ago I acquired an Intel NUC due to a need for an x86 server that could provide services 24/7 without burning though my electricity bills, currently it runs a webserver for filesharing/JenkinsCI deployment, acts as a NAS with its connected 3TB disk and can dualboot into a Linux partition for testing the server setup with BZSmod.
But most of all it still run gaming servers when there is a request for it, this year Minecraft have been quite popular among my friends and with the many modpacks one server just haven't sufficed.
However 4GB ram and Intel Atom doesn't allow for two MC servers at once, so it is necessary to switch between as needed.
My friends and I have many times debated the option of making a system that could allow them to make these switches without the need of my assistance. As PHP exec() didn't work out for enabling our master plan, it has been postponed ever since.
Being available for hire has provided me with enough time to work on a solution that both requires back-end and front-end development and I estimate to have used about 60 to 100 hours work time so far (across a month, not including learning time of languages and technicalities).
It has resulted in a stable solution we originally named MineCraftDaemon, but now would be more fitting to name MyCustomDaemon.
The server provides a webclient that allows for switching between servers, reading the output from the active server and provides the ability to send an input command to the active server. This is handled by a socket connection and manually interpreting HTTP GET and POST requests.
Behind the scene is a random key generator that ensures the POST request to be from a valid state and checks on the POST variable to be within its limits. The POST request is processed inside a mutex to ensure only one request is processed at a time and no queueing of requests can occur. Finally the request is split into variables that are used for shutting down or starting a cmd process with the appropriate arguments.
The GET request returns the string representing the output text if /output was included otherwise it returns the control page. Both are in HTML format.
The good thing about using cmd.exe to call the process we need to start, is that it scales well and allows for a bat file to do all the needed things that might be related to the setup of the server.
The bad thing is that unless "exit" is provided in the end of the bat script and the program, (ex: minecraft) can end it self by a text command (stop or quit), then the web application allows full usage of the cmd.exe, which could lead to abuse or accidents.
Currently the project is stable and could be lunched with a warning that every server should be wrapped inside a bat file with an exit command in the end, and it might be necessary as long as cmd.exe is used for executing the programs.
An alternative way would be to implement that wrapper into the code and hope that it won't cause any limitations.
While this might work well for the explicit task it provides it does not scale very well.
- What if one wants to provide a printer service though the interface, should the interface allow for a login and session or should the printer service?
- How do we handle the upload of files?
- How do we avoid abuse?
- What if we want to run 2 servers, but not 3?
- How can we provide hidden services for users with privileges
eg: could we provide the cmd.exe for the server admin when logged into his/her account, but not to be shown for anyone else. How would that conflict with the server count rule?
MCDaemon will be released as open source on github when the security has been improved and a GUI for manipulating the config file is in place, but resolving the scalability issue could make MCDaemon much more usefull.
Another feature I intend to implement is the usage of Server Sent Events to get rid of the refresh cycle and thereby making the feedback from the service become more smooth. Server Sent Events would also allow for a user to have time to write a longer input command for a service without using copy/paste.
MCDaemon will be added to my project page when available for download.