Transactions CDX Service and Matchmaker Service

Turning now to Figure 1, in one embodiment, the mobile device A 102 and mobile device B 106 can be executing a collaborative application such as a multi-player game or a collaborative chat session which requires a P2P connection with one or more other computing devices. At NAT traversal request 110, mobile device A 102 transmits a CDX Hole-Punch Request to the CDX server 104. The CDX server 104 then responds with the CDX Hole-Punch Data at nat traversal response 112. In one embodiment, the hole punch data includes the public IP address and port of mobile device A and/or any other data needed to punch a hole through mobile device A‘s NAT (e.g., NAT type data defining mobile device A‘s NAT type). similar transactions are performed for mobile device B at NAT traversal request 116 and nat traversal response 118, respectively. 

At match request 116 and match request 120, mobile devices A and B then send match requests including the CDX Hole-Punch Data to the matchmaking service, along with any additional matching criteria (described below). At this stage, mobile devices A and B may begin to construct the Connection Data needed to establish a P2P connection. This may be accomplished, for example, using a transaction such as a standard Internet Connectivity Establishment (“ICE”) transaction (e.g., by a NAT traversal service). However, the underlying principles of the invention are not limited to any particular mechanism for determining Connection Data. 

In one embodiment, once the matchmaking service 108 has found a set of client devices with matching criteria, it may generate a unique CDX Session ID, a unique CDX Ticket for each member of the CDX Session, and a unique Session Key. In one embodiment, the matchmaking service 108 may encrypt the CDX Hole-Punch Data for the CDX Ticket using a unique CDX ticket key. At Ticket A 122 and Ticket B 124, the matchmaking service then may then send each of the mobile devices A and B their CDX Ticket and the Session Key. 

Mobile device A receives the CDX Ticket and Session Key and encrypts its previously determined Connection Data using the Session Key, making a payload. In one embodiment, mobile device A constructs a CDX Request by appending the constructed Payload to the CDX Ticket. At Ticket A with Connection Data 126, mobile device A sends the CDX Request to the CDX server 104. Mobile device B could also performs the same operations and transmit a request to the CDX server at 138. 

At authenticate Ticket A 128, the CDX server 104 receives the CDX Request, examines the ticket to ensure that it is valid and authentic (e.g., based on the Message Authentication Code 307). If the CDX Ticket is invalid, the request is dropped. In one embodiment, the CDX server then decrypts the CDX Hole-Punch Data set that is contained in the CDX Ticket using the CDX Ticket Key. In one embodiment, the CDX Ticket Key can include an expiration time/date which may also be transmitted with the tickets. The CDX service 104 and the matchmaker service 108 can store two (or more) different CDX ticket keys for encryption/decryption–a first which is currently active and a second which will become active upon reaching the expiration time/date of the first. Upon receiving a ticket, the CDX service 104 can read the expiration time/date to determine which ticket key to use. When a CDX Ticket Key has expired, both the CDX service 104 and the matchmaker service 108 can each generate a new ticket key (which will be the next key to be used after the current ticket key expires). In one embodiment, the CDX service 104 and matchmaker service 108 execute the same key generation algorithm to ensure consistency with the two ticket keys. For example, techniques such as those used for the well-known RSA SecurID authentication mechanism may be used in which a new authentication code is generated at fixed intervals. In one embodiment, a new CDX ticket key is generated on a daily basis. However, the underlying principles of the invention are not limited to any particular mechanism for generating CDX ticket keys. 

The same operations could be performed as shown at 136 for mobile device B. The CDX server constructs a CDX Response from the CDX Request and then uses the CDX Hole-Punch Data to send the CDX Response to the participants in the CDX Session (sending to mobile device B at 130 and to mobile device A at 140). 

mobile device B receives the CDX Response 130 from the CDX server. Client Device B examines the CDX Ticket Stub to ensure that the Session ID matches the Session ID of its own CDX Ticket. Mobile device B may then decrypt the payload using the Session Key, yielding the Connection Data from Mobile device A. Mobile device B then uses the Connection Data from mobile device A to begin the process of establishing the P2P session. In one embodiment, these involve standard ICE transactions. However, the underlying principles of the invention are not limited to any particular mechanism for establishing P2P communication. 

As mentioned above, in one embodiment, mobile device A and B establish Hypertext Transfer Protocol Secure (“HTTPS”) sessions to communicate with the matchmaker service 108 (e.g., using HTTPS request/response transactions) and establish UDP sockets to communicate with the CDX service. The match requestsTicket A 122, Ticket B 124 can include the NAT type and the hole punch data (e.g., the public IP address and port) previously determined for each respective mobile device. In an embodiment which involves a multi-player game, each match request can identify the player on each mobile device (e.g., using a unique player ID code), the game that each user wishes to play, the number of players to participate in the game, and/or other game configuration variables associated with the desired game. By way of example, and not limitation, the game configuration variables associated with a game may include a level of difficulty (e.g., easy, normal, difficult), a user’s age (e.g., “under 13”), a sub-region of the game (e.g., “level 2”), and/or a level of player expertise (e.g., expert, beginner, intermediate). As described in detail below, these variables are sometimes referred to as a game “bucket” and are identified using a unique “bucket ID.” Each game may include different sets of bucket IDs to identify different game configuration variables. 

