Are you sharing the receive buffer with another thread
perhaps?
Notice how toward the end of the "packet" there's a
different response tacked on? This looks like there could be
a problem with how the receive buffer is being maintained. When you
get a packet like this, how many bytes does the "recv" call
return?
Terry
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of EdGruberman
Sent: Wednesday, April 07, 2004 12:07 AM
To: [EMAIL PROTECTED]
Subject: [hlds_apps] Re: Master Server Query Results ValidationJeffrey "botman" Broome wrote:> If your 'runt' packet doesn't begin with...
>
> 0xFF, 0xFF, 0xFF, 0xFF, 'f'
>
> ...then should should bail out (and possibly restart the transfer from
> the beginning?).>> Are the bytes in the broken packet consistent (same thing each time you
> try it) or do you get random garbage each time. If it's consistent,
> what are the 22 bytes that you are getting?Well, that's a good question! :) The 22 bytes was just an example. Basically it's intermittent and random, but almost always it has the header data in it as expected. I tried to run a few more to get some examples and the first one I ran I hit another problem I noticed with "weird" packet responses. In response to a ('e', 0x00) I got:00000020 FF FF FF FF 66 0D ....f.
00000030 81 02 00 80 42 1C 17 61 69 B9 5C 70 72 6F 74 6F ....B..ai.\proto
00000040 63 6F 6C 5C 34 36 5C 63 68 61 6C 6C 65 6E 67 65 col\46\challenge
00000050 5C 32 31 32 36 38 36 35 35 31 39 5C 70 6C 61 79 \2126865519\play
00000060 65 72 73 5C 30 5C 6D 61 78 5C 31 36 5C 62 6F 74 ers\0\max\16\bot
00000070 73 5C 30 5C 67 61 6D 65 64 69 72 5C 63 73 74 72 s\0\gamedir\cstr
00000080 69 6B 65 5C 6D 61 70 5C 64 65 5F 61 7A 74 65 63 ike\map\de_aztec
00000090 5C 74 79 70 65 5C 64 5C 70 61 73 73 77 6F 72 64 \type\d\password
000000A0 5C 30 5C 6F 73 5C 77 5C 73 65 63 75 72 65 5C 31 \0\os\w\secure\1
000000B0 5C 6C 61 6E 5C 30 5C 76 65 72 73 69 6F 6E 5C 34 \lan\0\version\4
000000C0 2E 31 2E 31 2E 31 00 45 5D 60 9B 69 87 5C 70 72 .1.1.1.E]`.i.\pr
000000D0 6F 74 6F 63 6F 6C 5C 34 36 5C 63 68 61 6C 6C 65 otocol\46\challe
000000E0 6E 67 65 5C 31 39 36 35 35 30 35 32 38 35 5C 70 nge\1965505285\p
000000F0 6C 61 79 65 72 73 5C 30 5C 6D 61 78 5C 34 5C 62 layers\0\max\4\b
00000100 6F 74 73 5C 30 5C 67 61 6D 65 64 69 72 5C 63 73 ots\0\gamedir\cs
<hacked the rest of it off as you get the idea but it was a good sized ~1.4KB packet>It's the 'f' repsonse... but with 'infostringrespons' data??? What the...? I'm not even sure what to do with this packet other than hope the data is not evenly divisible by 6... Guess I could check if it has the '\protocol' string in it, but still, seems a bit kludgey... no?Sometimes I've seen it where the packets get "stuck" on the bad responses also. I'll send out an 'e', 0x00 packet and keeping getting the same runt packet back... I think thats happend with the 22byte packet I mentioned earlier, which btw to directly answer your question about it, the 22bytes looked like a normal batch server response with a good header and only 2 IPs and ports worth of info.So again, is there an easier way? Or if not, does anyone have some logic worked out for this? Is this normal???Stuck in UDP Frustration,EdGrubermanPersonal Website -- http://www.rjump.comAssault Maps -- http://www.assaultmaps.comTFC Server Monitor IRC Bot -- http://sentinel.rjump.com
