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
