3.1.5.1 Client Joins a DirectPlay Session with No Other Clients

  • Article

  • The client sends an EnumQuery (section 2.2.4) session packet in search of a chat session.

  • When processing an EnumQuery packet:

    • The server MUST validate the CommandByte field for a valid value as specified in section 2.2.4; otherwise, the packet SHOULD be ignored.

    • The server MUST validate the QueryType field for a valid value as specified in section 2.2.4; otherwise the packet SHOULD be ignored.

    • The server SHOULD NOT respond to the EnumQuery messages when the QueryType field is 0x01 and the ApplicationGUID field does not match the server application GUID.

  • The server responds to the client with an EnumResponse session packet. These DirectPlay session packets are identifiable by a leading zero-byte tag.

  • When processing an EnumResponse packet:

    • The client MUST validate the CommandByte field for a valid value as specified in section 2.2.5; otherwise, the packet SHOULD be ignored.

    • The client MUST match the value of the EnumPayload field of the EnumResponse packet with the EnumPayload field values of EnumQuery messages that were previously sent. Otherwise, the EnumQuery message SHOULD be retried by the client.

  • The client requests a connection using a TRANS_COMMAND_CONNECT packet.

  • When processing a TRANS_COMMAND_CONNECT packet:

    • If the source address corresponds to an existing, fully established connection it SHOULD be ignored.

    • If the source address is from an earlier received inbound connection that has not completed the connection handshake process and the value of the dwSessID field matches the previously received TRANS_COMMAND_CONNECT, then a TRANS_COMMAND_CONNECT_ACCEPT (section 2.2.8) message SHOULD be sent; otherwise, the packet SHOULD be ignored.

    • If the source address is from a previously established outbound connection that has not completed the connection handshake process, the packet SHOULD be ignored.

    • If the recipient is not allowing connections, the packet MUST be ignored.

    • If the source address does not correspond to any existing connection, it SHOULD be treated as a new connection attempt and the bExtOpcode field MUST be validated as described in section 2.2.7.

      • If the validation succeeds, a TRANS_COMMAND_CONNECT_ACCEPT packet SHOULD be sent in response; otherwise, the packet MUST be ignored.

  • When processing a TRANS_COMMAND_CONNECT_ACCEPT packet:

    • The source address SHOULD be verified. If the address does not correspond to one with a partially or fully established connection, it SHOULD be ignored.

    • If the source address matches that of a previously initiated outbound connection that has not completed the connection handshake process, then validation checks SHOULD be performed as described.

      • If the bExtOpcode field does not have a valid value, the packet MUST be ignored.

      • If the bCommand field is set to 0x80, then the TRANS_COMMAND_CONNECT_ACCEPT acknowledge packet SHOULD NOT be sent.

      • The dwSessID field MUST match the one previously sent in the TRANS_COMMAND_CONNECT packet and the bCommand field MUST have the POLL value set.

  • The client issues a TRANS_COMMAND_CONNECT_ACCEPT packet to acknowledge the connection.

  • When processing a TRANS_COMMAND_CONNECT_ACCEPT acknowledge packet:

    • The source address SHOULD be verified. If the address does not correspond to one with a partially or fully established connection, it SHOULD be ignored.

    • If the source address matches that of a previously initiated outbound connection that has not completed the connection handshake process, then validation checks SHOULD be performed as described in the following steps.

      • If the bExtOpcode field does not have a valid value, the packet MUST be ignored.

      • If the bCommand field is set to 0x88, the Connect Retry Timer SHOULD be initiated as described in section 3.1.2.1.

      • The dwSessID field MUST match that of the previously sent TRANS_COMMAND_CONNECT_ACCEPT packet.

      • The bCommand field MUST NOT have the POLL value set.

  • The server and client exchange TRANS_USERDATA_KEEPALIVE request packets.

  • The client sends user information in a TRANS_USERDATA_PLAYER_CONNECT_INFO packet. The client can send this packet either in between the keep-alive exchange or after the keep-alive exchange has completed.

  • 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 sends session information in a TRANS_USERDATA_SEND_SESSION_INFO packet.

  • The client MUST send a TRANS_USERDATA_ACK_SESSION_INFO to the server.

  • The server sends a TRANS_USERDATA_INSTRUCT_CONNECT to the client to instruct it to form a connection.

  • The client responds with a TRANS_USERDATA_NAMETABLE_VERSION packet.

  • The server sends a TRANS_USERDATA_RESYNC_VERSION packet.

  • The client acknowledges it by sending a TRANS_COMMAND_SACK packet.

  • When processing a TRANS_COMMAND_SACK packet:

    • The source address SHOULD be verified. If the address does not correspond to one with a fully established connection, it MUST be ignored.