Don't we all
Fernando Manso wrote:
Ok, thanks. I hope valve implements another way.
On Mon, 8 Nov 2004 10:03:04 -0600 (CST), [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
Well as Shannon said one of the only ways to really determine it is to set
a short timeout on the socket so that when you're reading data from it and
it times out after the last packet (and thus you'll have no data) you know
it will be the end.
I don't believe using that method is the proper way to do it. But there's
no other alternative at this moment, unless valve builds something into
the protocol that would allow us to see the end.
--
Jason Morriss
http://www.psychostats.com/
On Mon, 8 Nov 2004, Fernando Manso wrote:
Date: Mon, 8 Nov 2004 12:05:15 +0100
From: Fernando Manso <[EMAIL PROTECTED] >
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [hlds_apps] Source RCON format
Excuse me again, but I dont finish to understand how to know the
finish of the transimission. Please, May someone explain it detailed ?
Thanks a lot.
On Sat, 6 Nov 2004 22:39:31 -0600 (CST), [EMAIL PROTECTED]
<[EMAIL PROTECTED] > wrote:
It would make sense if the HL2 protocol just reported the total bytes to
expect (all packets in the response combined) within the first packet so
the remote end would know exactly when to stop reading packets, or add
some sort of 'end of response' header flag.
I don't want to rely on using a short timeout as that may cause problems
later. Owell. Thanks for the responses.
--
Jason Morriss
http://www.psychostats.com/
On Sun, 7 Nov 2004, Shannon Wynter wrote:
Date: Sun, 07 Nov 2004 12:04:57 +1000
From: Shannon Wynter <[EMAIL PROTECTED] >
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [hlds_apps] Source RCON format
I only pad the packet to make my life easier for reassembly - you can
see this elsewhere in the class file
"Commands that span multiple only have the last packet with ACK and PUSH
(0x18) set, all others just have ACK set (0x10). Hopefully this might help."
However, if you just set yourself a realy short timeout on reading the
socket... seems to be the best solution anyone has found so far.
[EMAIL PROTECTED] wrote:
I don't believe there is a problem with the received rcon packets. Is it
possible this was an earlier bug that was fixed? Below is a sample from
some debug output of my class. It includes just the first 16 bytes from
each packet sent/received after issuing the rcon command 'cvarlist'. As
you'll see, each packet seems to include the proper header bytes just
fine. If you want to see the entire hexdump output let me know (it's too
long to post here).
If I glue the 'string1' packets together I get a perfect 'cvarlist' output
result, and I never have to add any sort of 'padding'. But there's no way
to tell when you've read the LAST packet in the input stream. That's the
point I'm trying to get across here.
Note: Below, the 'size' reported for each packet does not include the
4byte int32 size field, but the hexdumps shown include that size field.
DEBUG: Sending rcon packet: (send authorization)
0E 00 00 00 41 42 43 44 03 00 00 00 74 65 73 74 ....ABCD....test
--
DEBUG: Received (size: 10): (SERVERDATA_RESPONSE_VALUE, ignore)
0A 00 00 00 00 00 00 00 00 00 00 00 00 00 ..............
--
DEBUG: Received (size: 10): (auth response; valid)
0A 00 00 00 41 42 43 44 02 00 00 00 00 00 ....ABCD......
--
DEBUG: Sending rcon packet: (rcon cmd: cvarlist)
12 00 00 00 41 42 43 44 02 00 00 00 63 76 61 72 ....ABCD....cvar
--
DEBUG: Received (size: 4096): (remaining packets are cvarlist response)
00 10 00 00 00 00 00 00 00 00 00 00 63 76 61 72 ............cvar
--
DEBUG: Received (size: 4096):
00 10 00 00 00 00 00 00 00 00 00 00 61 69 5F 6E ............ai_n
--
DEBUG: Received (size: 4078):
EE 0F 00 00 00 00 00 00 00 00 00 00 61 69 5F 73 ............ai_s
--
DEBUG: Received (size: 3785):
C9 0E 00 00 00 00 00 00 00 00 00 00 62 6F 74 5F ............bot_
--
DEBUG: Received (size: 3951):
6F 0F 00 00 00 00 00 00 00 00 00 00 63 6C 5F 63 o...........cl_c
--
DEBUG: Received (size: 4102):
06 10 00 00 00 00 00 00 00 00 00 00 64 74 69 5F ............dti_
--
DEBUG: Received (size: 4065):
E1 0F 00 00 00 00 00 00 00 00 00 00 65 6E 74 5F ............ent_
--
DEBUG: Received (size: 4043):
CB 0F 00 00 00 00 00 00 00 00 00 00 67 5F 72 61 ............g_ra
--
DEBUG: Received (size: 3984):
90 0F 00 00 00 00 00 00 00 00 00 00 6B 69 6C 6C ............kill
--
DEBUG: Received (size: 4098):
02 10 00 00 00 00 00 00 00 00 00 00 6D 61 78 70 ............maxp
--
DEBUG: Received (size: 4026):
BA 0F 00 00 00 00 00 00 00 00 00 00 6D 70 5F 73 ............mp_s
--
DEBUG: Received (size: 4076):
EC 0F 00 00 00 00 00 00 00 00 00 00 6E 61 76 5F ............nav_
--
DEBUG: Received (size: 4081):
F1 0F 00 00 00 00 00 00 00 00 00 00 6E 65 74 5F ............net_
--
DEBUG: Received (size: 3970):
82 0F 00 00 00 00 00 00 00 00 00 00 6E 70 63 5F ............npc_
--
DEBUG: Received (size: 4084):
F4 0F 00 00 00 00 00 00 00 00 00 00 70 68 79 73 ............phys
--
DEBUG: Received (size: 4032):
C0 0F 00 00 00 00 00 00 00 00 00 00 72 5F 64 72 ............r_dr
--
DEBUG: Received (size: 4036):
C4 0F 00 00 00 00 00 00 00 00 00 00 72 5F 6E 6F ............r_no
--
DEBUG: Received (size: 4081):
F1 0F 00 00 00 00 00 00 00 00 00 00 73 63 65 6E ............scen
--
DEBUG: Received (size: 4057):
D9 0F 00 00 00 00 00 00 00 00 00 00 73 6E 64 5F ............snd_
--
DEBUG: Received (size: 4079):
EF 0F 00 00 00 00 00 00 00 00 00 00 73 76 5F 6C ............sv_l
--
DEBUG: Received (size: 3986):
92 0F 00 00 00 00 00 00 00 00 00 00 73 76 5F 72 ............sv_r
--
DEBUG: Received (size: 4081):
F1 0F 00 00 00 00 00 00 00 00 00 00 74 65 73 74 ............test
--
DEBUG: Received (size: 4075):
EB 0F 00 00 00 00 00 00 00 00 00 00 76 6F 78 65 ............voxe
--
DEBUG: Received (size: 504):
F8 01 00 00 00 00 00 00 00 00 00 00 77 63 5F 75 ............wc_u
_______________________________________________
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
_______________________________________________
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
