Anyhow, Alfred (the legend) made some changes last night, and I'm just waiting on a linux build before I find out how large responses are now dealt with. I'll post the findings here, my development website (http://dev.kquery.com), and my dev/coding forums ( http://www.kquery.com/forums/index.php?act=SF&f=7 )
Kris.
At 01:53 02/02/2004, you wrote:
Ah yes! I remember this now. I tried to deal with the same thing with the
rcon status returns. I don't know how the server is packaging the data up
in response to rcon commands, but it's very consistant with the responses to
the public server query.
I dug through the archives - exactly two years ago yesterday I brought this
up. What I ended up doing was inspecting the packets in the status response
and trying to assemble them in order. It didn't work very well. I
Here's what I had found in the archives.
BEGIN ARCHIVE POST ================================================
-----Original Message-----
From: Jeroen "ShadowLord" Bogers [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 31, 2002 3:14 PM
To: [EMAIL PROTECTED]
Subject: Re: [hlds_apps] Ressurecting the Rcon issue
>From what I have seen from 'split' rcon replies you just have to guess.
Basicly, the last packet has a newline.
You just have to hope all of the packets in front all arrive and in correct
order.
Maybe, for the next release, Valve could add packet IDs (one byte for the
current packet number and one for the total ammount of packets in this
reply). Would make rcon a lot easier and much more reliable.
Jeroen "ShadowLord" Bogers
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
http://www.solrain.com <http://www.solrain.com>
----- Original Message -----
From: Terry <mailto:[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
Sent: Thursday, January 31, 2002 22:24
Subject: [hlds_apps] Ressurecting the Rcon issue
A while back someone asked if there was any way to intelligently reconstruct
the information that comes back in an rcon response when it gets split into
multiple packets.
This was never resolved and I'm having to deal with it again.
For example, when issuing rcon commands that generate enough output to
require that the information be split into more than one packet, it's
difficult to tell how to order the packets if they come in out of order.
For example, the response to a 'cvarlist' command will be split into about 7
or 8 packets, some of them start with
FE FF FF FF 54 02 00 00 02 FF FF FF FF 6C
others start with
FF FF FF FF 6C
Often times the packets will be out of order. It seems to me that the bytes
"54 02 00 00 02" somehow contain the information to put them back into their
proper order.
Could someone please shed some light on this?
Thanks,
Terry
END ARCHIVE POST ================================================
