Support always-listening / always-monitoring (remote mc server)

[javabrett]

Currently mcPortKnock implements a:

• monitor (real mc server is running, detect idle and run stopCommand) ->
• listen/be-fake-mc-server (port knock listener and run startCommand on client join-server knock) ->
• monitor etc.

... loop. This is ideal when mcPortKnock runs on the same server as Minecraft and would typically listen on the same TCP port, so both mcPortKnock and Minecraft can't listen simultaneously.

mcPortKnock can actually work quite well already in a different scenario, where it runs on a different server to the Minecraft server it monitors. In this case, mcPortKnock can run on a tiny server with startCommand and stopCommand controlling a remote mc server running on bigger hardware, which can then be completely shutdown when idle, since it isn't hosting mcPortKnock.

In this scenario, an enhancement would be for mcPortKnock to always-listen e.g. 25565/tcp, since it won't ever have to yield that port for a local real mc server. Additionally, it can always-monitor, allowing it to stopCommand the mc server when it is idle, even when it is in "listen" mode, where currently I don't expect it would be monitoring mc or expect it to be running.

If implemented, this enhancement could improve tiny/off-mc-host mcPortKnock to improve responsiveness and avoid any out-of-sync states where mc is not shutdown when idle.

Networking for above usage: there are a number of great ways to incorporate mcPortKnock as a port-knock with mc-direct when running - I've used DNS with health-checks and failover rules, but other DNS and load-balancing options also work.

Thanks for the nifty utility and project.

[daniel-widrick]

This is an interesting suggestion. It's certainly a use case that is interesting. I'd be reluctant to use dns as the failover personal due to delays. A proper load balancer could likely handle the transition.. but ultimately that would likely be out of scope and up to the users to handle.

An "always listen" option would be trivial to add...

[javabrett]

I'd be reluctant to use dns as the failover personal due to delays. A proper load balancer could likely handle the transition

Agreed, absolutely a LB will be better and more reliable than the DNS failover, although the healthcheck/rules-based one in AWS Route 53 is working pretty well. If cost is the main factor and you are trying to scale to almost zero, the DNS zone plus a tiny portknock instance is a fair bit cheaper than an always-running LB.

[daniel-widrick]

So, I definitely see the values in the ideas proposed and the use case. My concern is as follows: How much can we add before the project stops being a fairly trivial tool and grows into a full management suite?

I suppose a persistent listen option could be added and a larger management suite could reference this specific tool to handle the Minecraft masquerading...