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
