Module facio::client

High-Level RCON client

Client

Using the RawPacket as its underlying data model and a common TcpStream from the standard library, this part of the library implements a RCON client.

As of now (which means: before async/await is stable), this client is synchronous only. It is a future project to extend this to an async client, whenever the feature hits stable.

Example

use facio::{raw_packet::*, client::*};

fn main() -> std::io::Result<()> {
   // open the rcon connection where `mypass` is the password and
   // echoing `echo` is used as the safe/check command (see below).
   // The last `None` denotes that the connection attempt has no timeout.
   let mut rcon =
       RconClient::open("127.0.0.1:38742",
                        "mypass",
                        Some("echo"),
                        None).expect("Cannot open rcon");

   // now execute the command `/help`.
   if let Some(s) = rcon.exec("/help").ok() {
       println!("/help from server:\n{}", s);
   } else {
       println!("Error?");
   }
 
} // connection is closed here.

Safe/Check Command

Since the protocol allows multi-packet response but does not provide any solution to detect those, finding any response as beginning, part and end of a multi-packet response is a bit tricky.

The wiki on the protocol gives an idea (see here) but to a full extend this is based on a specific implementation detail of the server. My experience with RCON server-side implementations has shown that this is mostly not working. Anyways, the basic idea seems to work throughout: an RCON server processes the requests it got in the order they arrived. Also, the packet id of a request is used as the id of the response to this very request. Insofar, to check if a response packet marks the end of a response, with every sent request, there is right behind another request sent of which it is sure that the server responses with exactly one packet.

This second request packet (the safe or check packet) is sent with a different id then the actual request. By checking the response packet id it can be determined whether the received packet is a response for the check request and therefore the packet before marks an end to the original response, or it is still part of the response.

• send request packet (with normal id)
• send check packet (with check id)
• receive packet while id is not check id
• when packet with check id is received, everything is received from the original request, where all packets with normal id belong to the original response.

Authentication

Authentication can become tricky as well, since some servers do not comply the protocol in every detail. The protocol defines that following a SERVERDATA_AUTH packet, i.e. a auth request, the server sends back an empty SERVERDATA_RESPONSE_VALUE packet, followed by a SERVERDATA_AUTH_RESPONSE packet. Some servers do implement this in this way. Some just send a SERVERDATA_AUTH_RESPONSE back. Authentication as provided by the open function supports both by checking the type of the received packet.

Using packet ids

To solve the multi-packet response problem, packet ids are used in a certain way. This occupies the packet ids; they are not longer visible from the outside of the higher-level abstraction around exec.

As a lower-level entry point which does not manage multi-packet responses but allows for an own implementation, there is the ll module.

Structs

RconClient

The basic type to connect to a RCON server and execute commands.