> > > 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?
Just verified this 100%. "half-life.central.won.net" is resolving to junee.boston.sierra.com [65.73.232.252]. All my packets are sent to or received from that IP address. > > 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? Correct. Sorry I just didn't expand to that detail in my explanation. But yes, when I receive the 22 byte packet, my code will assume there is no more to get as the unique value is 0x00, 0x00, 0x00, 0x00 so it stops. That's my point. If I only have 15 or so packets so far (3000 or so game servers) and I get this 22byte packet, what gives? Obviously I haven't gotten all the servers the master server should be returning. So what should I use in code/logic to determine I really haven't gotten the end yet? I can put in some logic that says if I don't get at least 5000 servers then consider it a bogus packet. But you can see how that number is arbitrary... At best? > 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. Ah I see. I'm actually using the SocketWrench freeware utility from www.catalyst.com. I'm not sure of the specifics of their tool, possibly they could be doing something wrong also I guess. ==================================== ==============?????================= ==================================== But the question remains even if they are doing something wrong, that UDP packets have the possibility of getting whacked out during network transfer and the standard for UDP coding from every sight I run across is that since UDP is not a guaranteed protocol, it is the responsibility of the application to ensure successful data transfer. So, what can I use in the master server query protocol to fulfill this requirement? ==================================== ==============?????================= ==================================== > 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 n0ice!! :) I absolutely love the implementation of the color coding and direct copy/paste out of network monitor. Very associative. Very obvious. Even thought I code in VBS I frequently find C code very useful for determining base logic for my scripts. It's weird, I couldn't write a C program to save my life, but I feel pretty darn confident in reading it. :) So from that site I gather you've been spending a lot of time on this type of stuff. Do you have any logic in your code for FUBAR master server packet response situations? How do you determine you have good packet info? Full source? Sweet! I'll be looking for it to figure out what you did to determine such! :) _______________________________________________ hlds_apps mailing list [EMAIL PROTECTED] http://list.valvesoftware.com/mailman/listinfo/hlds_apps
