Hi there,
Right now the D2X-XL tracker functions like telephone dial switch. Every host using the tracker sends a single byte message to it saying "I am a game host". The tracker stores the IP address of the message's sender in its table of game hosts. Clients (people looking for a host) send a single byte message to the tracker saying "Please send me your current table of hosts". Once the clients have received that table with IP addresses of available game hosts, they periodically send a "Give me your game info" message directly to the game hosts. This behavior is part of Descent's networking protocol (and hence not D2X-XL specific). Descent itself makes sure data endianness is handled properly (MSB machines convert data to be sent to LSB and received data to MSB).
If I remember correctly, the host table size is exactly 512 bytes, which is plenty given the actual amount of game hosts these days.
IP and port number endianness is not an issue - this is handled by the OS.
you can find all information about the D2X-XL tracker interface here:
http://www.descent2.de/d2x-tracker.html
I can see several approaches to retrieving detailled game info via a tracker.
Approaches
- The tracker is enhanced and will not only store the IP address of available game hosts, but also a well defined, relevant subset of their game parameters. As D2X-XL has introduced quite a bunch of new settings that are gameplay relevant. I would make a sound proposition of the required data structure design.
- The tracker stays as it is, and once your service has the hosts table, it directly queries the hosts themselves for their game info.
- Your service directly uses the present networking interface of Descent and has to properly interpret the game information it gets.
- Your service uses the present networking interface of Descent, but add a new message type for this particular purpose will be added and a game info data structure that is as concise as possible while giving all relevant information will be designed for it.
Data format
As far as I can tell, your tracking service will have to be expanded, as D2X-XL offers a bunch of additional multiplayer relevant game settings (smoke, target indicators, etc. etc.)
- There is already a useful data format your tracking service uses and which XL/R can support. Utilizing it would require moderate effort on your side for XL specific extensions.
- Your service directly uses the Descent game info data format and XL's extensions to it. This would put all the burden on you.
- A distinct game info data format will be defined that will require you to make greater changes in your tracking service or even branch to completely different handling of data formats.
Evaluation
(1.)
Advantage:
- The easiest way to query the data for you
Disadvantage:
- The tracker will require changes. Depending on the size of the game info, the number of game hosts returned in a single response packet of the tracker may be drastically reduced, requiring a more complicated protocol
- XL/R will require changes (minor changes for XL, as it already knows how to interface with the tracker)
(2.1)
Advantage:
- Neither Zico nor I would need to change the existing code (-> no inconsistencies due to different implementations, no need for coordination, particularly when the need of changes should arise)
- The tracker wouldn't need any changes and either lose storage capacity or would need to use a more complicated protocol in case there is so much data that it needs to be sent in several packets
Disadvantage:
- You would have to interpret the game data Descent sends, which is quite a bit.
(2.2)
Advantage:
- The tracker wouldn't need any changes and thus neither lose storage capacity nor would need to use a more complicated protocol in case there is so much data that it needs to be sent in several packets
- The game info data would be tailored to the actual requirement and hence be rather sleek and easy to handle
Disadvantage:
- The existing XL/R code would need to be expanded (the changes would be moderate and easy to handle)
- You would have to query all game hosts after having retrieved their addresses.
Conclusion
(1) While this may seem attractive at the first glance, it actually may not be. The problem is that right now a tracker response packet isn't all that big and you may not be able to store too many game host info records in it, requiring you to do extra data management and networking stuff, with all the problems of lost and out of sync UDP packets. A decision can only be made here after the final game info data design is available.
(2.1) Doesn't really make sense. The game info data Descent uses is too bloated for the purpose aimed at here, and probably a PITA to interpret for you.
(2.2) This solution looks quite attractive to me. It keeps the tracker communication of XL/R simple, and will minimize problems with packet loss, as you will only lose a single game host's information in case of networking problems, and not a big bunch as you would when a tracker response gets lost. Such a case could be easily detected using a timeout, and game info requests to such game hosts could be repeated.
The required game info data handling would be needed to be implemented in XL/R anyway, regardless of whether solution (1) or (2.2) are used.
Your tracking service might need an extra level of indirection by first having to query a tracker and then each game host the tracker returns, but this looks very straightforward to me.
Creating an HTML snippet that can be loaded into a tracker display page (e.g. using jQuery) wouldn't be a big thing. If need be, I can implement that. I would create some C/C++/C# code you could add to your tracking service (it is coded in C/C++, isn't it?)