Rcon responses should work how terry described. If you do find different
behavior please send me a report of what happened (and the IP of the
server that did it) so I can investigate.  

> -----Original Message-----
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Terry
> Sent: Sunday, February 01, 2004 11:11 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [hlds_apps] HLDS RCON fragmented UDP
> 
> Oops.  I didn't read your initial message correctly.  Are you 
> saying it
> doesn't split the datagrams properly in response to an rcon 
> command?  I just
> tried it with a Firearms server and it worked ok for me, i.e. 
> it split the
> packet.
> 
> I do seem to remember that Rcon was inconsistent at times, but I don't
> remember the exact problems I had.  If you search through the 
> archives for
> this mailing list, I'm sure you'll find more information on it.
> 
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Terry
> Sent: Sunday, February 01, 2004 12:16 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [hlds_apps] HLDS RCON fragmented UDP
> 
> 
> Yep - there certainly is.
> 
>               //
>               //   packet number in seq ___   ____ total 
> number of packets
>               //                           | |
>               // -pkt split-  -32 bit id-  | | - normal pkt start -
>               // FE FF FF FF  07 02 00 00  0 2  FF FF FF FF 6C <data>
> 
>               // FE FF FF FF  07 02 00 00  1 2  <data>
> 
> If the data returned doesn't fit into a single datagram, the 
> server will
> split the data, indicated by the first four bytes being "FE FF FF FF"
> instead of "FF FF FF FF".  The next four bytes are some kind 
> of ID (correct
> me if I'm wrong on that Alfred) which I use in my code to identify the
> packets that need to be reassembled.  The next 4 bits is the 
> part number
> (zero based) and the following 4 bits is the total number of 
> bytes in the
> sequence.  So, in the example above, the first line is the 
> first part of 2,
> and the second line is the second part of 2.
> 
> Once you've reassambled the data, it looks just like any 
> other HL packet.
> 
> Good luck.
> 
> Terry
> 
> Author of the not so excellent ServerInfo  ;-)
> 
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Kris
> Sent: Sunday, February 01, 2004 11:33 AM
> To: [EMAIL PROTECTED]
> Subject: [hlds_apps] HLDS RCON fragmented UDP
> 
> 
> Is there any way to detect that a hlds rcon udp packet reply 
> is fragmented
> or not?
> 
> Doing an 'rcon status' on large servers returns two packets, 
> the first one
> 16 bytes and the second one 1400 bytes, and the full reply is 
> created by
> putting the first packet on the end of the second one. Can it 
> not be changed
> so that fragmented rcon replies work in the same way as fragmented
> rules-query replies (where there is a different header)?
> 
> Cheers,
> Kris.
> 
> Author of the excellent K-query. : www.kquery.com
>      ___
>     /__/|
>    |  |:|
>    |  |:|
>  __|  |:|
> /__/\_|:|____
> \  \:\/:::::/
>  \  \::/~~~~
>   \  \:\
>    \  \:\
>     \__\/
> 
> 
> _______________________________________________
> hlds_apps mailing list
> [EMAIL PROTECTED]
> http://list.valvesoftware.com/mailman/listinfo/hlds_apps
> 
> 
> _______________________________________________
> hlds_apps mailing list
> [EMAIL PROTECTED]
> http://list.valvesoftware.com/mailman/listinfo/hlds_apps
> 

_______________________________________________
hlds_apps mailing list
[EMAIL PROTECTED]
http://list.valvesoftware.com/mailman/listinfo/hlds_apps

Reply via email to