Network Architecture

As illustrated in Figure 1, a general network topology implemented in one embodiment of the invention can include a group of “client” or “peer” mobile computing devices A-D (mobile device A 112, mobile device B 114, mobile device C 116, mobile device D 118) respectively, communicating with one another and with one or more services (CDX service 104, matchmaker service 106, and invitation service 108) over a network 110. Although illustrated as a single network cloud in Figure 1, the network 110 can include a variety of different components including public networks such as the internet and private networks such as local Wi-Fi networks (e.g., 802.11n home wireless networks or wireless hotspots), local area Ethernet networks, cellular data networks (e.g., 3G, edge, etc), and WiMAX networks, to name a few. For example, mobile device A 112 may be connected to a home Wi-Fi network represented by network link A 120, mobile device B 114 may be connected to a 3G network (e.g., Universal Mobile Telecommunications System (“UMTS”), High-Speed Uplink Packet Access (“HSUPA”), etc) represented by network link B 122, mobile device C 116 may be connected to a WiMAX network represented by network link C 124, and mobile device D 118 may be connected to a public Wi-Fi network represented by network link D 126. Each of the local networklinks (network link A 120, network link B 122, network link C 124, network link D 126) over which the mobile devices (mobile device A 112, mobile device B 114, mobile device C 116, mobile device D 118) are connected may be coupled to a public network such as the internet through a gateway and/or NAT device (not shown in Figure 1), thereby enabling communication between the various mobile devices (mobile device A 112, mobile device B 114, mobile device C 116, mobile device D 118) over the public network. However, if two mobile devices are on the same local or private network (e.g., the same Wi-Fi network), then the two devices may communicate directly over that local/private network, bypassing the public network. It should be noted, of course, that the underlying principles of the invention are not limited to any particular set of network types or network topologies. 

Each of the mobile devices (mobile device A 112, mobile device B 114, mobile device C 116, mobile device D 118) illustrated in Figure 1 can communicate with a connection data exchange (CDX service 104), a matchmaker service 106, and an invitation service 108. In one embodiment, the services (CDX service 104, matchmaker service 106, and invitation service 108) can be implemented as software executed across one or more physical computing devices such as servers. As shown in Figure 1, in one embodiment, the services (CDX service 104, matchmaker service 106, and invitation service 108) may be implemented within the context of a larger data service 102 managed by the same entity (e.g., the same data service provider) and accessible by each of the mobile devices (mobile device A 112, mobile device B 114, mobile device C 116, mobile device D 118) over the network 110. The data service 102 can include a local area network (e.g., an Ethernet-based LAN) connecting various types of servers and databases. The data service 102 may also include one or more storage area networks (“SANs”) for storing data. In one embodiment, the databases store and manage data related to each of the mobile devices (mobile device A 112, mobile device B 114, mobile device C 116, mobile device D 118) and the users of those devices (e.g., user account data, device account data, user application data, . . . etc.). 

In one embodiment, matchmaker service 106 can matchtwo or more mobile devices for a collaborative P2P session based on a specified set of conditions. For example, users of two or more of the mobile devices may be interested in playing a particular multi-player game. In such a case, the matchmaker service 106 may identify a group of mobile devices to participate in the game based on variables such as each user’slevel of expertise, the age of each of the users, the timing of the match requests, the particular game for which a match is requested and various game-specific variables. By way of example, and not limitation, the matchmaker service 106 may attempt to matchusers with similar levels of expertise at playing a particular game. Additionally, adults may be matched with other adults and children may be matched with other children. Moreover, the matchmaker service 106 may prioritize user requests based on the order in which those requests are received. The underlying principles of the invention are not limited to any particular set of matching criteria or any particular type of P2P application. 

As described in detail below, in response to a match request, the matchmaker service 106 can coordinate with the CDX service 104 to ensure that all matched participants receive the necessary connection data for establishing P2P sessions in an efficient and secure manner. 

In one embodiment, the invitation service 108 also identifies mobile devices for participation in collaborative P2P sessions. However, in the case of the invitation service 108, at least one of the participants is specifically identified by another participant. For example, the user of mobile device A 112 may specifically request a collaborative session with the user of mobile device B 114 (e.g., identifying mobile device B 114 with a user ID or phone number). As with the matchmaker service 106, in response to an invitation request, the invitation service 108 can identify the set of participants and coordinate with the CDX service 104 to ensure that all participants receive the necessary connection data for establishing P2P sessions in an efficient and secure manner. 

As mentioned above, in one embodiment, the CDX service 104 operates as a central exchange point for connection data required to establish P2P sessions between two or more mobile devices. Specifically, one embodiment of the CDX service generates NAT traversal data (sometimes referred to as “Hole Punch” data) in response to mobile device requests to enable external services and clients to communicate through the NAT of each mobile device (i.e., to “punch a hole” through the NAT to reach the device). For example, in one embodiment, the CDX service detects the external IP address and port needed to communicate with the mobile device and provides this information to the mobile device. In one embodiment, the CDX service also receives and processes lists of mobile devices generated by the matchmaker service 106 and invitation service 108 and efficiently and securely distributes connection data to each of the mobile devices included on the lists (as described in detail below). 

In one embodiment, communication between the mobile devices and the CDX service 104 is established using a relatively lightweight network protocol such as User Datagram Protocol (“UDP”) sockets. As is known by those of skill in the art, UDP socket connections do not require hand-shaking dialogues for guaranteeing packet reliability, ordering, or data integrity and, therefore, do not consume as much packet processing overhead as TCP socket connections. Consequently, UDP’s lightweight, stateless nature is useful for servers that answer small queries from a vast number of clients. Moreover, unlike TCP, UDP is compatible with packet broadcasting (in which packets are sent to all devices on a local network) and multicasting (in which packets are sent to a subset of devices on the local network). As described below, even though UDP may be used, security can be maintained on the CDX service 104 by encrypting NAT traversal data using session keys. 

