> > Here is one of the 22 byte packets. Just got 2 of them in a row > > (identical) in reponse to a 'e', 0x00 request: > > > > 00000020 FF FF FF FF 66 0D > > ....f. > > 00000030 00 00 00 00 44 77 72 7A 69 87 52 60 61 44 69 8C > > ....Dwrzi.R`aDi. > > This is a valid packet! The 4 byte null at the start indicates that > there are no more packets (this is the last one). There are > 2 hosts in > this response.
I know it's valid in and of itself, but in context, as the first response to a standard 'e', 0x00 request??? Or I've even seen it appear halfway down the response chain of packets (which in it's entirety is roughly 30 packets for about 6000 servers). If I only have 3000 servers I've collected so far and this packet appears, what's the deal? > Wow, I'm not sure how you're getting CVAR settings from a WON master > server. Are you SURE that you are querying the WON master and not a > Half-Life game server? Maybe somewhere the IP address of the > host you > are sending request packets to is getting replaced by the IP > address of > one of the responses (i.e. a game server). I will verify 100% tonight when I go home in a few hours to an environment where I have my network monitor, but I'm 97% positive this won't be the case. I've been doing most of my testing against half-life.central.won.net. Try half-life.west.won.net every now and then also. Same type of response problems. > 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? I'll check when I get home, but not sure how the number of bytes will help determine what's going on here? Other than if it's way too large, maybe packets are backing up and being mashed together? I'm 97% positive this isn't the case either as my script distincly sends out a single 'e' packet at a time and waits each time thereafter for a response, then parses the response, then sends the next 'e' packet out and repeats. I specifically wanted to avoid the problem of overlapping packets just for that very reason. > Have you tried using the new hlserver protocol specifying the > region you > are interested in? See Alfred's post on the new Steam > hlserver protocol... That's for Steam game servers. Pretty sure that won't return WON game servers...? Or that WON master servers will even respond to the '1' query? _______________________________________________ hlds_apps mailing list [EMAIL PROTECTED] http://list.valvesoftware.com/mailman/listinfo/hlds_apps
