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
