> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > EdGruberman > Sent: Wednesday, April 07, 2004 7:20 PM > To: [EMAIL PROTECTED] > Subject: RE: [hlds_apps] FW: Re: Master Server Query Results > Validation > > > > 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? >
I'm a little confused by this part. From below you say you send the first packet, wait for a response, send the next packet, wait for a response, etc. Once you receive this 22 byte packet you're done. So, there really shouldn't be an opportunity for more packets to come after that because you've already received them, right? > > > 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. > When I asked about buffer reuse, I was thinking in terms of C++. If you allocate a 2048 byte receive buffer, for example, and you use it to receive a 1400 byte packet, and then reuse it to receive a 22 byte packet without marking the end or paying attention to what's going on, it's easy to keep reading past the end of the packet you just received. I don't know if this will help, but I'm in the process of putting a site together for game browser development. The site as a whole is incomplete and just getting started, but I do have a writeup of the Half-Life master and game server protocol with sample C# code snippets (I'll be posting the full source tonight or tomorrow). It's here -> http://www.game-tracker.com/gameproto/halflife.htm Terry _______________________________________________ hlds_apps mailing list [EMAIL PROTECTED] http://list.valvesoftware.com/mailman/listinfo/hlds_apps
