New/Better Interface for Server Admins



  • Reading all those threads concerning the current Rcon system, I was wondering whether a new and improved system should be developed.
    With the SDK, it’s possible to create a more advanced Rcon system or a totally new system.

    I was thinking about an IRC plugin-like mod that puts a bot in a channel and let channel operators use admin commands, aswell as report server status to the channel.
    Through a DCC server implemented within UDK, admins connected to IRC would also be able to login-in, chat with admins in-game aswell as other admins logged to DCC, view more sensitive information or information that is too long to be displayed in a channel (player list request for example), etc.

    Here are some pros and cons for both IRC and Advanced Rcon.

    IRC:

    Pros:

    • Simple and universal protocol with only small changes between implementations.

    • Lots of client softwares already developed.

    • Lots of documentation.

    • Only a single socket object is used by UDK (not considering DCC).

    • You don’t have to worry about connecting to your server, the bot is the server’s responsibility.

    • Easy to implement new commands.

    • Better communication between players and admins.

    • A normal user can see what’s going on in a server and interact without needing to be an admin.

    • Easier to manage your own admins.

    • Able to manage your server anywhere (even from a phone) via browser webchats.

    Cons:

    • Depends on a middleman (IRC server).

    • Bot can stay disconnected for hours/days if the bot’s IP is banned or the IRC network is down.

    • Excess flood may keep disconnecting your bot. To prevent this, messages (DCC is immune as it’s a direct connection between server and client) needs to delayed everytime the bot needs to send several messages at the same time. If you run your own network, you can make your bot an IRCOp and thus it becomes immune to excess flood disconnections.

    • Data cannot be compressed.

    • Lack of security. Data cannot be hashed nor encrypted.

    • Bandwidth consumption is higher as every message must be formatted before sending.

    • Several servers running on the same IP address may have trouble connecting to public networks as they only allow a certain number of connections from the same IP.

    Advanced Rcon:

    Pros:

    • No dependencies on servers that you have no control over.

    • Compression, hashing and encryption can be performed on both ends.

    • Advanced clients can be developed with only Rcon in mind. Allowing for better and more intuitive interfaces.

    • Data can be assembled with as few bytes as possible. The responsibility for human readable data would fall into the client’s software.

    • Privacy. Data doesn’t pass through a middleman server.

    Cons:

    • Multiple socket objects.

    • Larger overhead and bandwidth consumption when multiple users are connected to it.

    • Need for development of new client software.

    • Normal users can’t have any information in what’s going on.

    • Normal users can’t interact with the server.

    • Not able to manage your server from different platforms and/or locations.

    • Lack of a conventional protocol. Makes development of clients with support for others/new implementations difficult.

    • Rcon port can be exploited with DoS and possible bruteforce attacks.

    This is not a full Pros/Cons list. Just what I could think of right now.

    In any case, I’m putting this here instead of the Mods section because I want to hear your opinions.
    I’ll not begin development until the SDK is released to Live, if we ever get to that point.

    Feel free to post your opinion and/or any suggestions.
    You can also post suggestions for new commands, so once I actually start developing it, I’ll have a nice set of features for the first release.



  • No interest at all?

    I don’t have a server myself, so it doesn’t actually fall into my needs.
    I just thought it was an area that needed some work, and that’s something that can be done entirely through coding.

    Oh well, with no demand for it there is no real reason to put effort into this.



  • @Cthulhu:

    Oh well, with no demand for it there is no real reason to put effort into this.

    They are not putting effort into the things that do have demand.



  • @gregcau:

    @Cthulhu:

    Oh well, with no demand for it there is no real reason to put effort into this.

    They are not putting effort into the things that do have demand.

    What?
    I’m not talking about TBS. This is a project that I would be developing myself.



  • @Cthulhu:

    What?
    I’m not talking about TBS. This is a project that I would be developing myself.

    oh I see. build an awesome TO map instead :-)



  • @gregcau:

    oh I see. build an awesome TO map instead :-)

    I don’t map. Besides, I’ve little to no interest in creating visual stuff.

    Unfortunately it seems that modding for Chivalry isn’t going anywhere.
    The few users that still bother to read these forums don’t bother to read the modding section, unless you are developing a new map.
    Feedback is non-existent.

    I’ll probably start modding for another game. My time on Chivalry has decreased to almost 0 anyway.



  • @Cthulhu:

    My time on Chivalry has decreased to almost 0 anyway.

    TBS made the choice to abandon it in favor of a new standalone so I understand.



  • Advanced RCON implementation is the way to go. IRC control’s Pros are mostly moot. If you look implementations suchs as phogues RCON tool for BF games, it’s damn near perfect, including daemon layers so that you can have it running on a single master and all of your admins connect to that.

    There are already well founded anti ddos for rcon handling from the likes of metamod/source and the con of some info not being publically available is moot one for me: the public don’t need to see everything going on in a server unless they’re playing there (in which case they already see everything they need).

    A package that tracks stats on a remote server is best parsed to something like a web frontend (like B3/Echelon/xlrstats) because if you’re trying to present info to the public a web frontend is much better than IRC (which tbf many people don’t even know of these day)

    tldr: A good RCON implementation is the way forward



  • @MonkeyFiend:

    Advanced RCON implementation is the way to go. IRC control’s Pros are mostly moot. If you look implementations suchs as phogues RCON tool for BF games, it’s damn near perfect, including daemon layers so that you can have it running on a single master and all of your admins connect to that.

    It doesn’t matter how high level your interface is, you still end up with mutiple objects for multiple connections when dealing with TCP.
    It happens because IPv4 is connectionless and TCP implements a pseudo connection into it.
    Packets will still be connectionless, but TCP handles them differently with a 3-way handshake (SYN, SYN-ACK, ACK).
    Even if you go low-level enough at network or driver level, you will still need to create individual states for establishing a pseudo connection with another end.
    That’s how I would be implementing it either for IRC DCC or Advanced Rcon, a single socket object for listening, and spawning a new instance for each new connection.

    As to avoid data replication through a master server, well, I suggested it to the creator of this tool viewtopic.php?f=72&t=19421
    He didn’t like the idea of a single server storing all server passwords by itself.
    And even if you were the one to run the master server, that would bring one more dependency to your end, that of running a master server.

    @MonkeyFiend:

    There are already well founded anti ddos for rcon handling from the likes of metamod/source and the con of some info not being publically available is moot one for me: the public don’t need to see everything going on in a server unless they’re playing there (in which case they already see everything they need).

    Well, I don’t have direct access to the engine nor its low-level socket operations. I can’t perform low-level bad packet dropping.
    Once you start receiving a massive DDoS attack from dynamic IPs, even firewalls will have a hard time blocking them.
    And considering the fact that UDK is single-threaded, a well placed DDoS attack can very well consume all its CPU time.

    As for the info being available to the public, there are a couple of examples that it can be useful.
    A player might want to see the activity of a server before deciding to join it. How mature the players in there are, etc.
    Events. Public is invited but not everyone can put up with streaming.
    Besides, only public information would go into the channel chat (general chat, who killed who, players who joined/left the server, etc).
    You can also make the channel invite only, passworded, or run your own private network. All these would prevent the public from even seeing your public information.

    @MonkeyFiend:

    A package that tracks stats on a remote server is best parsed to something like a web frontend (like B3/Echelon/xlrstats) because if you’re trying to present info to the public a web frontend is much better than IRC (which tbf many people don’t even know of these day)

    Again the problem with dependencies on the client.
    For it to work, you need to have a web front.

    @MonkeyFiend:

    tldr: A good RCON implementation is the way forward

    The real pro of IRC is to have no extra dependencies for the client to run it. Anyone can download an IRC client or use an IRC Webchat.
    All you need is a Chivalry server and you’ve all that interface already granted.

    The real con of Advanced Rcon is the need to develop new clients for it. And when someone does a slightly modification to the code, the client needs to have its code modified aswell.
    It’s a nightmare to maintain, as it would be dealing with a non-standard protocol.


Log in to reply