4.2 Example PATH_TEST Message

The following example has three participants:

  • PlayerA – The host, IPv4 address 192.168.1.3, port 2505.

  • PlayerB – An existing peer, IPv4 address 10.194.72.68, port 2302.

  • PlayerC – The joining peer, IPv4 address 192.168.1.2, port 2302.  PlayerC has local firewall software installed which prevents unsolicited inbound UDP messages.

For the purposes of this example, the following assumptions are made:

  • PlayerA has created a game session that uses an application GUID {02AE835D-9179-485F-8343-901D327CE794} and an instance GUID {C0A65D4F-9CE3-4F70-80DE-3AB4DF6F09B6}, as described in [MC-DPL8CS].

  • PlayerB has already joined PlayerA's game session and was assigned the DPNID value 0xC0965D4C, as described in [MC-DPL8CS].

  • PlayerC is in the process of joining the game session and previously exchanged the following messages with PlayerA as described in [MC-DPL8R] and [MC-DPL8CS]:

     Source: 192.168.1.2:2302, Dest: 192.168.1.3:2505,
          Type: MC-DPL8R CONNECT
     Source: 192.168.1.3:2505, Dest: 192.168.1.2:2302,
        Type: MC-DPL8R CONNECTED
     Source: 192.168.1.2:2302, Dest: 192.168.1.3:2505,
        Type: MC-DPL8R CONNECTED
     Source: 192.168.1.2:2302, Dest: 192.168.1.3:2505,
        Type: MC-DPL8CS DN_INTERNAL_MESSAGE_PLAYER_CONNECT_INFO
     Source: 192.168.1.3:2505, Dest: 192.168.1.2:2302,
        Type: MC-DPL8CS DN_SEND_CONNECT_INFO,
        assigning DPNID 0xC0F65D4B to PlayerC
     Source: 192.168.1.2:2302, Dest: 192.168.1.3:2505,
        Type: MC-DPL8CS DN_ACK_CONNECT_INFO
    
  • PlayerA has also already sent the following messages to PlayerB regarding the joining PlayerC as described in [MC-DPL8CS].

     Source: 192.168.1.3:2505, Dest: 10.194.72.68:2302,
        Type: MC-DPL8CS DN_ADD_PLAYER
     Source: 192.168.1.3:2505, Dest: 10.194.72.68:2302,
        Type: MC-DPL8CS DN_INSTRUCT_CONNECT
    

PlayerB now initiates an instructed connect to PlayerC, beginning with the CONNECT packet described in [MC-DPL8R] section 2.2.1.1, as seen in the following frame contents (Ethernet, IPv4, and UDP headers included):

  
 0000  00 1D 92 37 5E 40 00 0F B5 95 C3 C8 08 00 45 00   .. 7^@..µ ÃÈ..E.
 0010  00 2C 12 D8 00 00 7C 11 00 00 0A C2 48 44 C0 A8   .P.Ù..|....ÂHDÀ¨
 0020  01 02 08 FE 08 FE 00 18 21 EF 88 01 00 00 06 00   ...þ.þ..!ï .....
 0030  01 00 E4 1C B0 50 E4 CA 32 00                     ..ä.°PäÊ2.

The CONNECT packet arrives at PlayerC, but is rejected by the firewall because it does not have a mapping between local port 2302 and remote address 10.194.72.68:2302.Concurrent with the attempt by PlayerB to connect to PlayerC, PlayerC issues a PATH_TEST message to PlayerB using a message ID 0xD0C1 and key value 0xF9AFE99C92DD82B8 (due to the DNPIDs and GUIDs described above). This results in the following frame contents (Ethernet, IPv4, and UDP headers included):

  
 0000  00 0F B5 95 C3 C8 00 1D 92 37 5E 40 08 00 45 00   ..µ•ÃÈ..'7^@..E.
 0010  00 28 1C 45 00 00 80 11 09 D0 C0 A8 01 02 0A C2   .(.E..□..ÐÀ¨...Â
 0020  48 44 08 FE 08 FE 00 14 34 4B 00 05 C1 D0 B8 82   HD.þ.þ..4K..Áи‚
 0030  DD 92 9C E9 AF F9                                 Ý'œé¯ù

This outbound packet implicitly establishes a firewall mapping between local port 2302 and remote address 10.194.72.68:2302. PlayerB receives this PATH_TEST message, but PlayerB does not need to perform any of the optional state modifications described in section 3.1.5. In this example, there is no network address translation occurring, and therefore, there is no difference between the port to which the CONNECT packet was sent and the actual port that maps back to PlayerC.PlayerB now attempts to resend the CONNECT packet to PlayerC as described in [MC-DPL8R] section 2.2.1.1 (Ethernet, IPv4, and UDP headers included):

  
 0000  00 1D 92 37 5E 40 00 0F B5 95 C3 C8 08 00 45 00   .. 7^@..µ ÃÈ..E.
 0010  00 2C 12 D9 00 00 7C 11 00 00 0A C2 48 44 C0 A8   .P.Ù..|....ÂHDÀ¨
 0020  01 02 08 FE 08 FE 00 18 21 EF 88 01 01 00 06 00   ...þ.þ..!ï .....
 0030  01 00 E4 1C B0 50 E4 CA 32 00                     ..ä.°PäÊ2.

This time a firewall mapping exists, and the CONNECT packet is allowed to reach PlayerC. PlayerC responds with a CONNECTED packet as described in [MC-DPL8R] section 2.2.1.1, and continues with the peer connection sequence described in [MC-DPL8R] and [MC-DPL8CS]:

 Source: 192.168.1.2, Destination: 10.194.72.68,
    Type: MC-DPL8R CONNECTED
 Source: 10.194.72.68, Destination: 192.168.1.2,
    Type: MC-DPL8R CONNECTED
 Source: 10.194.72.68, Destination: 192.168.1.2,
    Type: MC-DPL8CS DN_SEND_PLAYER_DPNID