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
