UT3 query protocol

From UnrealAdminWiki

Basics

The query port (on the server) seems to be a random port number by default, contrary to the UT2003/4 situation where it was one port above the gameport. The protocol is Gamespy Query Protocol version 4, which uses UDP to send datagrams.

The UT3 query protocol is quite different from the UT2003/2004 query protocols, which were proprietary.

This is the basic schema:

1. Client sends request to Server
2. Server replies with a unique number
3. Client sends new request to Server, including said number
4. Server replies with query information

These are the specifications of the packets:

Packet 1: Initial request

FE FD 09 XX XX XX XX

The first 2 bytes (FE FD) are protocol identifier. In this case, they represent the Gamespy Query Protocol version 4.

Byte 3 (09) indicate that the client wishes to receive the challenge string.

Bytes 4 to 7 (XX XX XX XX) are a timestamp, in milliseconds. It is overall and per byte big-endian. According to the available data on Gamespy protocol, this can be any value, and is only used as an identifier to distinguish between multiple packets from the same server. Apparently UT3 uses time to generate these timestamps.

Packet 2: First response

09 XX XX XX XX YY YY YY YY YY YY YY YY YY YY YY YY

The first byte (09) indicates this is a reply to the initial request.

Bytes 2 to 6 (XX XX XX XX) are the sequence number that was in the initial request.

Bytes 7 to 18 (YY YY YY YY YY YY YY YY YY YY YY YY) is an ASCII represented number. This number can start with a - sign (2D), and is padded with 00's at the end.

Packet 3: Second request

FE FD 00 WW WW WW WW ZZ ZZ ZZ ZZ FF FF FF 01

The first two bytes (FE FD) again indicate the query protocol.

Byte 3 (00) indicates that this is a request for server information.

Bytes 4 to 7 (WW WW WW WW) is a new timestamp. It normally only changes in the first byte, as the 3rd request is usually sent within milliseconds of the first request.

Bytes 8 to 11 (ZZ ZZ ZZ ZZ) is the hexadecimal representation of the number received from Packet 2. If that number was negative, it needs to be subtracted from 4294967296 before it is transcoded into the hexadecimal value.

Bytes 12 to 15 are always (FF FF FF 01).

Or, in code (source):

 // $challenge was the number received from Packet 2,
 // We assume the timestamp is 10 20 30 40:
 $query = sprintf(
  "\xFE\xFD\x00\x10\x20\x30\x40%c%c%c%c\xFF\xFF\xFF\x01",
  ( $challenge >> 24 ),
  ( $challenge >> 16 ),
  ( $challenge >> 8 ),
  ( $challenge >> 0 )
 );
 // Now you can send $query and receive the server details.

Packet 4: Server information response

00 WW WW WW WW *DATA*

Byte 1 (00) indicates that this is a reply for a server information request.

Bytes 2 to 5 (WW WW WW WW) are the new timestamp, sent in Packet 3.

What follows is server information, in the following format:

This is taken from a Multiplay server, the first 16 bytes of the response packet are stripped, these included the 6 bytes mentioned above, and 10 bytes containing "splitnum" and some other weird bytes. This data is the exploded, meaning that the \0 character is used to separate different values. These values can be combined as "value n" => "value n+1", resulting in:

See also:

Cruz's UT3 Server Query Script