For those who are updating the original src, I’ve been brushing up on my c# to help out with this project.
The main concern I have for this tool is this:
It’s a local tool, can’t be used for multiple admins connecting and sending commands simultaneously. That’s due to the fact that the tool itself is sending the direct UDP commands to the server through the RCON listen port. This can be fixed though, if we create a “listener” tool that sits on a different host, probably the same one the server is on to limit UDP traffic and lag. This listening application (probably a console application) can utilize SQLserver compact or express to store data locally/offsite and can hold admin log-in credentials.
Then we can release an Admin client separately. This application can connect to the listener and queue commands. It would take a little more work, especially to tag commands with the connected credential’s names, but it would provide easy 24/7 rcon support for servers.
A note to the devs:
! Another thing, if the Dev’s are reading this… If you could also implement a “wake up” UDP/TCP message from the RCON port that can maintain an RCON connection yet keep the chatter to a minimum, we can also develop low-fi tools that don’t send all kill/connection/chat messages every second. Say, after a certain time of not receiving commands from a RCON connection, send a default outwards packet with a “wake up” message to check it’s still connected– but stop all other outwards RCON messages in the meantime to save bandwidth and lag. This is a problem really frequent in small maps with a fast rate of kills and deaths, where the server bottlenecks kill/death messages through the RCON port and starts lagging.
! That way… a user can join the server and log in using the ‘adminlogin’ command and re-open the message flow-- this non-sleeping state should also be triggerable by the rcon tool sending the message to wake up.
! Ideally the best rcon setup would be:
! [Server]<>[RconTool Listener]<–/internet/–>[LocalRconUser]
! And the connection between the listener and the server would be defaulted to a low-fi RCON message status until a command is given. This setting should be able to be turned off for those who have more advanced hardware/ network bandwidth for their servers who don’t mind a constant flood of information.