Drawings
Figure 1 illustrates a network architecture in which a group of mobile devices and services communicate over a network.
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.
Figure 2 illustrates a group of mobile devices connected through primary and secondary communication channels.
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 a group of mobile devices connected through primary and secondary communication channels
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.
Figure 4 illustrates the resulting network topologies from Figure 3.
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.
Figure 5 illustrates a network architecture in which a group of mobile devices and services, including a registration /directory service 502 and a push notification service 504 communicate over a network 110.
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.
Parts List
102
data service
104
CDX service
106
matchmaker service
108
invitation service
110
network
112
mobile device A
114
mobile device B
116
mobile device C
118
mobile device D
120
122
124
126
202
NAT device A
204
NAT device D
206
NAT device B
208
210
212
NAT device C
214
216
302
private network
304
communication link E
306
communication link F
402
primary channel A
404
primary channel B
502
registration /directory service
504
push notification service
506
relay service
Terms/Definitions
device
other children
same entity
first channel
remaining channels
mobile device B
various different prioritization schemes
subset
particular device configuration
User Datagram Protocol
primary and secondary communication channels
addition
direct connections
hand-shaking dialogues
expertise
primary channel A
skill
same data service provider
Transport Layer Security
servers and databases
users
match request
network topology
case
information
wireless hotspots
standard Internet Connectivity Establishment
P2P sessions
Secure Sockets Layer
links
other adults and children
High-Speed Uplink Packet Access
private network connection
network types or network topologies
NAT traversal data
channels
conditions
invention
secondary channels
CDX service
underlying principles
communication link A
two or more channels
network link C
software
primary communication channel
mobile device A
variety
communication link C
“SANs”
backup communication channels
Ethernet-based LAN
communication channels
secondary communication channels
databases store
vast number
devices
highest bandwidth channel
participation
public network
home Wi-Fi network
phone number
user application data
P2P application
service
connection data
order
switching
security
relay service
stateless nature
game
protocols
third channel
their payload header
various mobile devices 120
general network topology
cellular data networks
802.11n home
such a case
internet
NAT device
local network
requests
network link D
matching criteria
small queries
second channel
WiMAX networks
only three devices
local area Ethernet networks
UDP socket connections
communication link B
3 G communication links
device B
payload
larger data service
mobile device C
link management module
mobile device requests
optional additionally-formatted information
lists
networks
servers
Hypertext Transfer Protocol Secure
NATs
same Wi-Fi network
public Wi-Fi network
low-overhead
NAT device B
particular game
detail
NAT ports
external IP address
channel time-to-live value
NAT device D
connection data exchange
participants
particular multi-player game
mobile devices and services
example
data integrity
various game-specific variables
various types
two or more mobile devices
specified set
clients
private network
mobile device D
response
particular packet format
limitation
small “heartbeat” packet
Universal Mobile Telecommunications System
four different communication channels
edge
collaborative P2P sessions
Bluetooth PAN connection
techniques
two devices
local/private network
timing
“UMTS”
simplified example
user requests
collaborative P2P session
packet broadcasting
network architecture
data service
inherently secure network protocol
NAT device A
similar levels
registration /directory service
external services
3G network
different network topology configurations
NAT type data
heartbeat packets
communication link D
primary
method
network link B
highest bandwidth
lightweight network protocol
invitation request
context
match
local area network
channel
communication link F
specific examples
details
primary channel B
public networks
contrast
single network cloud
group
secure manner
network
socket connections
packets
open using heartbeat packets
UDP packets
different components
bandwidth
course
two mobile devices
efficient
Wi-Fi communication links
user
user ID
matchmaker service
network link A
device C
resulting network topologies
port
user account data
prioritization scheme
relatively lightweight network protocol
collaborative session
push notification service
lightweight
central exchange point
only way
public and private IP addresses/ports
significantly larger number
local Wi-Fi networks
variables
private networks
particular set
WiMAX network
match requests
user’s
ports
invitation service
packet reliability
participant
NAT device C
three remaining channels
level
data
gateway
device account data
self-identifying type field
same network configuration
adults
communication link E
connection
session keys
least expensive channel
matched participants
secondary channel