3.1.5.2 Client Joins a DirectPlay Session with Multiple Other Clients

  • Article

  • The client sends an EnumQuery session packet in search of a chat session. The processing rules for the EnumQuery packet are specified in section 3.1.5.1.

  • The server responds to the client with an EnumResponse session packet. These DirectPlay session packets are identifiable by a leading zero-byte tag. The processing rules for the EnumResponse packet are specified in section 3.1.5.1.

  • The client requests a connection using a TRANS_COMMAND_CONNECT packet. The processing rules for the TRANS_COMMAND_CONNECT packet are specified in section 3.1.5.1.

  • The server responds with a TRANS_COMMAND_CONNECT_ACCEPT packet. The processing rules for the TRANS_COMMAND_CONNECT_ACCEPT packet are specified in section 3.1.5.1.

  • The client issues a TRANS_COMMAND_CONNECT_ACCEPT packet to acknowledge the connection. The processing rules for the TRANS_COMMAND_CONNECT_ACCEPT acknowledge packet are specified in section 3.1.5.1.

  • The server and client exchange TRANS_USERDATA_KEEPALIVE request packets.

  • The client sends user information in a TRANS_USERDATA_PLAYER_CONNECT_INFO packet.

  • If the TRANS_USERDATA_PLAYER_CONNECT_INFO packet fails validation, the server sends a TRANS_USERDATA_CONNECT_FAILED packet and the connection attempt is terminated with a TRANS_USERDATA_END_OF_STREAM packet from the server.

  • The server, after receiving the TRANS_USERDATA_PLAYER_CONNECT_INFO packet, alerts existing clients to the existence of the new client by sending a TRANS_USERDATA_ADD_PLAYER packet.

  • The server sends a TRANS_USERDATA_SEND_SESSION_INFO packet to the new client.

  • The new client tests the network path to the existing clients with SESS_PATH_TEST packets.

  • When processing a SESS_PATH_TEST packet:

    • The peer MUST search for outstanding TRANS_USERDATA_INSTRUCT_CONNECT and TRANS_USERDATA_ADD_PLAYER messages that have a matching key value as specified in section 3.1.3.

    • If a matching key is found and the connect attempt has not yet initiated to the intended target source address and port, the connect target SHOULD be modified to use the source address and port of the SESS_PATH_TEST packet.

    • If no connect attempt is associated with a matching key value, the existing peer MUST ignore the SESS_PATH_TEST packet.

      • If the recipient is the new client or the host, and therefore not intending to make any connection attempts, the SESS_PATH_TEST packet MUST be ignored.

  • The new client sends a TRANS_USERDATA_ACK_SESSION_INFO to acknowledge the game session information previously received from the server.

  • The server sends a TRANS_USERDATA_INSTRUCT_CONNECT packet to all clients (both existing and the new client) to instruct them to connect.

  • If an existing client cannot connect to the new client, the existing client responds with a TRANS_USERDATA_INSTRUCTED_CONNECT_FAILED user data packet, and the connection attempt to the new client is canceled.

  • Otherwise, each client initiates the connection with the new client using a TRANS_COMMAND_CONNECT packet.

  • The new client responds with a TRANS_COMMAND_CONNECT_ACCEPT packet.

  • Each existing client acknowledges the connection with a TRANS_COMMAND_CONNECT_ACCEPT packet.

  • The new client and each existing client exchange TRANS_USERDATA_KEEPALIVE packets, and the existing client transmits its user identifier in a TRANS_USERDATA_SEND_PLAYER_DNID packet to the new client.

  • Finally, all clients acknowledge the game session server and each other using TRANS_COMMAND_SACK packets. The processing rules for the TRANS_COMMAND_SACK packet are specified in section 3.1.5.1.