In one embodiment, mobile device B sends and acknowledgement 132 and 134. Similarly, mobile device A‘s acknowledgement is transmitted at 146 and 144. If mobile device A‘s or B’s acknowledgements are not received after a specified period of time, then the Connection Data 130 may be resent to mobile device B 212. Either the CDX service 104 may initiate the retry and/or mobile device A 102 may initiate the retry. 

Figure 2 illustrates a more detailed example in which three different mobile devices 102-122 negotiate for P2P connections using the CDX service and matchmaker service 108. Figure 2 also illustrates two additional services used by the mobile devices 102-122 to establish a connection: a NAT traversal service 206 for determining NAT type and a NAT traversal service 204 for determining the full connection data for each mobile device (e.g., utilizing an ICE connection data transaction). It should be noted, however, that separate services are not required to comply with the underlying principles of the invention. For example, in an alternate embodiment, the NAT traversal functions performed by each of these services 204-206 may be integrated directly within the CDX service 104 and/or matchmaker service 108. Similarly, the functions performed by the both NAT traversal services 204-206 may be integrated within a single NAT traversal service. In summary, the specific functional separation shown in Figure 2 is not required for complying with the underlying principles of the invention. 

Turning now to the specific details of Figure 2, at 214, mobile device A transmits a NAT type request to the NAT traversal service 206. In response, the NAT traversal service 206 may use various known techniques including implementing a series of transactions to determine the NAT type used by mobile device A. For example, the NAT traversal service 206 may attempt to open different IP addresses and ports on mobile device A‘s NAT and communicate with mobile device A through those ports using different IP/port combinations. In this manner, the NAT employed by mobile device A may be classified as one of the NAT types described above (e.g., full cone, restricted cone, port restricted cone, symmetric) or an alternative NAT type. This information may then be provided to mobile device A 102 as illustrated. 

At 210, mobile device A 102 initiates a NAT traversal request with the CDX service 104. In response, the CDX service 104 can read the public IP address and public port number used for the request and transmits this information back to mobile device A 102. As described above, if a device is behind a NAT, its public port and IP address will be different from its private port and IP address, respectively. Thus, depending on the type of NAT being used, the public IP address and port may be used to “punch a hole” through the NAT device to reach the mobile device. 

At 216, mobile device A 102 transmits a match request 216 to the matchmaker service 108. As described above, in one embodiment, mobile device A communicates to the matchmaker service 108 using Hypertext Transfer Protocol Secure (“HTTPS”) sessions (e.g., using HTTPS request/response transactions). The match request can include the NAT type and the hole punch data (e.g., the public IP address and port) previously determined for mobile device A 102. In an embodiment which involves a multi-player game, the match request can identify the player on mobile device A (e.g., using a unique player ID code), the game that the user wishes to play, the number of players to participate in the game, and/or other game configuration variables associated with the desired game (as previously described with respect to Figure 1). 

At 212-220 a set of transactions corresponding to transactions 214-216 are performed for mobile device B 106 and at 222-226 a set of transactions corresponding to transactions 214-216 are performed for mobile device C 122. Thus, following transaction 226, the matchmaker service 108 has received match requests for all three of the mobile devices 102-122. In this specific example, the match requests result in mobile devices 102-122 being matched for a particular collaborative session such as a multi-player game (e.g., the users of these mobile devices may have selected the same game with the same, or similar, sets of variables, thereby resulting in a match by the matchmaker service 108). 

The matchmaker service 108 uses the data contained in each of the match requests to generate Ticket A, which it transmits to mobile device A at 228; Ticket B, which it transmits to mobile device B at 230; and Ticket C, which it transmits to mobile device C at 246. Although not shown in Figure 2, the matchmaker service 108 may utilize a push notification service to pushTickets A, B and C to mobile devices A, B, and C, respectively.

At 232, mobile devicemobile device A 102communicates with NAT traversal service 204 to determine its own connection data. In one embodiment, this can include a standard ICE connection data transaction. As previously mentioned, the Connection Data may include public/private IP address, port and NAT type for mobile device A 102. 

Mobile device A 102 appends its connection data to Ticket A and, at 244, transmits Ticket A with the Connection Data to the CDX service 104. In one embodiment, the CDX service 104 processes Ticket A as described above and, at 234, transmits the Connection Data (which may be encrypted) to mobile device B 106 and mobile device C 122. For these transactions, the CDX service 104 can utilize the NAT traversal data for mobile devices B and C included with Ticket A. 

At 236-238, a set of transactions corresponding to transactions 232-234 are performed using Ticket B and at 238-240 a set of transactions corresponding to transactions 232-234 are performed for Ticket C. Thus, following transaction 240, Connection Data has been shared between each of the mobile devices 102-122. Using the Connection Data, P2P sessions are established between mobile devices A and B, mobile devices A and C, and mobile devices A and C.