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-59] – 7saturn
+++ en:games:star_trek_armada_1:directplay_game_query [2024-10-30-02-08] (current) – [Description 1] 7saturn
@@ Line 8: / Line 8: @@
 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 //anet// 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 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.
 ^  Offset  ^  Description  ^
@@ Line 18: / 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. The offsets below are all based on the assumption, that this //anet// header is already stripped from the data.
+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 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 [[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 //anet// headers before those).
+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 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:
@@ Line 49: / Line 49: @@
 ==== Answer Contents ====
+=== General DirectPlay Structure ===
 The answer to such a request is relatively long, but mostly because the payload needs actual space:
@@ Line 72: / 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 95: / 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}}