How you know it is a multipacket and where is the end of the transmission ?
On Sat, 6 Nov 2004 12:28:51 -0600 (CST), [EMAIL PROTECTED] <[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 > > -- > Jason Morriss > http://www.psychostats.com/ > > > On Sat, 6 Nov 2004, Shannon Wynter wrote: > > > Date: Sat, 06 Nov 2004 17:29:32 +1000 > > From: Shannon Wynter <[EMAIL PROTECTED]> > > Reply-To: [EMAIL PROTECTED] > > To: [EMAIL PROTECTED] > > Subject: Re: [hlds_apps] Source RCON format > > > > > > G'day there. > > > > I've solved this problem in php, perhaps you can use it. > > > > http://www.users.on.net/~freman/php/rcon.phps > > > > Basically, if you read the size field and it's greater then 4096 bytes > > then it's part of multipul packets and you should note that it appears > > that valve breaks the protocol here and doesn't include any of the other > > expected packet information. > > > > The important part is the function _PacketRead() > > > > There is also a lot more information and examples in other languages at > > http://wikki.kquery.net/index.php/Other:SourceRcon > > > > Regards > > > > Shannon > > > > > > [EMAIL PROTECTED] wrote: > > > > >Hi, > > > > > >Maybe I'm missing something but i'm having a little trouble with the > > >multi-packet responses from RCON commands with the source engine. > > > > > >>From what I can tell there's no way to tell when you've reached the end of > > >the multi-packet stream. > > > > > >I've seen various random information about the new tcp/rcon protocol being > > >'broken' with multi-packet responses but I see no evidence of that. It > > >appears to me that every packet has the proper size/request/command header > > >bytes. However, I can see that there's no way to tell when you've read the > > >LAST packet in a multi-packet stream. Obviously, if the first packet > > >you've read is less than 4096 then you know it's the only packet. But that > > >is the only case where you can be sure. > > > > > >And it's not possible to just keep reading packets until the size field is > > >< 4096, as the sizes flucutate a little with each response. > > > > > >Can someone else tell me what I'm missing here? > > > > > > > > > > > > > > > > > > _______________________________________________ > > 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
