[0.18.34] RCON issues: out of order responses, multipart trick unavailable.

Bugs that we were not able to reproduce, and/or are waiting for more detailed info.
Post Reply
franck
Burner Inserter
Burner Inserter
Posts: 8
Joined: Sun Jul 05, 2020 3:56 pm
Contact:

[0.18.34] RCON issues: out of order responses, multipart trick unavailable.

Post by franck »

Hello,

I have started working on a potential TAS and was looking at using RCON to control the game. The original idea was to try to use python-valve to do that, however I have run into an handful of issues.

In a document from valve describing the protocol, they describe the multipart behavior (which python-valve implements). In summary, the way I understand this is the following:

Client sends a EXECCOMMAND and a RESPONSE_VALUE to server. The EXECCOMMAND response may be many packets (call them EC1..ECN). RESPONSE_VALUE request from client is invalid, but server in this case is expected to return two responses to it. One empty and one (call it RV1) with 4 specific bytes of content (RV2). The packets are also expected to be in order they are received.

The reason this is done, is because then, we would get the following responses in order: EC1, EC2, ..., ECN, RV1, RV2

So in multiple EXECCOMMAND are executed, we would be able to tell their output apart using the (RV1, RV2) pair as markers.

Issues I have run into:
  • Factorio does not seem to implement the RESPONSE_VALUE at all, instead printing an error in its console and not responding at all. This is mentioned in other libraries found on google aimed at connecting to factorio's RCON.
  • It seems to me like the commands responses are not in order: I tried to use a trick to reproduce the expected behavior with python-valve: I send the command (which may be a slow-ish lua script), then '/silent-command rcon.print("TOKEN1")' and '/silent-command rcon.print("TOKEN2")'; I then translate TOKEN1 and TOKEN2 into the RV1 and RV2, however I receive the responses in the following order: ???, RV1, RV2, EC1...
Could this be reviewed, and if found correct fixed please? This would help setup reliable RCON connections :)

Cheers

mark9064
Burner Inserter
Burner Inserter
Posts: 8
Joined: Sun Feb 11, 2018 11:23 am
Contact:

Re: [0.18.34] RCON issues: out of order responses, multipart trick unavailable.

Post by mark9064 »

Factorio uses TCP for RCON rather than UDP, and therefore can take the luxury of ignoring the multipacket part of the protocol as a TCP connection is a continuous stream. So Factorio just returns a standard response with a larger body.

If you want to use RCON in python, I'll shamelessly plug my own library, https://github.com/mark9064/factorio-rcon-py, which implements all (but one) of the factorio quirks. The only current issue is this which can be worked around by using send/receive_packet.

However you end up implementing your solution, hopefully my library will be useful for your debugging :)

franck
Burner Inserter
Burner Inserter
Posts: 8
Joined: Sun Jul 05, 2020 3:56 pm
Contact:

Re: [0.18.34] RCON issues: out of order responses, multipart trick unavailable.

Post by franck »

Hey mark, noticed your library indeed! I read about the use of TCP however the outputs being in different order is still kind of messing with me, I need to check if it is coming from the python-valve lib or the game side. Maybe the python-valve lib does get confused by it using TCP. As for your own lib unfortunately I cannot use it because if its license (even though my own work will probably be open source soon), but I appreciate that you published your work as I'm sure some others will be able to leverage it!

Oxyd
Former Staff
Former Staff
Posts: 1428
Joined: Thu May 07, 2015 8:42 am
Contact:

Re: [0.18.34] RCON issues: out of order responses, multipart trick unavailable.

Post by Oxyd »

Indeed, TCP should handle large packets for us. (Why Valve would implement something like RCON over UDP is beyond me.)

I also don't understand why you're trying to use any marker commands. Each EXECCOMMAND contains an ID and the RESPONSE_VALUE then echoes this ID back to the client. This is what you should use to match replies to commands.

Post Reply

Return to “Pending”