eliasr / mcdaemon Goto Github PK

Nothing like trolling guests emphasizes the need for a logging system.

The logging system will collect data such as IP and interaction. At a later stage it will be used with the login system to identify users and act as a warning system for login attempts.

Finally MCDaemon should be able to block incoming connections from potential and identified hostile IP's.

The main purpose of restarting MCDaemon is to reload the configuration from the config file after it has been altered.
There is a general method to provide a restart without closing the program, but it would cause active servers to be closed. (lets assume people don't necessarily want that).

There are multiple ways to go about it, and the best would be that the configuration would be reloaded when changes are applied. It is, however, not the primary task with MCDaemon and as soon as it is properly configured a user might rarely need it.

Currently this is at a low priority, but sooner is better as less refactoring will be necessary.

The request strikes me a bit odd, but not entirely bad nor completely impossible to perform.

I want to see the in-game time from the minecraft server on the webclient, so i know if it is safe to join the server.

• a friend

So the problem my friend experiences is that it is very dangerous to join the server during night time, especially if there are certain circumstances that increases the danger, ex: bloodmoon (caused by a mod)

My first though was that it wouldn't make sense to implement as it wouldn't fit with a service in general. Ex: a half-life server doesn't provide that type of info, a printer service would neither, etc.
However if every service can be seen as a module, then a module or a profile can be made for each service.

That in turn leads to the need for a module that one can customize entirely by sub modules.
Like the upload feature that would be essential for a printing service, could also be used to update a modpack on a minecraft server - now considering the upload feature to be a submodule and services to be the program we execute in this module, it is possible to refactor the code to allow this, but it adds a level of complexity both for the development and for the admin.

Each submodule would not only be a feature, ex read x data, or upload x files; there is also the question of what to do or how to do it.
For instance the data that requires reading might need to use a certain command to do so. Depending on the service this would have to be set appropriately and hard coding it would limit the use of the feature. So already here we see that the admin would have to apply further configuration to make the sub modules work.

For the uploader there is the question of what to do, should it unpack the file to a certain place, should it call the service with the file as an argument, what should it do if something goes wrong (ex unable to unpack due to service being active) This information too, would have to be set by an administrator, a person who isn't necessary a tech savvy.

So that in turn leads to defining a set of, what to do and how to do events that can take a small set of arguments, probably in a sequence too.

Okay, so we could make a sequence and fill them with these events and let them be part of a submodule that we can add to our module. In the abstract sense of coding it, it shoudn't be too hard. But my experience tells me that it will take a lot of time to get right and the user interface has to remain simple and intuitive.
It would be so simple to just add a config button to the module that opens a new windows that can show yet a list of module and argument lines - well heck if you are into linux you would probably be fine with just editing the xml in hand. However, that approach might be confusing for the common guy/kid who just wants to add a gaming server and post how many players there is online or something else.
So this leads to yet a layer of interaction that has to be well considered, but on the cost of time and complexity that means setting it up requires a lot of tearing down if it needs correcting.

Right now i consider the login "module" more important, but i can also see it as a prototype for this kind of implementation.
What do you think?

Due to how a Minecraft server is shut down, a stop command is sent to the server and a few seconds is given to allow it to gently shut down, but no more than 5 second otherwise it is forced to stop.
While this implementation isn't perfect it does suffice for most cases.

It should however be extended to support different stop commanded and timing.

But for now a smaller adjustment is to be made with regards to the response time on the web client.
As a user stops or switches a server, the user is first getting a reply from the host after the completion of the server termination, this results in a delay of 5 seconds or more and provides an insufficient experience (according to feedback) - The server will instead show an intermission status as soon as it is handing the request and the user will experience a better response time from the host. The status will then change again when the host is done shutting down the service.

This is a minor enhancement that later will be part of an realtime solution though server-sent-events.

Platform: Windows xp SP1 (but runs .net 4.0)
Processor: Intel(R) Celeron(R) CPU N2820 @ 2.13GHz (2 CPUs), ~2.1GHz

Apparently MCDaemon drains about 50% CPU constantly. That was never the intention.
A comparison in a much faster PC shows that it is consistent.
Optimization of the software is given high priority (otherwise, what is the point?)

To avoid invalid file path, using a dialogue to select a file would both be convenient and reduce errors.

MCDaemon is currently only for Windows.
It would be cool if it also could work on Linux.

My experience in converting windows projects to linux is rather vague, so if you could fork the project to make a solution or provide some hints then it would be very helpfull.

• Extend the config to hold multiple taps and categorise the taps accordingly
• Resize the server entities in the server list to be as wide as the list itself
• Relocate Add server button to make it more intuitive and less ugly
• Add "web client" quick access link in the context menu

By implementing SSE the need for refreshing the web client/site will disappear and the actions performed on the site will instantly be shared with every use - hence reducing the risk of invalid session key and generally providing a more smooth experience.

The input text will no longer be removed due to the page refresh.
The output iframe will work properly as the onload event no longer is in a race against the loaded status on the site.
Less data is needed to be sent and therefore improves performance.

Long term feature

Some of the uploaded images in the source are by RoundIcon, however it was incorrect of me to upload it in the current state as flaticons doesn't allow for redistribution of their files.

Likewise the licenses for the program should be packed with the binary files.

This issue will be resolved as the first thing.

MCDaemon is open and free and will remain so.
This feature is set by the admin and doesn't affect the user of the webclient.

A dynamic library in closed source will be provided to collect limited statistics, check for updates and allow for verification of the MCDaemon to be an original version by encrypted communication.
The individual services provided by the dll can be disabled by the admin and MCDaemon can still be used without the dll file, however the dll file is necessary to provide those services.

The point of making it closed source is to provide security and allow for verification. Since MCDaemon is open source it would be easy to bypass the dll file and fake its verification, however, with a lookup service from a trusted webpage(mine) that knows how to communicate with the DLL file, it would be possible to verify the version - no backdoors used.

The second purpose is to collect some statistics without transferring them in clear text, if the admin wants to share the statistics.
The statistics I intend to collect is unique visitors, button usage (start, stop, input), host usage.
The point of these statistics is to see how MCDaemon is used and whether the host chooses to interact with the interface itself. It will provide an idea about what area would benefit the most from enhancing certain elements and if certain module (future development) is in use.

The only personal data that is required is an IP address, which is used to distinguish visitors from each other and the host itself. A private policy will be written and needs to be accepted upon installation / first run - I consider the project to be under Danish jurisdiction and as such the laws regarding protection of personal data means that your IP address won't be shared with third party, otherwise it would be a crime.
I also consider the individual host to be able to see the statistical results of visitors and unique visitors without compromising the ipadress.

This is considered a long term development that is developed on the sideline of MCDaemon and implements the features as they become available.