rcon

rcon copied to clipboard

It can't return full information

from rcon.source import Client
cmd = "ListPlayers"
with Client('ip', port, passwd='passwd') as client:
        response = client.run(cmd)
        print(response)

Only when I use asynchronous environment, it also can't return full infomation and will return "Unexpected terminator: b'Na'" at the beginning of the message

I found this in https://developer.valvesoftware.com/wiki/Source_RCON_Protocol#Multiple-packet_Responses

Multiple-packet Responses
Most responses are small enough to fit within the maximum possible packet size of 4096 bytes. However, a few commands such as cvarlist and, occasionally, status produce responses too long to be sent in one response packet. When this happens, the server will split the response into multiple SERVERDATA_RESPONSE_VALUE packets. Unfortunately, it can be difficult to accurately determine from the first packet alone whether the response has been split.

One common workaround is for the client to send an empty SERVERDATA_RESPONSE_VALUE packet after every SERVERDATA_EXECCOMMAND request. Rather than throwing out the erroneous request, SRCDS mirrors it back to the client, followed by another RESPONSE_VALUE packet containing 0x0000 0001 0000 0000 in the packet body field. Because SRCDS always responds to requests in the order it receives them, receiving a response packet with an empty packet body guarantees that all of the meaningful response packets have already been received. Then, the response bodies can simply be concatenated to build the full response.

Hi. Thanks for the report. Unfortunately I did not yet find the time to look into this. I may implement this over the upcoming Easter weekend.

Sorry again. Over the past weekend I was not able to work on this, since I had to do some work because of that xz kerfuffle. Since I am very busy over the next two weeks I will not be able to do any work on this library during this time. If you want to implement this by yourself, I'd be happy to merge an appropriate pull request.

I just had briefly time to look into this. I'm currently using a response size-based approach to detect packet fragmentation. Please try lowering the frag_threshold parameter when crating your Client (it currently defaults to 4096).