In contrast to the low-overhead, lightweight network protocol used by the CDX service 104, in one embodiment, communication between the mobile devices (mobile device A 112, mobile device B 114, mobile device C 116, mobile device D 118) and the matchmaker service 106 and/or invitation service 108 is established with an inherently secure network protocol such as Hypertext Transfer Protocol Secure (“HTTPS”), which relies on Secure Sockets Layer (“SSL”) or Transport Layer Security (“TLS”) connections. Details associated with these protocols are well known by those of skill in the art. 

Specific examples in which mobile devices establish primary and secondary communication channels will now be described with respect to Figure 2. It should be noted, however, that the underlying principles of the invention are not limited to the particular set of communication links and communication channels shown in Figure 2. 

In Figure 2, mobile device A 112 is capable of connecting to a network 110 (e.g., the internet) over communication link (communication link B 210 with NAT device B 206 and over communication link A 206 with NAT device A 202. Similarly, mobile device C 116 is capable of connecting to the network 110 over communication link C 214 with NAT device C 212 and over communication link D 216 with NAT device C 212. By way of example, and not limitation, communication links (communication link B 210 and communication link C 214) may be 3 G communication links and communication links (communication link A 206 and communication link D 216) may be Wi-Fi communication links. 

Consequently, in this example, there are four different communication channels which may be established between mobile device A 112 and mobile device B 114: a first channel which uses links (communication link B 210 and communication link C 214); a second channel which uses links (communication link B 210 and communication link D 216); a third channel which uses links (communication link A 206 and communication link C 214); and a third channel which uses linkscommunication link A 206 and communication link D 216). In one embodiment, mobile devices A and B will select one of these channels as the primary communication channel based on a prioritization scheme and will select the three remaining channels as backup communication channels. For example, one prioritization scheme may be to select the channel with the highest bandwidth as the primarychannel and to use the remaining channels as the secondary channels. If two or more channels have comparable bandwidth, the prioritization scheme may include selecting the least expensive channel (assuming that the user pays a fee to use one or more of the channels). Alternatively, the prioritization scheme may be to select the least expensive channel as the primarychannel and, if the cost of each channel is the same, to select the highest bandwidth channel. Various different prioritization schemes may be implemented while still complying with the underlying principles of the invention. 

Mobile device A 112 and mobile device C 116 may utilize the techniques described above to establish the primary communication channel (e.g., by exchanging connection data via the CDX service 104). Alternatively, the mobile device A 112, and mobile device C 116 may implement standard Internet Connectivity Establishment (“ICE”) transactions to exchange the connection data. Regardless of how the primarychannel is established, once it is, the mobile device A 112 and mobile device C 116 may exchange connection data for the secondary communication channels over the primary communication channel. For example, if the primary communication channel in Figure 2 includes communication link A 206 and communication link C 214, then this connection, once established may be used to exchange connection data for secondary communication channels which include communication links (communication link B 210 and communication link C 214). In this example, the connection data exchanged over the primary communication channel may include NAT traversal data and NAT type data for NAT device B 206 and NAT device C 212, including public and private IP addresses/ports for each of the mobile devices. 

Once the secondary communication channels have been established, they are maintained open using heartbeat packets. For example, device A may periodically transmit a small “heartbeat” packet to device C and/or device A may periodically transmit a small “heartbeat” packet to device C to ensure that the NAT ports used for the secondary channels remain open (NATs will often close ports due to inactivity). The heartbeat packets may be UDP packets with no payload, although the underlying principles of the invention are not limited to any particular packet format. The heartbeat packets may be UDP packets with a self-identifying type field in their payload header, and may contain optional additionally-formatted information including but not limited to a channel time-to-live value. 

Figure 3 illustrates the same network configuration as shown in Figure 2 with the addition of mobile device B 114 connected directly to the network 110 and connected to mobile device C 116 through a private network 306 connection. The private network 306 may be, for example, a Bluetooth PAN connection between mobile device B 114 and mobile device C 116. It can be seen from this example that switching from a primarychannel to a secondary channel may dramatically alter the network topology. 

For example, as shown in Figure 4, if the primary channel A 402 for the mobile devices include communication link C 214 (resulting in direct connections between devicedevices A, B and C) and the secondary channels include the private network 306, then the network topology may change as illustrated in Figure 4 because the only way for device A and device C to communicate using the private network is through device B. While this is a simplified example with only three devices, a significantly larger number of devices may be used, resulting in a variety of different network topology configurations when switching between primary and secondary communication channels. 

As illustrated in Figure 5, in addition to the CDX service 104, matchmaker service 106 and invitation service 108 (some embodiments of which are described above), one embodiment of the invention can include a registration /directory service 520, a push notification service 522, and a relay service 516. As mentioned above, in one embodiment, the invitation service 108 and/or the matchmaker service 106 can use the registration /directory service 520 to identify registered mobile devices and the push notification service 522 to push data to the mobile devices. In one embodiment, when a mobile device is activated on the network, it registers a “push token” (sometimes referred to as a “notification service account identifier” in the Push Notification Application) with a database maintained by the registration /directory service 520 by associating the push token with a password protected user ID or a telephone number. If the push token is identified in the registration directory (e.g., by performing a query with the user ID), the push notification service 522 can use the push token to transmit push notifications to a mobile device. In one embodiment, the push notification service is the Apple push notification service (“APNS”) designed by the assignee of the present application and described, for example, in the Push Notification Application referenced above.