Query protocol and list server development

[blurredd]

My previous threads dealing with players timing out and creating a more convenient way for zipping level packs didn't get the type of response I was looking for (so far anyway), but I'm hoping this thread is different considering others are showing interest in further development in this area.

Basically what I want to propose is adapting an existing query protocol to be used with JJ2 in place of the current inefficient method of having a fake player join a server and retrieving information. I'm partial towards using the Gamespy Query Protocol version 4 (read more about it here (http://www.int64.org/docs/gamestat-protocols/gamespy2.html) and here (http://wiki.unrealadmin.org/UT3_query_protocol)), although it's mainly because it's used by UT3 and I like implementing Unreal Tournament ideas into JJ2 (must be because of the Epic relation).

I'm thinking a script would have to query the port that is server's hosting port + 1, so by default the query port would be 10053. The list servers should be updated to be able to handle custom game types and the like. A packet sent by a server connecting to the list servers will be used to indicate the server is capable of accepting the newer form of queries when listed in the server list.

I'm probably forgetting something, but I mostly want to get this out there before I forget to post this again. I would like to help establish a standard way of doing everything I proposed before I start work on anything (unlike what I did with JJ2+).

[djazz]

Sounds really interesting, BlurredD! :D

Some questions

Is this for both external and internal GIPs?
The server list needs JJ2+ features. Am I get it right?
And that fake player/gamespy would be the player viewing info about specified server? or?
Or is it a rebuild of the JJ2's protocol?

(Sorry if I'm total lost)

Feels good to stay the Epic way (UT, Killing Spree..).

[blurredd]

Is this for both external and internal GIPs?
Pretty much, though I don't intend on implementing the new form of server queries through JJ2 right away.

The server list needs JJ2+ features. Am I get it right?
Well, not really. I'm assuming by "server list" you mean the program the list servers use. The list servers would just need to somehow indicate which servers can accept queries using the new query protocol. Now that I think about it, I should look into how server browsing works on UT3.

And that fake player/gamespy would be the player viewing info about specified server? or?
Or is it a rebuild of the JJ2's protocol?
My proposal would be to simply implement server queries like how they are done on other games. That is, a script somewhere sends a packet indicating it wants info from a server, and the server replies with all the information in a single packet. No more sending multiple packets to establish a connection as a "player" and then receiving server information that way. It's an ugly hack which really shouldn't be used anymore--except to query older servers if that's really necessary. The new query protocol should be able to work through JJ2 without disrupting how servers usually works, though admittedly I am making a lot of assumptions right now.

I do plan on redoing all of JJ2's (and in turn JJ2+'s) net code since I think it's very limiting at the moment, but it's not something I want to focus on right now.

[Cpp]

You're assuming that most NATted jj2 servers have their port 10053 forwarded. I see a major firewall problem here. Personally I would go for an existing TCP port i.e. 10052 as most servers have that forwarded. Since plus is already capable of native packet inspection, you can design a new packet that houses all the query packets inside. Since non-plus servers won't recognize this packet, they will simply drop it. You can wrap an existing standard packets in a shell pretty easily, all you do is attach two bytes at the beginning of a packet - packet size and a new "query" packet ID.

struct TCP_Packet {
char PacketLength; // Length of the packet
char PacketID; // Identified type of packet
char ExtraData[]; // Can be of variable size
};


Also, the idea of having the server display ping of its clients (like in many other games) would be neat.

[blurredd]

I'm assuming that people will forward port UDP port 10053 when told to, which shouldn't be asking a lot. And when I manage to get UPnP working (some time in 2010...), they might not have to even think about it. I wouldn't want to use TCP since the packets for queries don't have to be reliable, plus JJ2's packet structure is limiting.

[Cpp]

Yeah, I just gave it some thought and it seems like trying to wrap the xfire stuff into a jj2 TCP packet structure would break the compatibility completely. Just one thought. I've always seen people suggest to forward ports 10052 and 10054 both TCP and UDP in order to get hosting working. We know that jj2 doesn't use all four options at once (10052:tcp, 10052:udp, 10054:tcp, 10054:udp), so do you think you can stick the query protocol in here somewhere rather than port 10053?