3.1.5.2 Peer-to-Peer Connect Sequence
Figure 6: Peer-to-peer connect sequence
Assuming the first peer has been launched, that peer will be deemed the host of the game session and will be in the process of accepting incoming connections. (The peer host is responsible for all name table transactions and synchronization across peers in the game session.)
The new peer establishes a connection to the host as specified in [MC-DPL8R].
The internal player connect message is sent in from the peer to the host:
DN_INTERNAL_MESSAGE_PLAYER_CONNECT_INFO_EX (DirectPlay 9)
When the peer sends the player connect message, it includes the user-provided password described in section 5.2, if present. When the host receives the message, it verifies the peer has specified compatible values; if a higher layer indicated that a password is required, the peer’s password string MUST exist and match exactly. If no password is required, the host SHOULD silently ignore any password string specified by the peer.
If the host fails in validating DN_INTERNAL_MESSAGE_PLAYER_CONNECT_INFO, the connecting peer is sent:
If the host successfully validates DN_INTERNAL_MESSAGE_PLAYER_CONNECT_INFO, the host creates a new name table entry for the connecting peer and adds the new entry into the host’s name table. The host increases its name table version by 1 and enters the new version into the new name table entry. The host then responds to the connecting peer with:
The DN_SEND_CONNECT_INFO message MUST contain the current game session state and settings. The message also contains a copy of the host’s updated name table.
Note The entries in the DN_NAMETABLE_ENTRY_INFO message will exist for each player connected to the game session.
Note If a password was required, the message includes the DPNSESSION_REQUIREPASSWORD flag and a redundant echo of the password that had been successfully verified. If no password was required, the DPNSESSION_REQUIREPASSWORD SHOULD NOT be included, and the dwPasswordOffset and dwPasswordSize values SHOULD be 0.
If the host is unable to verify the password and validation fails, the host sends a DN_CONNECT_FAILED message (section 2.2.1.3) with the hResultCode field set to DPNERR_INVALIDPASSWORD or to another validation failure code.
At the same time as the host is responding to the connecting peer with DN_SEND_CONNECT_INFO, the host is also issuing a message to the already-connected peers:
The DN_ADD_PLAYER message contains the new name table entry for the connecting player.
Upon receipt of the DN_SEND_CONNECT_INFO message from the host, the connecting peer will construct its initial name table state based on the entries and version number sent by the host and acknowledge the connection by returning:
After receiving DN_ACK_CONNECT_INFO from the connecting peer, the host instructs all existing peers to also establish a connection to the connecting peer by sending them the following message. The host will also send the following message to the connecting peer in order to keep the name table for the connecting peer in sync with the name tables of the existing peers in the session:
Upon receiving DN_INSTRUCT_CONNECT from the host, the existing peers will issue their DPNIDs to the new peer being added by sending:
If the modulo 4 result of the new version for the name table is equal to 0, the name tables of the existing peers are updated as described in section 2.2.6 with:
If existing peers are unable to successfully send the DN_SEND_PLAYER_DPNID message to the connecting peer, the existing peers will issue a fail packet back to the host:
Upon receiving the DN_INSTRUCTED_CONNECT_FAILED message from any of the existing peers, the host will send the connecting peer:
Host "removes player from the game session".