Differences

This shows you the differences between two versions of the page.

--- en:games:star_trek_armada_1:directplay_game_query [2024-10-20-13-46] – created 7saturn
+++ en:games:star_trek_armada_1:directplay_game_query [2024-10-30-02-08] (current) – [Description 1] 7saturn
@@ Line 1: / Line 1: @@
 ====== DirectPlay Game Query ======
 //Star Trek: Armada// could be played basically via one of the following network means:
-  - TCP/IP LAN play,
+  - [[en:network_terms:tcp|TCP]]/IP LAN play,
-  - IPX LAN play and
+  - [[en:network_terms:ipx|IPX]] LAN play and
-  - WON internet play.
+  - [[en:gaming_platforms:world_opponent_network|WON]] internet play.
-The actual game play is facilitated by DirectPlay connections. The queries for open games are slightly different for the above mentioned types of connection/game set-up. But in essence DirectPlay is always involved. As WON worked differently in terms of how to gain a list of open games, it will not be described here. But for the LAN play options, see below. They all do DirectPlay game queries, giving them the information of where a game is open, and what properties it does have (e.g. game name or map being used).
+The actual game play is facilitated by [[en:game_tech:directx#directplay|DirectPlay]] connections. The queries for open games are slightly different for the above mentioned types of connection/game set-up. But in essence DirectPlay is always involved. As WON worked differently in terms of how to gain a list of open games, it will not be described here. But for the LAN play options, see below. They all do DirectPlay game queries, giving them the information of where a game is open, and what properties it does have (e.g. game name or map being used).
 ===== TCP/IP vs. IPX =====
-Basically it is not really relevant, how exactly the TCP/IP connection or the IPX connection is established. The actual contents sent by the game must of course be transported properly to the other peers. But if it is a native IPX connection or an RFC 1234 IPX server, are details the game will not know anything about. Same goes for some VPN solutions via TCP. It is just important to note, that when doing an analysis of network traffic, one must of course keep in mind, that overhead from other protocols (e.g. RFC 1234 UDP headers and IPX headers) is to be excluded from any analysis for DirectPlay game queries.
+Basically it is not really relevant, how exactly the TCP/IP connection or the IPX connection is established. The actual contents sent by the game must of course be transported properly to the other peers. But whether it is a native IPX connection or an RFC 1234 IPX server, are details the game will know nothing about. Same goes for TCP via some VPN solution. It is just important to note, that when doing an analysis of network traffic, one must of course keep in mind, that overhead from other protocols (e.g. RFC 1234 [[en:network_terms:udp|UDP]] headers and IPX headers) is to be excluded from any analysis for DirectPlay game queries.
+When receiving the TCP packages, the following socket header is considered to be part of the DirectPlay header by //WireShark//. Considering that it is not part of the IPX packages, it stands to reason, that this based on a wrong assumption that it is part of the DirectPlay contents. It must be skipped to get to the actual DirectPlay contents.
-When receiving the TCP packages, the following anet header is considered to be part of the Direct Play header by WireShark. Considering that it is not part of the IPX packages, it stands to reason, that this is a wrong assumption that it is part of the DirectPlay contents, but the //anet// header. It must be skipped to get to the actual DirectPlay contents:
 ^  Offset  ^  Description  ^
 | 00/00 | Size of the entire part, including the DirectPlay contents (0x8e 0x00) |
@@ Line 17: / Line 18: @@
 | 12/0c | Padding (0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00) |
-So in total a length of 20 bytes can be skipped, to get to the DirectPlay contents.
+So in total a length of 20 bytes can be skipped, to get to the DirectPlay contents. The offsets below are all based on the assumption, that this socket header is already stripped from the data.
 ===== The DirectPlay Analysis =====
 ==== Method ====
-For the analysis of the game's sent and received data Wireshark was used on a LAN, once with direct TCP/IP packages send, and once with an RFC 1234 UDP-IPX-server in-between the peers. This already requires to carefully look at the results. Apparently Wireshark does not know about RFC 1234 wrapped IPX messages. It does recognize the UDP connection and also that there is IPX content inside of the UDP datagram. But it does not recognize the DirectPlay packages inside the IPX package as such. However, when connecting directly via TCP/IP it does indeed recognize DirectPlay contents for what they are and gives a detailed analysis of the different parts of each DirectPlay package, like headers or what kind of fields and flags are being used.
+For the analysis of the game's sent and received data Wireshark was used on a LAN, once with direct TCP/IP packages used and once with an RFC 1234 UDP-IPX-server in-between the peers. This already requires to carefully look at the results. Apparently Wireshark does not know about RFC 1234 wrapped IPX messages. It does recognize the UDP connection and also that there is IPX payload inside of the UDP datagram. But it does not recognize the DirectPlay payload inside the IPX package as such. However, when connecting directly via TCP/IP it does indeed recognize DirectPlay contents for what they are and gives a detailed analysis of the different parts of each DirectPlay package, like headers or what kind of fields and flags are being used.
-When looking at the packages sent back and forth between a peer having an open game lobby, and a peer requesting open lobbies via broadcast from everyone else on the same subnet, the contents are fairly the same for TCP/IP and IPX. The network headers are different of course (the IPX header being removed leaves the very same contents, as are sent via TCP/IP, while TCP/IP seems to add //anet// headers).
+When looking at the packages sent back and forth between a peer having an open game lobby, and a peer requesting open lobbies via broadcast from everyone else on the same [[en:network_terms:subnet]], the contents are fairly the same for TCP/IP and IPX. The network headers are different of course (the IPX header being removed leaves the very same contents, as are present via TCP/IP, while TCP/IP seems to add socket headers before those).
-So for the analysis the TCP/IP parts were taken as a base of reference also for the IPX messages. Headers that have nothing to do with DirectPlay were removed, leaving only the following contents.
+So for the analysis of IPX sent DirectPlay the TCP/IP representation was taken as a base of reference. Headers that have nothing to do with DirectPlay were removed, leaving only the following contents:
 ==== Query Contents ====
-The game query is actually rather short, once headers of TCP or IPX are removed:
+The open game query is actually rather short, once headers of TCP or IPX are removed:
 ^  Group  ^  Offset (Dec/Hex))  ^  Description  ^
 | Header | 00/00 | The word //play// (0x70 0x6c 0x61 0x79) |
@@ Line 45: / Line 45: @@
 The game queries all games, not filtering for anything. The filtering happens on the client side. So the in-game selection field does not control which contents come from the peers having a session opened.
+These messages are sent to the broadcast address. For TCP/IP that is 255.255.255.255, for IPX it is ff:ff:ff:ff:ff:ff. Note: In case of the TCP/IP broadcast, the game apparently only uses the primary network card (whose metric is the lowest). Meaning, if you are connected to multiple networks, only on of them is actually considered. If that is some VPN solution's network card, then an actual LAN game cannot be found in this fashion.
 ==== Answer Contents ====
+=== General DirectPlay Structure ===
 The answer to such a request is relatively long, but mostly because the payload needs actual space:
@@ Line 70: / Line 73: @@
 | Data | 92/5c | Lobby name, 30 bytes |
-Session Description Flags are a bit field of length 32 bits/4 bytes with the following meaning:
+//Session Description Flags// are a bit field of length 32 bits/4 bytes with the following meaning:
 ^  Bit Position  ^  Description  ^
@@ Line 93: / Line 96: @@
 | 32 | No Create Players |
-Reserved 1 and Description 1 seem to change. They must somehow indicate, whether there is a password set, or not, and if it is a head to head match, or a normal match. The clients can tell the difference, so it must be in there. It may also contain information about any already running match (clients also can tell the difference).
+**Note**: The //Session Description Flags// like //Can Join// have nothing to do with the actual Armada information about the match, e.g. whether the game is closed off, or not. Some of that information can be found in the //Description 1// block.
+=== Description 1 ===
+Reserved 1 and Description 1 seem to change. The rest is (aside from the obvious GUIDs) static. //Description 1// holds at least the following information. The offset values are 0-based in relation to the entire DirectPlay block (first byte has number 0, values only start at 72). The bits are 1 based.
+^ Byte Dec ^ Byte Hex ^ Bit ^ Description ^
+| 73 | 49 | 1-3 | Max. number of players. If this value is 8 (all player slots available), all three bits are set to 0. Otherwise the little-endian representation is the actual max. number of players. |
+| 74 | 4a | 2 | IS the match a head-to-head match (basically 1v1)? 1 means yes, 0 means no. |
+| 74 | 4a | 3 | Has the match been protected by a password? 1 means yes, 0 means no. |
+| 74 | 4a | 6 | Is a match already ongoing (has started)? 1 means yes, 0 means no. |
+| 74 | 4a | 7 | Has the match been closed (no joining possible)? 1 means yes, 0 means no. |
 {{page>footer&nofooter}}