CN102215121A - 用于建立和利用备份通信信道的装置和方法 - Google Patents
用于建立和利用备份通信信道的装置和方法 Download PDFInfo
- Publication number
- CN102215121A CN102215121A CN2010105520536A CN201010552053A CN102215121A CN 102215121 A CN102215121 A CN 102215121A CN 2010105520536 A CN2010105520536 A CN 2010105520536A CN 201010552053 A CN201010552053 A CN 201010552053A CN 102215121 A CN102215121 A CN 102215121A
- Authority
- CN
- China
- Prior art keywords
- mobile device
- service
- data
- communication channel
- nat
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
描述了一种用于在点对点(“P2P”)网络中建立,维持以及利用备份信道的装置,方法和机器可读介质。例如,在一个实施方式中,每个移动设备可以与一个或多个其他移动设备建立一个主要P2P通信信道。一旦所述主要信道被建立,每个移动设备都可以使用该主要信道交换次要信道连接数据以及可以随后开启与其他移动设备的一个或多个次要P2P通信信道。一旦检测到所述主要P2P通信信道已经故障或者衰落到一个特定阈值(例如,带宽或比特率阈值)以下时,所述次要P2P通信信道中的一个可以自动提升为一个主要P2P通信信道。
Description
本申请要求2010年4月7日申请的标题为“Apparatus and Method forEstablishing and Utilizing Backup Communication Channels”的美国临时申请No.61/321,841的优先权。
当Apple iPhone 4的原型在2010年3月25日被明显的从一个Apple工程师那里被盗走时,在本申请中公开的和要求保护的发明在未经Apple允许的情况下被过早地对公众的公开。本申请所基于的美国优先权申请在被这次明显的盗窃之前尚未提交。
技术领域
本发明一般涉及计算机网络领域。更特别地,本发明涉及一种改进的、用于为移动设备建立和利用备份通信信道的装置和方法。
背景技术
A.网络地址转换(“NAT”)
大型公共网络,例如因特网,经常连接至小型私有网络,例如那些由公司、网络服务提供商、或者甚至个人家庭所持有的。由于其本身的性质,公共网络必须具有一个普遍约定的网络地址的分配,即公共地址。因为各种各样的原因,私有网络的持有者们经常为所述私有网络选择使用私有网络地址,这些地址不是普遍约定分配的一部分。因此,为了来自私有网络的网络传输能够穿越公共网络,需要一些私有/公共网络地址转换(“NAT”)方式。
一个执行NAT操作的设备将从私有网络发出的数据包转变成使之遵从公共网络的寻址方案。特别地,网络地址转换器用它自己的公共地址和已分配的端口号来替换原先的私有地址和端口号。网络地址转换器还改变所接收的发往私有网络上的计算机的数据包,采用预期接收者的正确的私有地址和端口号来替换目标公共地址和端口号。如此处所用的,如果在上下文中是适合的,术语“地址”应当解释为包括地址和端口号,如同本领域技术人员所理解的。
NAT已经在现代网络计算中变得更加普遍。NAT的一个好处就是它减缓了公共网络地址空间的损耗。例如,在因特网上使用的TCP/IP寻址,每个包括四个三位的字符串,因此提供了有限的地址空间。另外,这个地址空间的特定部分为具体用户或用户保留,这进一步消耗了可用地址的实际数目。但是,如果采用NAT,私有网络或者子网络可以使用任意数目的地址,并且仍然仅仅对外提供一个单独的、标准的公共地址。这使得可用地址的数目几乎是无限的,因为理论上,每个私有网络都完全可以使用相同的私有地址。
由于公共网络上的计算机不能确定私有网络上的计算机的实际(即,私有的)网络地址,因此由NAT所提供的一个好处是增加了安全性。这是因为网络地址转换器在公共网络上只提供公共地址。另外,这个公共地址可以对应于私有网络上的任意数目的计算机。
不同的NAT类型采用不同的安全级别。例如,采用“全锥形(full cone)NAT”,一旦内部地址(iAddr:iPort)映射到外部地址(eAddr:ePort),任意外部主机都可以通过向eAddr:ePort发送数据包而向iAddr:iPort发送数据包。采用“限制锥形NAT”,具有hAddr地址的外部主机仅当iAddr:iPort之前曾向hAddr发送过数据包时才可以通过向eAddr:ePort发送数据包而向iAddr:iPort发送数据包。外部主机的端口是不相关的。采用“端口限制锥形NAT”,具有hAddr:hPort地址的外部主机仅当iAddr:iPort之前曾向hAddrr:hPort发送过数据包时才可以通过向eAddr:ePort发送数据包而向iAddr:iPort发送数据包。最后,采用对称NAT,从同一iAddr:iPort到专门的目标IP地址和端口的每个请求被映射到唯一的eAddr:ePort。如果同一内部主机发送数据包到不同的目的地,则使用不同的外部地址和端口映射。只有从内部主机接收到数据包的外部主机才可以向内部主机发送数据包。
B.点对点网络的NAT问题
点对点(“P2P”)运算是指包括下述运算节点的分布式网络结构:所述运算节点使得其部分资源对其他网络参与者是直接可用的。P2P网络中的节点(peer)彼此之间建立直接通信信道并同时作为客户端和服务器,与传统的客户机/服务器模型不同,在后者中,服务器提供资源而客户机消耗资源。
前面所述的NAT操作给P2P连接造成了众多问题。例如,当两个节点中的一个或两个节点位于前面所述的一个或多个NAT类型后面时,在这两个节点之间建立直接连接变得越发困难。由于以下事实:例如Apple iPodAppleApple以及各种其他设备(例如,RIM设备,Palm设备等等)等移动设备会频繁的在具有不同NAT实现方式的网络之间移动,所以这个问题被加剧。例如,Apple iPhoneTM可以在Wi-Fi网络(例如,802.11b,g,n网络),3G网络(例如,通用移动通信***(“UMTS”)网络,高速上行分组接入(“HSUPA”)网络,等等),以及蓝牙网络(被称为个人区域网络(“PANs”))上通信。未来的移动设备可以在另外的通信信道例如WiMAX,高级国际移动通信(“IMT”),以及高级长期演进(“LTE”)上通信,仅以这些为例。
发明内容
描述了用于在点对点(“P2P”)网络中建立、维持以及利用备份信道的装置、方法和机器可读介质。例如,在一个实施方式中,每个移动设备可以与一个或多个其他移动设备建立主要P2P通信信道。一旦主要信道被建立,每个移动设备就可以使用该主要信道交换次要信道的连接数据,并可以随后开启与其他移动设备的一个或多个次要P2P通信信道。在检测到主要P2P通信信道发生了故障或者衰落(degrade)到指定阈值(例如,带宽或比特率阈值)以下时,次要P2P通信信道中的一个可以被自动提升为主要P2P通信信道。
附图说明
根据下文结合附图进行的详细说明可以获得对本发明的更好的了解,其中:
附图1示出了网络结构,其中,一组移动设备和服务在网络上通信。
附图2a-c示出了一个实施方式的连接数据交换(CDX)服务、匹配器服务和/或邀请服务之间的事务。
附图3示出了标签数据结构的实施方式。
附图4示出了由CDX服务执行的方法的实施方式。
附图5示出了由移动设备执行的方法的实施方式。
附图6示出了通过主要和次要通信信道而连接的一组移动设备。
附图7示出了用于在主要和次要通信信道中进行选择的移动设备的一个实施方式。
附图8a-b示出了通过主要和次要信道而连接的一组移动设备和所得的网络拓扑。
附图9示出了用于在主要和次要通信信道之间进行选择的、由计算机实现的方法的一种实施方式。
附图10示出了一种网络架构,其中,一组移动设备和服务(包括目录服务和推送通知服务)在网络上通信。
附图11示出了一个实施方式中的邀请服务,推送通知服务以及连接数据交换(CDX)服务之间的事务。
附图12示出了一个实施方式中的邀请服务,推送通知服务以及中继服务之间的事务。
附图13示出了用于在两个或更多移动设备之间建立中继连接的中继服务的实施方式。
附图14示出了用于确定NAT兼容性的NAT兼容性表的实施方式。
附图15示出了用于为在线应用匹配移动设备的匹配器服务的实施方式。
附图16示出了用于匹配用户/设备的方法的实施方式。
附图17a-d示出了执行用于匹配用户/设备的一系列示例性表更新。
附图18示出了使用不同匹配适合变量来匹配用户/设备的方法。
附图19示出了展示用于各种应用的应用程序接口(API)以及用于与一组服务通信的服务API的框图。
附图20示出了具有用于应用的API、用于与服务通信的游戏后台程序和游戏服务模块的游戏框图的实施方式。
附图21示出了API实现软件组件和API调用软件组件的实施方式。
附图22示出了一个实施方式,其中在操作***,服务和应用之间进行API调用。
附图23示出了一个示例性计算机***架构的实施方式。
附图24示出了另一个示例性计算机***架构的实施方式。
具体实施方式
以下描述的是用于在网络上建立,维持以及利用主要的和/或备份的点对点(“P2P”)通信信道的装置、方法和机器可读介质。还描述了邀请服务和匹配器(matchmaker)服务,分别用于为P2P会话邀请用户和匹配用户。另外,还描述了中继服务,用以允许用户在特定条件下建立中继连接。最后,描述了应用程序框架和相关联的应用程序接口(API),用以允许应用开发者们设计应用,其可以利用在此描述的各种协作的在线特性的优点。
在整个说明书中,为了说明的目的,阐明了大量特别细节以便提供对本发明更全面的理解。但是,对本领域技术人员明了的是,本发明可以不依赖于所述特定细节而实施。在其他情况下,众所周知的结构和设备未被示出或在方框图中示出,以避免模糊本发明的基本原则。
用于有效且安全地交换连接数据的装置和方法
如附图1中所示,在本发明的一个实施方式中实现的总体网络拓扑结构可以分别包括一组“客户端”或“节点”移动运算设备A-D,120-123,它们在网络120上相互通信并与一个或多个服务110-112通信。尽管附图1中示出的显示为一个单独的网络云,但“网络”120可以包括各种不同的组件,包括公共网络,例如因特网以及私有网络,例如Wi-Fi局域网(例如,802.11n家庭无线网络或者无线热点),以太局域网,蜂窝数据网(例如,3G,Edge,等等),以及WiMAX网络,仅仅举几个例子。例如,移动设备A 120可以连接到网络链路125代表的家庭Wi-Fi网络,移动设备B 121可以连接到网络链路126代表的3G网络(例如,通用移动通信***(“UMTS”)网络,高速上行分组接入(“HSUPA”),等等),移动设备C 122可以连接到网络链路127代表的WiMAX网络,以及移动设备D 123可以连接到网络链路128代表的公共Wi-Fi网络。这些移动设备120-123连接所基于的每个本地网络链路125-128可以通过网关和/或NAT设备(未在附图1中示出)耦合至公共网络,例如因特网,从而使得不同移动设备120-123之间能够在公共网络上通信。但是,如果两个移动设备在相同的本地或私有网络上(例如,相同的Wi-Fi网络),则所述两个设备可以直接通过那个本地/私有网络进行通信,绕过公共网络。需要指出的是,当然,本发明的基本原则并不限于任何特定网络类型或网络拓扑集合。
在附图1中示出的移动设备120-123的每一个可以与连接数据交换(connection data exchange,CDX)服务110、匹配器服务111以及邀请服务112进行通信。在一个实施方式中,这些服务110-112可以作为软件在一个或多个实体运算设备(例如服务器)上执行。如附图1中所示的,在一个实施方式中,服务110-112可以在由同一实体(例如,同一数据服务提供商)管理的更大的数据服务100的背景下执行,并且可以被移动设备120-123中的每一个通过网络120访问。数据服务100可以包括连接各种类型服务器和数据库的局域网(例如,基于以太网的LAN)。数据服务100还可以包括一个或多个用于存储数据的存储区域网络(“SAN”)。在一个实施方式中,这些数据库存储和管理与移动设备120-123中的每一个有关并与其他设备的用户有关的数据(例如,用户账户数据、设备账户数据、用户应用数据,等等)。
在一个实施方式中,匹配器服务111可以基于一组指定的条件来使两个或更多个移动设备相匹配以进行协作(collaborative)P2P会话。例如,两个或更多个移动设备的用户可能对玩特定的多玩家游戏感兴趣。在这种情况下,匹配器服务111可以基于一些变量(例如各个玩家的专业水平、各个玩家的年龄、匹配请求的时间、被请求匹配的特定游戏、以及根据具体游戏而不同的各种变量)来识别一组参与该游戏的移动设备。例如但不限于,匹配器服务111可以在进行特定游戏时尝试匹配具有相似专业水平的用户。另外,成年人可以与其他成年人匹配,而儿童可以与其他儿童匹配。此外,匹配器服务111还可以基于接收到各个用户请求的顺序来给这些请求赋予优先度。本发明的基本原则并不限于任何特定的一组匹配准则或者P2P应用的任何特定类型。
如下所详细描述的,响应于匹配请求,匹配器服务111可以与CDX服务110协作,以确保所有匹配的参与者都能以有效且安全的方式接收用于建立P2P会话的必要连接数据。
在一个实施方式中,邀请服务112也对加入协作P2P会话的移动设备进行识别。但是,在邀请服务112的情形下,参与者中的至少一个会被另一个参与者专门识别。例如,移动设备A 120的用户可以专门请求与移动设备B 121的用户的协作会话(例如,利用用户ID或电话号码识别移动设备B)。对于匹配器服务111,响应于邀请请求,邀请服务112可以识别这组参与者并且与CDX服务110协作,以确保所有参与者都能以有效且安全的方式接收用于建立P2P会话的必要连接数据。
如同上面所提到的,在一个实施方式中,CDX服务110可以对于用于在两个或更多个移动设备之间建立P2P会话所需的连接数据作为中心交换点。特别地,响应于移动设备请求,CDX服务的一种实施方式生成NAT穿越(traversal)数据(有时被称为“穿孔”数据),以使外部服务和客户端能够通过每个移动设备的NAT进行通信(即,经过NAT“穿孔”以到达该设备)。例如,在一个实施方式中,CDX服务检测与移动设备通信所需的外部IP地址和端口并且向移动设备提供这些信息。在一个实施方式中,CDX服务也接收和处理由匹配器服务111和邀请服务112所生成的移动设备的列表,并向包含在列表中的每个移动设备有效和安全地分布连接数据(如以下的详细描述)。
在一个实施方式中,通过采用相对轻量级的网络协议(例如用户数据报协议(UDP))套接字,在移动设备和CDX服务110之间进行通信。如本领域技术人员所知晓的,UDP套接字连接不需要握手对话来保证分组(packet)的可靠性、排序或者数据完整性,因此不会像TCP套接字连接那样消耗那么多的分组处理开销。因此,对于回答来自大量客户端的小询问(query)的服务器来说,UDP的轻量级、无状态的性质是有用的。此外,不同于TCP,UDP与分组广播(其中,分组在本地网络上被发送给所有设备)以及多播(multicast,其中,分组在本地网络上被发送给设备的子集)兼容。如上所述,即使可以采用UDP,也可以利用会话密钥对NAT穿越数据进行加密以在CDX服务110上保持安全性。
与CDX服务110采用的低开销和轻量级网络协议不同,在一个实施方式中,移动设备120-123与匹配器服务111以及/或者邀请服务112之间的通信以固有的安全网络协议建立,例如安全超文本传输协议(“HTTPS”),其依赖于加密套接字协议层(“SSL”)或者传输层安全(“TLS”)连接。与这些协议相关的细节对本领域技术人员来说的是熟知的。
附图2a示出了可以由CDX服务器执行的示例性系列事务。当描述CDX服务的实施方式的操作时,下列术语具有以下含义:
连接数据——这是潜在的节点需要与其他节点交换以建立点对点会话的信息。以下描述的是交换该信息的机制的实施方式。
CDX服务器——在一个实施方式中,CDX服务器是经认证的多播反射器,其允许经授权的实体交换任意数据。该数据被称为有效载荷(payload)。
CDX会话——CDX会话是指一组可以通过CDX服务器而互相通信的客户端设备。作为会话一部分的每一个客户端设备被分配CDX标签(ticket)。每个会话具有唯一的CDX会话ID,该ID是大的整数,可以用来识别或者指代单独的会话。
CDX请求——从客户端设备发送至CDX服务器的请求。请求一般包括两部分:CDX标签和有效载荷。在这个实施方式中,有效载荷是由会话密钥加密过的连接数据。
CDX响应——CDX响应是在CDX服务器接收到来自CDX会话的成员的CDX请求时,被“反射”回CDX会话中其他设备的信息。它是通过将有效载荷添加到在给定的CDX请求中使用的CDX标签的CDX标签票根(stub)来构造的。
CDX标签——CDX标签告诉CDX服务器如何将有效载荷发送至CDX会话的成员。在一个实施方式中,采用CDX标签密钥来对其进行“签名”以防止伪造或篡改。如附图3所示,在一个实施方式中,CDX标签包括如下信息:
会话ID301,其在一个实施方式中不被加密或者被打乱。
会话中的参与者数目302,其在一个实施方式中不被加密或者被打乱。
在会话中标签所指的参与者的索引303(其在一个实施方式中不被加密或者被打乱)。
过期时间/日期304,在此之后,标签被认为是无效的(其在一个实施方式中不被加密或者被打乱)。
对于会话中每个参与者的CDX穿孔数据305-306,在一个实施方式中受到用CDX标签密钥进行的加密。
采用CDX标签密钥的消息认证码307,其作为“数字签名”来确保标签是经过认证的。
CDX标签票根——CDX标签的第一部分,减去了CDX穿孔数据以及消息认证码。
有效载荷——这是CDX请求和CDX响应的第二部分。有效载荷是指客户端设备在CDX会话中期望与其他设备进行通信的数据。在这个实施方式中,有效载荷是利用会话密钥加密过的连接数据。在一个实施方式中,CDX服务器不对有效载荷进行解密,而只是让其无改变的通过。
会话密钥——这是客户端用来对连接数据进行加密的密钥。在一个实施方式中,该密钥对CDX服务器而言是未知的。在这个实施方式中,会话密钥由匹配器服务生成,并且连同客户端各自的CDX标签发送给这些客户端。
CDX标签密钥——这是用于创建CDX标签并对其进行“签名”的密钥。只有CDX服务器和生成CDX标签的服务知晓CDX标签密钥,如下所述,该服务可以是匹配器服务和/或邀请服务。
CDX穿孔请求——用于从CDX服务器获得CDX穿孔数据的专门类型的CDX请求。
CDX穿孔数据——这是一种不透明的数据斑,它描述了CDX服务器如何向最初请求它的客户端发送信息。它是通过向CDX服务器发送CDX穿孔请求获得的。CDX穿孔数据必须在能够生成CDX标签之前从CDX会话中的各个客户端设备收集。CDX穿孔数据(有时称为“NAT穿越数据”)可以包括请求设备的公共IP地址和端口。
现在转向附图2a,在一个实施方式中,移动设备A 120和移动设备B 121可以执行协作应用,例如多玩家游戏或者协作聊天会话,这些应用需要与一个或多个其他计算设备的P2P连接。在201a,移动设备A 120向CDX服务器110传送CDX穿孔请求。CDX服务器在202a用CDX穿孔数据作出响应。在一个实施方式中,穿孔数据包括移动设备A的公共IP地址和端口以及/或者穿孔通过移动设备A的NAT所需的任何其他数据(例如,定义了移动设备A的NAT类型的NAT类型数据)。在201b和202b分别对移动设备B执行类似的事务。
然后,在203a和203b,移动设备A和B向匹配器服务发送包括CDX穿孔数据的匹配请求,以及任何附加的匹配准则(在下面描述)。在该阶段,移动设备A和B可以开始构建建立P2P连接所需要的连接数据。例如,这可以通过使用诸如标准的网络连接建立(“ICE”)事务(例如,通过NAT穿越服务)的事务来实现。但是,本发明的根本原则并不限于用于确定连接数据的任何特定机制。
在一个实施方式中,一旦匹配器服务111发现具有匹配的准则的一组客户端设备,它就会生成唯一的CDX会话ID、对于CDX会话中的每个成员而言唯一的CDX标签、以及唯一的会话密钥。在一个实施方式中,匹配器服务111可以使用唯一的CDX标签密钥为CDX标签加密CDX穿孔数据。然后,在204a和204b,匹配器服务可以向移动设备A和B发送它们的CDX标签和会话密钥。
移动设备A接收CDX标签和会话密钥并且使用会话密钥加密它先前确定的连接数据,制作有效载荷。在一个实施方式中,移动设备A通过将构建的有效载荷附加到CDX标签来构建CDX请求。在205a,移动设备A发送CDX请求至CDX服务器110。移动设备B在205b也执行相同的操作并发送请求至CDX服务器。
在206a,CDX服务器110接收CDX请求,检查标签以确保它是有效的和有授权的(例如,基于消息认证码307)。如果CDX标签是无效的,就丢弃所述请求。在一个实施方式中,CDX服务器然后使用CDX标签密钥对包含在CDX标签中的CDX穿孔数据组进行解密。在一个实施方式中,CDX标签密钥可以包括可以与所述标签一起传输的终止时间/日期。CDX服务110以及匹配器服务111可以存储两个(或多个)不同的用于加密/解密的CDX标签密钥-第一个是当前已经激活的以及第二个是在到达第一个的终止时间/日期时将被激活的。一旦接收到标签,CDX服务110就可以读取终止时间/日期来确定使用哪个标签密钥。当CDX标签密钥过期时,CDX服务110和匹配器服务111中的每个都可以生成新的标签密钥(其是在当前标签密钥过期后作为接下来使用的密钥)。在一个实施方式中,CDX服务110和匹配器服务111执行相同的密钥生成算法以保证与两个标签密钥的一致性。例如,诸如那些用于众所周知的RSA SecurID认证机制的技术可用于在固定间隔生成新的认证码。在一个实施方式中,新的CDX标签密钥是按日生成的。但是,本发明的根本原则并不限于任何用于生成CDX标签密钥的具体机制。
如在206B所示,可以为移动设备B执行相同的操作。CDX服务器可以从CDX请求构建CDX响应并且使用CDX穿孔数据发送CDX响应至CDX会话中的参与者(在207a发送至移动设备B以及在207b发送至移动设备A)。
移动设备B从CDX服务器接收CDX响应207a。客户端设备B检查CDX标签票根以确保会话ID可以匹配它自己的CDX标签的会话ID。移动设备B然后可以使用会话密钥解密有效载荷,以生成来自移动设备A的连接数据。移动设备B然后使用来自移动设备A的连接数据开始建立P2P会话的进程。在一个实施方式中,这些包括标准ICE事务。但是,本发明的根本原则并不限于任何用于建立P2P通信的具体机制。
如上所述,在一个实施方式中,移动设备A和B建立安全超文本传输协议(“HTTPS”)会话与匹配器服务111进行通信(例如,采用HTTPS请求/响应事务)并且建立UDP套接字与CDX服务进行通信。匹配请求204a,204b可以包括NAT类型以及先前为每个各自的移动设备确定的穿孔数据(例如,公共IP地址和端口)。在包括多玩家游戏的实施方式中,每个匹配请求可以识别在每个移动设备上的玩家(例如,使用唯一的玩家ID码),每个用户期望玩的游戏,加入游戏的玩家的数目,以及/或者其他与期望游戏相关的变量设置。通过举例的方式,而不是限制,与游戏相关的游戏设置变量可以包括难度级别(例如,简单,普通,困难),用户的年龄(例如,“小于13岁”),游戏的子区域(例如,第2级),以及/或者玩家的专业水平(例如,专家,初始,中级)。如下详细描述的,这些变量有时作为游戏“桶(bucket)”并且通过使用唯一的“桶ID”来进行标识。每个游戏可以包括不同的桶ID集合来识别不同游戏设置变量。
在一个实施方式中,移动设备B在208a和209a发送和应答(acknowledgement)。相似的,移动设备A的应答在208b和209b被发送。如果移动设备A和B的应答在指定的时间段之后还未接收到,则该连接数据207a可以被重新发送至移动设备B 212。CDX服务110或移动设备A 120都可以启动该重传。
附图2b示出了更详细的例子,其中,三个不同的移动设备120-122使用CDX服务和匹配器服务111来协商P2P链路。附图2b还示出了由移动设备120-122用来建立连接的两个另外的服务:用于确定NAT类型的NAT穿越服务291,和用于为每个移动设备确定完整连接数据的NAT穿越服务290(例如,利用ICE连接数据事务)。但是应当注意,不一定要通过彼此分开的服务来遵守本发明的根本原则。例如,在一个替代的实施方式中,由这些服务290-291的每一个所执行的NAT穿越功能可以直接集成在CDX服务110和/或匹配器服务111中。类似的,由两个NAT穿越服务290-291所执行的功能可以集成在一个NAT穿越服务中。总之,在附图2b中示出的分立的具体功能并非本发明的根本原则所必需的。
现在转向附图2b的具体细节,在220,移动设备A向NAT穿越服务291发送NAT类型请求。作为响应,NAT穿越服务291可以采用包括实现一系列事务的各种已知技术来确定由移动设备A使用的NAT类型。例如,NAT穿越服务291可以尝试打开移动设备A的NAT上的不同的IP地址和端口,并通过这些端口使用不同的IP/端口组合与移动设备A进行通信。按这种方式,由移动设备A采用的NAT可以分类为前面描述的NAT类型中的一种(例如,全锥形、限制锥形、端口限制锥形、对称),或者可选的NAT类型。该信息然后被提供给移动设备A 120,如图所示。
在221,移动设备A 120使用CDX服务110启动NAT穿越请求。作为响应,CDX服务110可以读取用于该请求的公共IP地址和公共端口号并且将这个信息发送回移动设备A 120。如上所述,如果设备在NAT后面,它的公共端口和IP地址将分别不同于它的私有端口和IP地址。因此,依赖于所采用的NAT类型,公共IP地址和端口可以用于“穿孔”通过NAT设备,以到达移动设备。
在222,移动设备A 120向匹配器服务111发送匹配请求222。如上所述,在一个实施方式中,移动设备A使用安全超文本传输协议(“HTTPS”)会话与匹配器服务111通信(例如,使用HTTPS请求/响应事务)。匹配请求可以包括NAT类型和先前针对移动设备A 120确定的穿孔数据(例如,公共IP地址和端口)。在涉及多玩家游戏的实施方式中,匹配请求可以识别移动设备上的玩家(例如,使用唯一的玩家ID码)、这些用户希望玩的游戏、加入游戏的玩家的数目、以及/或者其他与所需游戏相关的设置变量(如上参照附图2a所描述的)。
在223-225,为移动设备B 121执行一组与事务220-222相关的事务;在226-228,为移动设备C 122执行一组与事务220-222相关的事务。因此,在事务228之后,匹配器服务111已经为全部三个移动设备120-122接收了匹配请求。在这个具体的例子中,这些匹配请求使得移动设备120-122匹配于特定的协作会话,例如多玩家游戏(例如,这些移动设备的用户可能已经选择了具有相同或相似的变量集合的相同游戏,从而导致由匹配器服务111执行的匹配)。
匹配器服务111使用包括在每个匹配请求中的数据来生成标签A、标签B、标签C,标签A在229被发送至移动设备A;标签B在230被发送至移动设备B;标签C在231被发送至移动设备C。尽管未在附图2b中示出,但匹配器服务111可以利用推送通知服务来分别向移动设备A、B和C推送标签A、B和C(例如,附图11-12中示出的推送通知服务1050)。用于标签A、B和C的标签数据结构的实施方式在上面参照附图3进行描述。
在232,移动设备120与NAT穿越服务290通信以确定它自己的连接数据。在一个实施方式中,这可以包括标准ICE连接数据事务。如先前已经提到的,连接数据可以包括用于移动设备A 120的公共/私有IP地址、端口和NAT类型。
移动设备A 120将它的连接数据附加到标签A,并在233将标签A连同连接数据发送至CDX服务110。在一个实施方式中,CDX服务按照上面所描述的方式处理标签A,并在234将连接数据(可以被加密)发送至移动设备B 121和移动设备C 122。对于这些事务,CDX服务110可以利用标签A所包括的针对移动设备B和C的NAT穿越数据。
在236-238,利用标签B执行一组与事务232-234相关的事务,在238-240,利用标签C执行一组与事务232-234相关的事务。因此,在事务240之后,连接数据已经在每个移动设备120-122之间共享。通过使用连接数据,P2P会话在移动设备A和B之间、移动设备A和C之间、以及移动设备B和C之间建立。
如附图2c所示出的,邀请服务112也可以用于CDX服务110(既可以代替也可以增加到匹配器服务111)。在一个实施方式中,邀请服务112处理针对具有具体移动设备和/或用户的P2P连接的邀请请求。邀请服务112可以作为无状态的服务来实现(即,不固定每个移动设备之间当前事务状态的服务)。
转向这个具体的例子,在250,移动设备A 120向NAT穿越服务291发送NAT类型请求。作为响应,NAT穿越服务291可以使用各种已知的技术用于确定由移动设备A采用的NAT类型(其中的一些已在上面描述)。在251,移动设备A 120使用CDX服务110发起NAT穿越请求。作为响应,CDX服务110可以读取用于该请求的公共IP地址和公共端口号并且将该信息发送回移动设备A 120。如上所述,如果设备在NAT后面,它的公共端口和IP地址将分别不同于它的私有端口和IP地址。因此,取决于所采用的NAT类型,公共Ip地址和端口可以用于穿孔通过NAT设备以到达移动设备。
与匹配器服务的情况一样,在一个实施方式中,每个移动设备使用安全超文本传输协议(“HTTPS”)会话与匹配器服务112进行通信(例如,使用HTTPS请求/响应事务)。
在252,移动设备A 120向邀请服务112发送邀请请求,其包括移动设备A的NAT穿越数据(例如,NAT类型、公共IP地址/端口)。在利用推送通知服务的实施方式中(在下面更详细的描述),邀请请求还可以包括移动设备A的推送令牌。邀请请求252还可以包括用于识别一个或多个其他用户/设备的识别码——在这种情况下是移动设备B 121和C 122的用户。可以使用各种不同的识别码类型。例如,在多玩家游戏的情形下,识别码可以包括针对具体游戏的玩家ID码。在音频/视频聊天会话情形下,识别码可以包括电话号码或唯一ID,该ID用于识别移动设备A的用户的“朋友”列表中的一个或多个用户。
在一个实施方式中,邀请服务112从邀请请求中读取识别码,并在注册数据库(未示出)中执行查找以定位每个移动设备B和C。在一个具体实施方式中,每个移动设备B和C已经在推送服务中注册,以从邀请服务112接收推送通知。这样,在这个实施方式中,邀请服务112使用推送通知服务分别在253和254将邀请请求推送至移动设备B 121和移动设备C 122。与推送通知服务相关的其他细节在下面(参见,例如,附图11-12以及说明书相关部分)以及在上面所提到的推送通知应用中描述。
在一个实施方式中,邀请请求253和254包括图3中示出的以及上述参考附图2a-b描述的标签数据结构。特别地,发送至移动设备B的标签包括用于识别移动设备A和B的已加密列表,发送至移动设备C的标签包括用于识别移动设备A和C的已加密列表。在一个实施方式中,因为邀请服务112可能还没有移动设备B的NAT穿越数据,253处的“标签”可以包括用以识别移动设备B的其他信息。例如,如下文结合利用了中继服务和推送通知服务(参见,例如,附图11-12)的实施方式所述,253处的“标签”可以包括用于移动设备A的NAT穿越数据、设备A的ID码、设备A的推送令牌、设备B的ID码以及用于移动设备B的推送令牌。相同类型的信息可以在254为移动设备A和C提供。
在255,移动设备B可以与NAT穿越服务291通信以确定它的NAT类型,在256,移动设备B可以与CDX服务110通信以确定它的NAT穿越数据(例如,公共IP地址/端口)。在257,移动设备B向邀请服务112发送邀请响应,其包含移动设备A和移动设备B的识别码、NAT穿越数据、以及(如果采用推送通知服务的话)用于移动设备A和B的推送令牌。在258,移动设备B可以通过与NAT穿越服务290通信来获取它的当前连接数据。在259,移动设备B将它的标签(标签B)连同它的当前连接数据发送给CDX服务110。作为响应,CDX服务110按照上面所述的方式处理该标签并将连接数据转发至移动设备A120。
一旦接收到移动设备B的邀请响应,邀请服务112就可以生成用于移动设备A的加密标签并且在260将标签发送至移动设备A。在一个实施方式中,标签包括NAT穿越数据、NAT类型以及用于移动设备A和B的推送令牌(如果采用了推送通知服务的话)。参照附图2c描述的“标签”与用于所描述的关于匹配器服务111的“标签”的数据结构可以相同或不同。例如,与上面描述的生成加密的“标签”不同,邀请服务112可以简单地生成唯一的会话ID以识别每个移动设备的邀请会话。
在261,移动设备A通过与NAT穿越服务290通信获取它当前的连接数据。移动设备A然后可以将它的连接数据添加到标签,并在262将标签以及它的连接数据发送至CDX服务110。CDX服务110按照上面所述的方式处理该标签并且将移动设备A的连接数据转发至移动设备B。最后,在263,移动设备A和B使用所交换的连接数据打开P2P连接。如下所述的,在移动设备A和B的NAT类型不相容的情况下,可以使用中继服务来实现移动设备A和B之间的通信。
在264-272,移动设备C 122与移动设备A可以执行一系列事务来建立P2P连接,如同在255-263中描述移动设备B和A那样。特别的,在264,移动设备C 122与NAT穿越服务291通信以确定它的NAT类型,并在265与CDX服务110通信以确定它的NAT穿越数据(例如,公共IP地址/端口)。在266,移动设备C发送邀请响应,其包含移动设备C以及移动设备A的NAT类型、NAT穿越数据和推送令牌(如果采用了推送通知服务)。在267,移动设备C通过NAT穿越P2P服务290获取它的当前连接数据,在268,移动设备C将它的连接数据附加到标签C并且将标签C发送至CDX服务110。CDX服务110按照上面所述的方式处理该标签并且将移动设备C的连接数据转发至移动设备A120。
在269,移动设备A 120从邀请服务112处接收移动设备C的邀请响应,其包括移动设备A和C的NAT类型、NAT穿越数据以及推送令牌(如果采用了推送服务)。在270,移动设备A从NAT穿越服务290获取它的当前连接数据,将它的当前连接数据附加到标签A,并在271将标签A发送至CDX服务110。作为一种选择,可能不需要事务270,因为移动设备在事务261确定它的连接数据。CDX服务110按照上面所述的方式处理标签A并将移动设备A的连接数据转发至移动设备C。最后,在272,移动设备A和C使用交换过的连接数据建立直接的P2P连接272.
在一个实施方式中,邀请服务112和匹配器服务111可以依赖于推送通知服务(未示出)用于向移动设备推送数据。例如,在附图2c,邀请请求253和254可以通过该推送通知服务推送至移动设备B 121和C 122。类似的,在附图2a,标签A和B可以推送至移动设备A 120和B 121。在一个实施方式中,当移动设备在网络上被激活时,它会将它的推送令牌注册在可由推送通知服务访问的中心注册目录中。在一个实施方式中,该注册目录把受到密码保护的用户ID或者电话号码与推送令牌相关联。如果推送令牌可以在目录中识别,则推送通知服务可以使用推送令牌将通知推送至移动设备。在一个实施方式中,推送通知服务是由本申请的受让人设计、并例如在上文涉及的推送通知服务中进行描述的Apple推送通知服务(“APNS”)。但是应当注意,图2a-c中示出的本发明的实施方式并不必需推送通知服务。例如,CDX服务并不需要推送通知来执行它的操作,如同在此描述的。
附图4示出了一种方法,可以由CDX服务110执行以交换连接数据;附图5示出了一种方法,可由移动设备执行以交换连接数据并建立P2P连接。这些方法的某些方面已经在上面参考附图1-2c进行了描述。尤其是,这些方法可以在图1-2c示出的网络结构的环境中执行,但是它们并不限制于这样的结构。在一个实施方式中,这些方法以程序代码的形式来实现,当其被处理器执行时,可以导致这些方法的操作被执行。当所述程序代码被处理器运行时,其可以存储在例如随机存储器(“RAM”)的计算机可读介质上。处理器可以是通用处理器(例如,CoreTM处理器)或者专用处理器。但是,这些方法也可以通过使用硬件、软件以及固件的任意组合来执行。另外,程序代码可以存储在例如硬盘驱动器、光盘(例如,数字视频盘或者紧致盘)的非易失性存储设备,或者例如闪存设备的非易失性存储器上。
现在转向在附图4中示出的方法,在401,接收针对特别的移动设备——在这个例子中是“移动设备A”——的NAT穿越请求(有时被称作“穿孔”请求)。在402,生成NAT穿越响应并发送至移动设备A。在一个实施方式中,生成NAT穿越响应可以包括确定移动设备A的当前的公共IP地址/端口和/或NAT类型。
随后可以生成用于移动设备A的标签并且通过标签生成实体(例如上面所描述的匹配器服务111或者邀请服务112)来加密。在403,接收为移动设备A生成的标签(“标签A”),其包括NAT穿越数据(用于设备A和一个或多个其他设备)和用于设备A的连接数据。在404,采用信息认证码对该标签进行认证,并且采用与标签产生实体用来对标签进行加密相同的CDX标签密钥对穿孔数据进行解密。如上所提到的,在一个实施方式中,采用与CDX标签密钥相关联的过期时间/日期来识别正确的CDX标签密钥。
在405,提取用于移动设备的NAT穿越数据。在406,使用NAT穿越数据将用于移动设备A的连接数据发送至每个节点。在407,接收来自每个节点的回执。在408如果确定没有从全部节点接收到回执,就在409将移动设备A的连接数据重发至尚未响应的节点。当所有的连接数据都得到回执时,在408中确定,所述方法终止。
在一个实施方式中,可以为包含在P2P事务中的每个节点执行附图4中示出的方法,以确保接收到连接数据的每个节点都需要建立P2P连接。
附图5示出了可以根据本发明的实施方式由移动设备执行的一种方法。在501,发送NAT穿越请求,在502,接收NAT穿越响应。如上所述,包含在响应中的NAT穿越数据可以包括请求设备的公共端口/IP地址。在503,发送包含NAT穿越数据的匹配请求。随后可以生成用于移动设备的标签并且通过例如上面所描述的匹配器服务111或者邀请服务112的标签生成实体来加密。作为对上述标签数据结构的可选方式,匹配器服务111和/或邀请服务112可以利用唯一的会话ID简单地识别每个参与者。
在504,可以接收到标签;在505,用于移动设备的连接数据被附加至标签;并且在506,发送标签和连接数据。在507,接收与一个或多个其他节点建立P2P连接所需的连接数据。在508,接收表明一个或多个其他节点已经接收到在506发送的连接数据的回执。在510,如果没有接收到全部回执,则将连接数据重发至未从其接收到回执的移动设备。如果在509确定接收到全部回执,则在507接收的连接数据被用于与其他移动设备建立P2P会话。
用于建立和利用备份通信信道的装置和方法
目前的移动设备可以在各种不同的通信信道上通信。例如,Apple iPhoneTM可以在Wi-Fi网络(例如,802.11b,g,n网络)、3G网络(例如,通用移动通信***(“UMTS”)网络,高速上行分组接入(“HSUPA”)网络,等等)以及蓝牙网络(被称为个人区域网络(“PAN”))上通信;未来的移动设备可以在其他的通信信道(例如WiMAX,高级国际移动通信(“IMT”),以及高级长期演进(“LTE”))上通信,仅以这些为例。在操作中,现有的移动设备从一组可用的信道中选择一个主要(primary)通信信道。例如,如果有可用的Wi-Fi连接,则移动设备通常被配置为选择Wi-Fi连接;如果Wi-Fi是不可用的,则选择蜂窝数据连接(例如,UTMS连接)。
在本发明的一个实施方式中,一组移动设备采用前述的标准ICE连接数据交换和/或使用连接数据交换技术来首先建立主要点对点(“P2P”)通信信道。移动设备然后可以在该主要信道上交换连接数据以建立一个或多个次要通信信道,如果任何一个主要信道发生故障时,所述次要通信信道被用作备份信道。在一个实施方式中,通过周期性的在这些信道上发送“心跳(heartbeat)”分组,使次要通信信道通过NAT防火墙保持开放。
如在此使用的,通信“信道”指的是两个移动设备之间的全网络路径,通信“链路”指的是在通信路径中采用的一个具体连接。例如,如果移动设备A采用Wi-Fi连接连接至因特网,设备B采用3G连接连接至因特网,则设备A和设备B之间的“信道”是由Wi-Fi链路和3G链路二者限定的;设备A具有Wi-Fi通信“链路”,设备B具有3G通信“链路”。这样,如果设备A从Wi-Fi链路切换至3G链路,则设备A和设备B之间的“信道”就改变了,尽管事实上设备B的3G链路仍然保持不变。
现在参照附图6描述移动设备建立主要和次要通信信道的具体示例。但是应当指出,本发明的根本原则并不限于在附图6中示出的特定通信链路和通信信道的集合。
在附图6中,移动设备A 601能够通过具有NAT设备611的通信链路605和具有NAT设备612的通信链路606连接至网络610(例如,因特网)。类似的,移动设备C 603能够通过具有NAT设备613的通信链路609和具有NAT设备614的通信链路610连接至网络610。仅作为示例而不是限制,通信链路605和609可以是3G通信链路,通信链路606和610可以是Wi-Fi通信链路。
因此,在这个例子中,在移动设备A和移动设备B之间可以建立四个不同的通信信道:第一信道使用链路605和609;第二信道使用链路605和610;第三信道使用链路606和609;第四信道使用链路606和610。在一个实施方式中,移动设备A和B基于优先方案选择这些信道中的一个作为主要通信信道,并将三个剩下的信道选择为备份通信信道。例如,一个优先方案可以是选择具有最大带宽的信道作为主要信道并使用剩余信道作为次要信道。如果两个或更多个信道具有相同的带宽,则该优先方案可以包括选择具便宜的信道(假定用户付费使用一个或多个信道)。可选地,该优先方案也可以是选择最便宜的信道作为主要信道,并且如果每个信道的花费是相同的,则选择具有最大带宽的信道。在满足本发明的根本原则的同时,可以实现各种不同的优先方案。
移动设备A 601和C 603可以使用上述技术来建立主要通信信道(例如,通过借助CDX服务110交换连接数据)。可选地,移动设备601和603可以执行标准网络连接建立(“ICE”)事务来交换连接数据。不管主要信道是如何建立的,一旦建立,移动设备A 601和C 603就可以在主要通信信道上为次要通信信道交换连接数据。例如,如果在附图6中示出的主要通信信道包括通信链路606和通信连路609,则该链路在建立后可以被用来为包括通信链路605和609的次要通信信道交换连接数据。在这个例子中,在主要通信信道上交换的连接数据可以包括用于NAT 611和NAT 613的NAT穿越数据和NAT类型,包括用于每个移动设备的公共和私有IP地址/端口。
在次要通信信道已被建立后,采用心跳分组来使它们保持开放。例如,设备A可以周期性的向设备C发送小的“心跳”分组,以及/或者设备A可以周期性的向设备C发送小的“心跳”分组,以确保用于次要信道的NAT端口保持开放(NAT经常由于休眠(inactivity)而关闭端口)。心跳分组可以是没有有效载荷的UDP分组,但本发明的根本原则并不限于任何具体的分组格式。心跳分组可以是在它们的有效载荷报头具有自我识别类型字段的UDP分组,并且可以包含可选择的附加格式信息,该信息包括但不限于信道的存活时间(time-to-live)值。
如附图7中示出的,每个移动设备601存储并维护数据结构710(例如,表格,文本文件,数据库,等等),该数据结构包括主要和次要通信信道的列表。给每个通信信道提供单独的条目,该条目包括利用那个信道所需要的连接数据(例如,私有/公开IP地址,NAT类型等等),以及那个信道的当前状态(例如,主要,次要1,次要2,等等)。
在一个实施方式中,通信接口701和702被用于分别通过通信链路605和通信链路606进行通信。故障检测模块705可以在移动设备601上执行,以检测何时特定通信接口/链路发生了故障或者已经衰落到指定阈值以下。作为响应,链路管理模块706可以读取主要/次要连接数据710,以将具有最高优先级的次要信道提升为主要信道。次要信道的优先度可以采用与上述用于主要信道的相同的准则来实现(例如,基于带宽、成本、可靠性,等等)。一旦选择了次要信道,链路管理模块706可以向其他移动设备上的链路管理模块发送链路故障指示,指令那些设备将该次要通信信道提升为主要通信信道。那些设备然后会开始使用与所选择的主要信道相关联的连接数据。
在一个实施方式中,并不需要主要通信信道发生彻底的“故障”才强制切换至次要通信信道。例如,在一个实施方式中,如果主要通信信道足够衰落(例如,低于特定的带宽、比特率或者可靠性阈值),则可以如上所述实现切换至次要信道。在一个实施方式中,切换至次要信道仅在次要信道能够支持比当前的主要信道更好的性能(例如,带宽、比特率或可靠性)时才被执行。
附图8a示出了与在附图6中示出的相同的网络配置,所增加的移动设备B602直接连接至网络610并通过私有网络连接620而连接至移动设备C 603。私有网络620例如可以是介于设备B 602和设备C 603之间的蓝牙PAN链路。从这个例子中可以看到,从主要信道切换至次要信道可以显著地改变网络拓扑。例如,如同在附图8b中示出的,如果用于移动设备的主要信道801包括链路609(导致设备A、B和C之间的直接连接),并且次要信道包括私有网络620,则网络拓扑可以改变为如附图8c所示出的,因为设备A和C使用私有网络通信的唯一方式是通过设备B。尽管这只是具有三个设备的简单例子,但也可以使用数目多得多的设备,当在主要和次要通信信道之间切换时会导致各种不同的网络拓扑结构。
在附图8中示出了用于建立和保持次要信道的方法的一个实施方式。在一个实施方式中,该方法可以由各个移动设备上的链路管理模块706来执行。但是,该方法并不限于任何特定的设备配置。
在901,选择主要P2P通信信道。如上所述,主要信道可以基于预定的优先方案来选择。例如,某些通信信道类型可以优先于其他通信信道类型。信道也可以基于变量(例如带宽、使用成本和/或可靠性)而有优先度。
在902,建立备份P2P通信信道。在一个实施方式中,这是通过经过主要通信信道而在所有移动设备之间共享连接数据来实现的。在903,备份信道被保持。在一个实施方式中,这包括周期性的通过该次要信道传输数据(例如,以周期性心跳分组的形式)。
在904,如果主要P2P信道发生故障(例如,由于特定移动设备的通信链路掉线或者该移动设备离开该通信链路的范围),则在905,这些移动设备将具有最高优先级的备份信道提升为主要信道。在一个实施方式中,这包括由具有故障链路的移动设备在次要信道上将它的链路故障的通知发送到其他设备。最后,在906,使该备份信道成为主要信道,处理过程回到902(其中,任何附加的备份信道可以被发现并添加至所述优先方案)。
邀请服务用于建立点对点(P2P)通信信道的装置和方法
如附图10所示,除了CDX服务110,匹配器服务111和邀请服务112(它们的一些实施方式如上所述),本发明的一个实施方式可以包括注册/目录服务1052、推送通知服务1050以及中继服务1051。如上面所提到的,在一个实施方式中,邀请服务112和/或匹配器服务111可以使用注册/目录服务1052识别经注册的移动设备并使用推送通知服务1050向这些移动设备推送数据。在一个实施方式中,当移动设备在网络上被激活时,它将“推送令牌”(在推送通知服务中有时称为“通知服务账户标识符”)对由注册/目录服务1052维护的数据库进行注册,这是通过将推送令牌关联于受到密码保护的用户ID或者电话号码来实现的。如果推送令牌在注册目录中被识别(例如,通过利用用户ID执行询问),则推送通知服务1050可以使用推送令牌将推送通知发送到移动设备。在一个实施方式中,推送通知服务是由本申请的受让人设计、并例如在上面所涉及的推送通知应用中进行了描述的Apple推送通知服务(“APNS”)。
附图11示出了本发明的一个实施方式,其中,推送通知服务1051被用于在两个移动设备之间建立直接P2P连接,附图12示出了通过中继服务1051建立P2P连接的实施方式。如下文所述,对于是否使用中继服务1051来建立P2P连接的决定可以基于在这些移动设备之间建立直接P2P连接的可行性(例如,基于NAT兼容性问题)。
现在转向附图11,在1101,移动设备A 120发送邀请给移动设备B 121,来邀请移动设备B到P2P通信会话(例如,协作视频游戏、P2P视频聊天等)。在一个实施方式中,该邀请包括用户ID码,该用户ID码在特定在线应用的环境中识别移动设备B 121(和/或移动设备B的用户)。例如,用户ID码可以是用于特定的多玩家P2P游戏的玩家ID,并可以采用例如通用唯一标识符(UUID)的形式。可选地,在一些实施方式中,ID码可以是移动设备B 121的电话号码。游戏ID码可用于对移动设备A邀请移动设备B加入的多玩家游戏进行识别。桶ID可用于识别用于那个游戏的配置(如本申请中针对匹配器服务所述)。
邀请1101还可以包括用于识别移动设备A 120的ID码和关联于移动设备A的NAT穿越/连接数据(例如,用于移动设备A的公共/私有IP地址和端口,以及用于设备A的NAT设备的NAT类型)。NAT穿越/连接数据或者NAT类型可以由移动设备A在邀请请求1101之前已经确定(例如,通过NAT穿越、NAT类型以及连接数据事务,例如上面参照附图2a-c所描述的)。如上所述,邀请请求1101可以采取HTTPS请求的形式。另外,为了更高的安全性,邀请请求1101可以包括由预先指定的认证授权方(authority)签名的客户端认证。
不管用于识别移动设备B的ID码的特定类型如何,ID码由邀请服务112接收,在1102,邀请服务112可以在目录服务1052(未在附图11中示出)中执行查找以识别出通知服务账户标识符,该标识符例如用于向移动设备B推送通知的推送令牌(“推送令牌B”)。在一个实施方式中,查找操作可以执行几个检查以确定该邀请是否应当被允许。首先,它可以确定用于设备A的识别码(“ID-A”)和设备A的推送令牌(推送令牌A)在目录服务数据库中是已注册的关联关系。查找操作1102还可以确认移动设备A的用户被允许邀请移动设备B的用户(例如,移动设备B的用户可以指定只有注册为B的朋友的那些其他用户才能邀请B;或者,也可以指定任何邀请都是不允许的)。在一个实施方式中,如果这些检查中的任一者失败,则邀请被取消,邀请服务112向移动设备A返回错误。
虽然在这个实施方式中描述了“推送令牌”,但应当注意,本发明的根本原则并不限于使用“推送令牌”或者其他任何用于认证和向移动设备推送通知的特定数据结构。
在一个实施方式中,在推送令牌被识别之后,邀请服务112可以生成安全的一次性“会话令牌”,该令牌被赋予该邀请会话并用于在全部的进一步事务中标识该会话。该会话令牌的拷贝然后被发送回移动设备A 120并与该邀请请求一起发送至移动设备B。在一个实施方式中,该会话令牌与前面所述的标签数据结构一起使用,而在另一个实施方式中,只使用会话令牌。
在1103,邀请服务112向推送通知服务1050发送推送请求。在一个实施方式中,推送请求可以包括用于移动设备A的NAT穿越数据、设备A的ID码、推送令牌A、设备B的ID码以及推送令牌B。在一个实施方式中,这些信息可以被封装在“标签”数据结构中并且如上所述受到加密。在另一实施方式中,数据简单地与邀请会话ID一起被发送。
因为这个例子中的移动设备B 121已经对推送通知服务1050进行了注册,在1104,推送通知服务1050能够定位并向移动设备B 121推送邀请请求。所推送的邀请1104可以包括会话令牌、移动设备A的NAT穿越数据/连接数据、移动设备B的ID码。响应于该邀请请求,移动设备B可以通过如上所述对NAT穿越服务或者CDX服务110进行调用来确定它的网络信息(例如NAT穿越/连接数据、NAT类型等)。
在1105,移动设备B接受该邀请。接受(1105)可以采用对邀请服务112的HTTPS调用的形式,并可以包括由预先指定的认证授权方签名的客户端认证(上文涉及邀请请求时提及)。在一个实施方式中,接受(1105)可以包括用于移动设备A和B的ID码,以及用于移动设备A和B的NAT穿越/连接数据和/或NAT类型。接受(1105)还可以包括用于移动设备A和B的推送令牌和/或会话令牌。在一个实施方式中,接受(1105)还可以包含这样的指示:即关于它是否是来自此前发生故障的直接连接尝试的重试。但是,在另一个实施方式中,接受(1105)不包括该重试指示。而是,在检测到发生故障的P2P连接尝试时,两个移动设备中的一个可以发送专门的“中继邀请”至邀请服务112。作为响应,该服务可以直接发起下文参照附图12(开始于1201)描述的一系列中继事务。
在1106,邀请服务112可以执行兼容性检查,以确定移动设备A和B之间的直接P2P连接是否可行。例如,在一个实施方式中,如果从移动设备B接收的接受(1105)表明它是来自此前发生故障的直接连接尝试(或者来自指定数目个此前发生故障的直接连接尝试)的重试,则邀请服务可以得出结论:直接P2P连接是不可行的。邀请服务112可以比较用于移动设备A和B的NAT类型数据,以确定移动设备A和B的NAT设备是否支持直接P2P连接。已知一些NAT类型的组合对建立P2P连接是不兼容的。例如,全锥形NAT可以用来与除了关闭的/带防火墙的NAT之外的其他任何NAT类型建立直接P2P连接。相比之下,对称NAT只能用来与全锥形NAT建立直接P2P连接。在本发明的一个实施方式中组合各种NAT类型的可行性在附图14中示出的NAT兼容性表格1400中阐明,其中,各列代表一个移动设备(例如,移动设备A)的NAT类型,各行代表另一个移动设备(例如,移动设备B)的NAT类型。单元中的“1.0”表示相关联的行和列的NAT类型是兼容的,“0.0”表示这些NAT类型是不兼容的。
在一个实施方式中,如果兼容性检查1106确定直接P2P连接是不可行的,则邀请服务112可以发送中继查找请求1201,如下面参照附图12所述的。但是如果兼容性检查1106确定直接P2P连接是可行的,则邀请服务112可以发送推送请求1107到推送通知服务1050,该请求包含了移动设备B对移动设备A的请求的接受。推送请求1107以及随后从推送通知服务1050到移动设备A的推送通信1108可以包括会话令牌以及两个移动设备A和B的推送令牌、ID码和/或NAT穿越/连接数据。在一个实施方式中,该信息可以封装在上述(参见,例如附图2a-c以及说明书相关部分)的“标签”数据结构中,并可以采用唯一的密钥进行加密。可选地,该信息也可以简单地与唯一的邀请会话ID一起被发送。邀请服务1050还可以通知移动设备B:将要尝试直接连接。
在这个阶段,移动设备A和B具有足够的信息来建立直接P2P连接。在一个实施方式中,这是通过采用上面所述的CDX服务110来实现的。例如,移动设备B将它的连接数据附加到标签B,并在1109将标签B(与连接数据)发送至CDX服务。在即将进行该项事务之前,移动设备B可以实现事务(例如图2b中示出的事务235)以确保它的连接数据是当前的。CDX服务110然后对标签进行认证(例如,采用如上所述的唯一会话密钥),提取移动设备B的连接数据,并且在1110将该连接数据转发至移动设备A。类似的,移动设备A将它的连接数据附加到标签A,并在1111将标签A(与连接数据)发送至CDX服务110。在即将进行该项事务之前,移动设备A可以执行事务(例如图2b中示出的事务232)以确保它的连接数据是当前的。CDX服务110然后对标签进行认证(例如,采用如上所述的唯一会话密钥),提取移动设备A的连接数据,并且在1112将该连接数据转发至移动设备B。最后,在1113,移动设备A和B采用所交换的连接数据进入直接P2P连接。
现在转向附图12,如果兼容性检查1106确定直接P2P连接是不可行的,则邀请服务112可以向中继服务1051发送中继查找请求1201,以确定要由各个移动设备使用的中继主机。该请求1201可以包含用于移动设备A和B的网络信息(例如,NAT穿越/连接数据和/或NAT类型数据),该信息由中继服务1051用来给两个移动设备选择合适的中继主机。如附图13中示出的,中继服务1051的一个实施方式包括多个中继主机1302-1303,并包括中继主机数据库1301,该数据库包含有与这些中继主机中每一者有关的网络信息。邀请服务112向中继查找服务1300发送中继查找请求1201,所述请求使用用于移动设备A和B的网络信息询问中继主机数据库1301。在接收到数据库结果时,中继查找服务1300提供响应1202,该响应标识了所选择的中继主机1302-1303。
在一个实施方式中,中继查找响应1202包含由中继服务生成的中继令牌,以及要由移动设备A和B用于中继连接的中继主机1302-1303的网络地址(IP地址/端口)。在一个实施方式中,中继令牌与中继会话相关联,并且由中继主机1302-1303用于在连接到中继服务1051时对移动设备A和B进行认证。令牌可以采取各种形式,这些形式例如包括:唯一的ID中继会话ID码、数字证书和/或与中继会话相关联的唯一加密密钥。
在1203,邀请服务向移动设备B 121发送中继响应1203,其包含将要建立中继连接的指示。在一个实施方式中,中继响应1203可以包括用于中继主机B1303的中继令牌和网络信息。在一个实施方式中,响应1203可以直接被发送至移动设备B(绕开推送通知服务1050),因为它将响应于对移动设备B的接受(1105)而被发送。
邀请服务112向移动设备A发送中继响应1204,其可以包括用于中继主机B 1303的中继令牌和网络信息。在该情形中,该响应1204在事务1205被通过推送通知服务1050推送至移动设备A。
在1206,移动设备A 120使用用于中继主机A 1302的网络信息建立与中继服务1051的连接。类似地,在1207,移动设备B 121使用用于中继主机B 1303的网络信息建立与中继服务1051的连接。在这些事务中的每一个中,在移动设备A和B的任何NAT防火墙上打开了新的孔,用于移动设备A和B的NAT穿越/连接数据可以由中继服务1051确定并分别返回移动设备A和B(例如,通过确定用于这些设备的公共IP/端口)。在一个实施方式中,中继服务1051和移动设备A和B实现采用中继的NAT穿越(Traversal Using Relay NAT,“TURN”)协议,如本领域技术人员所知,该协议允许位于NAT或者防火墙后面的要素通过TCP或者UDP连接而接收到来的数据。
在1208,移动设备A向邀请服务112发送中继更新,该中继更新在1209被转发至推送通知服务并在1210被推送至移动设备B。类似的,在1211,移动设备B向邀请服务112发送中继更新,该更新在1212被转发至推送通知服务并在1213被推送至移动设备A。由移动设备A发送的中继更新可以包括会话令牌、每个设备的ID码、由1206和1207的中继确定的NAT穿越/连接数据(即,移动设备A向移动设备B发送它的NAT穿越/连接数据,反之亦然)。在一个实施方式中,执行中继更新操作是因为每个移动设备的NAT信息可能改变。
最后,在1214和1215,移动设备A和B分别通过中继服务1051建立P2P连接。在一个实施方式中,当移动设备A向中继服务1051发送移动设备B的NAT穿越/连接数据时,中继连接被建立,反之亦然,从而允许中继服务确定至每个节点的中继主机1302-1303的正确路径。
通过使用前述的技术,邀请服务112可以作为无状态服务来实现,无状态服务即使在具有大量移动设备的大规模***中也具有固有的可伸缩性和弹性。例如,由于推送通知服务1050固有地能够对注册的移动设备进行定位并向其推送内容,邀请服务不需要跟踪每个设备的当前位置。另外,由于设备可以通过每个请求和响应发送全部会话状态数据,所以邀请服务不需要维护任何每个连接(per-connection)状态信息,从而降低了邀请服务的存储和处理需求。这样的实现方式在大规模***中是特别有用的。
用于为在线会话匹配用户的***和方法
如附图15中所示的,一种实施方式的匹配器服务111可以包括:匹配调度器1501,用于接收匹配请求和向移动设备120-122推送匹配响应;数据库1512,用于在请求表格1502存储匹配请求以及在可匹配设置标识符(“MST”)表格1503中存储可匹配设置数据;一个或多个匹配器1510,用于从数据库1512取得匹配请求、执行匹配操作并将匹配结果存储回数据库1512。但是应当注意,本发明的根本原则并不限于如附图15示出的具体结构。
在一个实施方式中,匹配调度器1501作为至匹配器服务111的接口,从移动设备120-122接收请求,将这些请求翻译成命令以把这些请求存储在数据库1512中,从数据库1512读取匹配结果,并将这些结果翻译并传送给移动设备120-122。
在操作中,当新的匹配请求到达时,匹配调度器1501可以在请求表1502的一行中存储该请求。在一个实施方式中,调度器1501向每个匹配请求分配请求ID(“RID”)码,该码在图15中简单的表示为“A”,“B”和“C”(分别对应移动设备A,B和C)。尽管为了简单起见而在图15中采用字母指示方式,但RID码也可以是字符串、整数或者任何其他可用于在数据库中追踪匹配请求的变量类型。
每个匹配请求可以被分配存储在请求表格1502中的可匹配设置标识符(“MST”)值。在一个实施方式中,MSI可以识别匹配所请求的具体应用和/或用于那个应用的配置参数。例如,12:4的MSI值可以用标识符“12”来标识特定的多玩家游戏,并可以用标识符“4”来标识用于该游戏的具体配置。更特别的,该ID码12可以识别特定的多玩家竞速游戏,ID码4可以指定用于该竞速游戏的具体轨道、速度或者玩家经验等级。在一个实施方式中,应用的开发者可以选用以这种方式使用MSI值来指定任何应用配置参数。在一个实施方式中,应用开发者不是直接指定MSI,而是指定游戏ID(用于识别特定的游戏)和桶ID(用于识别特定的游戏配置),并且由匹配调度器1501把这些值映射到MSI。
另外,可以在单独的MSI中使用一些不同的MSI值来指定多个不同的配置参数(例如,12:4:1可以表示:12=竞速游戏;4=轨道;1=经验等级)。如下所详细描述的,在一个实施方式中,由匹配器1510使用每个MSI来识别一组匹配请求,其中可以执行匹配操作(例如,分组是基于MSI对请求进行分组,每个MSI组中执行匹配)。在一个实施方式中,由调度器可以动态的更改/选择每个MSI以包括用于识别不同机器分区的分区ID。例如,如果特定的MSI过载,则调度器可以将MSI分割在两个或更多个不同服务器和/或存储分区之间(例如,使用例如4:3:1和4:3:2的指示,其中最后一位数分别识别分区1和2)。不同的匹配器接着独立的获取和处理来自每个不同MSI的请求,该MSI来自每个不同的服务器。
如附图15中示出的,匹配请求数据还可以存储在用于每个请求的请求表1502中。请求数据可以包括任何可用于提供匹配器决定的数据以及/或者任何访问移动设备通过网络发起请求所需要的数据。例如,在一个实施方式中,用于每个请求的匹配请求数据包括用于移动设备发起请求的NAT类型数据和/或NAT穿越/连接数据。请求数据的其他类型也可以被存储在请求表1502中,例如设备连接速度(100kbps、1Mbps等等)、连接类型(例如3G、EDGE、WIFI等等)、设备位置(例如可由地理定位技术确定)、语言(英语、西班牙语等等)和/或用户喜好。请求数据可以由每个移动设备120-122确定并连同每个匹配请求一块发送至匹配调度器1501。例如,每个移动设备可以采用各种技术确定它的连接数据、连接类型、设备位置等等,其中一些技术在本申请中进行了描述(例如,与NAT穿越服务器通信以确定NAT穿越/连接数据、使用GPS来确定设备位置、读取HTFP信息以确定语言等等)。
如附图15中示出的,在一个实施方式中,每个激活的MSI可以在MSI表1503中被分配一行。在一个实施方式中,当新的请求到达时,除了将该请求添加至请求表1502,调度器1501还检查MSI表1503以确定针对该请求是否已有MSI存在(即,是否已经接收了具有相同MSI的其他请求)。如果未发现匹配的MSI,则调度器1501可以在MSI表1503中为该新的请求创建新的条目。如果发现匹配的MSI,则调度器可以如上所述简单地将该新的请求添加至请求表1502中。
一旦请求表1502和MSI表1503由匹配调度器1501更新,匹配器模块1510(以下简称为“匹配器1510”)的实例获取数据以执行匹配操作。多个匹配器实例可以被同时执行以执行匹配请求,也可以由一个匹配器1510对多个不同的MSI分组同时处理多个匹配操作。
在一个实施方式中,当匹配器1510可用时(例如,在完成用于MSI组的匹配操作之后或者在初始化之后),它询问MSI表1503以识别新的MSI来处理。在附图15,匹配器ID区域中对于MSI 3:1的“N/A”值表示处理该MSI的责任尚未分配给匹配器。在一个实施方式中,每个MSI条目都有时间戳,匹配器1510选择具有最早时间戳的MSI。
在一个实施方式中,当匹配器1510对特定的MSI承担责任时,它在MSI表1503中更新其匹配器ID码,并指定用于该MSI的出租(lease)期限(例如,5秒)。在一个实施方式中,匹配器1510随着它处理用于该MSI的匹配而持续更新出租期限值。出租期限值可用于对分配给发生故障的匹配器1510的MSI进行识别。例如,如果出租期限已经过期,则即使MSI表1503表明MSI已被分配给匹配器,该MSI也可以被新的匹配器要求。
一旦匹配器1510对MSI已经承担责任,它可以询问请求表1502来将与该MSI相关的请求读入存储器。然后匹配器1510可以根据一组匹配准则(例如,如下所述的)来执行匹配操作以将用户和移动设备匹配。匹配器1510可以更新请求表1512以指示匹配移动设备何时已经进行。例如,匹配器可以在请求表1512的列中移除MSI值,并输入预定的值以指示匹配已经完成。另外,匹配器1510可以为每个参与者更新“请求数据”字段以识别与该参与者匹配的其他参与者(例如,通过写入与其他参与者通信所需的NAT穿越/连接数据)。
调度器1501可以周期性的询问请求表1502以识别完成的匹配。作为对检测到已完成匹配的响应,该调度器1501可以发送推送通知到参与到该匹配的移动设备(采用在此描述的推送通知技术和在共同再审的那些申请中的推送通知技术)。在一个实施方式中,推送通知包括上述的“标签”数据结构。该移动设备然后可以如上所述通过CDX服务110使用它们的每个标签来交换连接数据。
除了使用推送通知,在一个实施方式中,移动设备120-122可以周期性的询问调度器1501以确定是否已经进行匹配。周期性的询问在推送通知还没有被送达移动设备的情况下是非常有用的。但是,因为使用了推送结构,周期性的询问可以设置为相对较低的速率,因此可以降低匹配服务111上的负载。
附图16示出了一个方法的典型实施方式,其中两个移动设备A和B由匹配服务111匹配。附图17a-d示出了对请求表1502以及MSI表1503的示例性更新,这可能随着该方法的前进而发生。
在1601,从移动设备A接收匹配请求。在1602,移动设备A的请求被输入请求表,新的MSI条目(MSI 1:1)被输入MSI表(如果尚未存在该条目),如附图17a中所示。在1603,从移动设备B接收匹配请求,在1604,移动设备B的匹配请求如附图17b所示也被输入请求表。
在1605,一个具体的匹配器实例(匹配器#N)检查MSI表并检测到MSI 1:1尚未被另一个匹配器实例所要求。可选地,匹配器可以检测租期已过的MSI表的条目,表明此前在该MSI上工作的匹配器已经故障了。在一个实施方式中,具有租期已过的MSI条目被给予比新的MSI条目(尚未被分配给匹配器)更高的优先级。另外,在一个实施方式中,相对较早的MSI条目可以被给予比相对较新的MSI条目更高的优先级。不管匹配器如何选择MSI,当它选择后,它会添加它的标识符并为MSI条目设定新的租期值,如附图17c中所示的(例如,在示出的例子中采用5秒的租期值)。匹配器然后可以询问请求表并将具有那个MSI的请求表条目读入存储器,以便可以对它们进行处理。
在1606,匹配器执行一系列匹配操作来为每个请求选择合适的匹配。匹配操作的某些实施方式在下面参照附图18进行描述。简言之,在一个实施方式中,为了确定“合适的”匹配而受到估计的变量包括NAT类型(例如全锥形、端口限制的、对称的等等)、连接类型(例如WIFI、3G、Edge等等)、与用户相关联的语言(得自HTTP请求的accept-language(接受语言)头部)、每个匹配请求的时效(age)。一般的,匹配器1510可以尝试匹配具有可兼容的NAT类型(尽管如下所述有时可以使用中继服务)、相同连接类型以及相同语言的移动设备。在一个实施方式中,对基于匹配请求时效的匹配请求,匹配器1510可能是更自由的(即,请求越早,要应用的匹配约束就越自由)。
转回附图16,在1607,在匹配决定之后,匹配器1510可以更新请求表以表明匹配已经完成,如附图17d所示。作为更新的一部分,匹配器还可以更新用于移动设备A和B的请求数据。例如,在一个实施方式中,匹配器1510在用于移动设备A的请求数据列中写入移动设备B的NAT穿越/连接数据并在用于移动设备B的请求数据列中写入移动设备A的NAT穿越/连接数据。
在1608,调度器1501可以从头到尾的读取请求表以识别已经被匹配的请求条目。在一个实施方式中,当其检测到移动设备A和B已经被匹配,就读取请求数据(如上所述由匹配器更新),并生成用于移动设备A和B的通知。在一个实施方式中,所述通知是上面所述的“标签”数据结构,其被加密且包括用于每个移动设备的NAT穿越/连接数据。如前所述,在一个实施方式中,使用推送通知服务1050向移动设备A和B推送通知。另外,移动设备A和B可以周期性的轮询(poll)调度器1501以确定是否已经进行了匹配。在这个实施方式中,轮询技术可以在相对较慢的速率下进行以便对于因为某种原因而没有被成功推送到移动设备的匹配进行识别。采用推送通知来管理轮询请求负载显著地降低了匹配服务111上的负载,否则该服务可能加载来自移动设备的轮询请求。
对于同一MSI,如果在1608中确定有其他的匹配请求在搁置(pending),则匹配器可以在MSI中继续匹配移动设备/用户。在1610,匹配器可以在MSI表1503中重新设定租期值。在1611,执行其他的匹配并更新请求表(如上所述)。在1612,从请求表中读取这些其他的匹配并更新另外的移动设备(如上所述)。如果对于该MSI没有另外的匹配请求搁置,则在1609,从MSI表中移除该MSI条目(例如,通过来自调度器或者匹配器的删除命令)。
附图18的实施方式示出了用于执行移动设备/用户之间的匹配的方法(附图16中的操作1606)。在1801,所有的当前MSI请求(例如,对特定的应用/桶的组合)被配置成对。在1802,评估每对之间的匹配“适合度”,并在1803按照适合度降序存储这些对。“适合度”的评估基于多种不同变量,包括但不限于NAT类型(例如全锥形、端口限制的、对称的等等)、连接类型(例如WIFI、3G、Edge等等)、与用户相关联的语言(得自HTTP请求的accept-language头部)、每个匹配请求的时效。进入匹配决定可以考虑的其他变量包括:各个移动设备的位置(例如,通过对特定位置的用户进行匹配的尝试);最小的和/或最大的玩家需求(例如,由用户和/或应用指定);包括在MSI中的这一个或多个用户是否是“朋友”或者此前已经进入过P2P连接(例如,优先匹配“朋友”或熟人);用户对于该应用的经验(例如,对于多玩家游戏,每个用户的排行榜等级可以被考虑进来,优先匹配具有相似经验的用户)。
如下面在表A中指示的,在一个实施方式中,对“适合度”的评估是介于0.0和1.0之间的数字值。采用浮点值允许对每个标准的适合度进行归一化。为避免浮点运算,可以将非归一化的整数值用于合适的计算,从而可以比较适合度。
在一个实施方式中,所有的标准都有二进制的适合度,其中它们是可兼容的(具有为1.0的归一化值)或者不兼容的(具有小于1.0的归一化值)。这些可以看作所需要的标准,其中适合度可以随时效而变化(如下所述)。如果位置被添加为变量,则最好的适合度可能是与可以满足所需准则的最近玩家之间的适合度。
匹配适合度——表A
因素 | 权重 | 归一化 |
NAT兼容性 | 2.0 | 0.4 |
连接类型 | 2.0 | 0.4 |
语言 | 1.0 | 0.2 |
全部 | 5.0 | 1.0 |
在一个实施方式中,对于每个上述准则,适合度等于(归一化权重*时效化的因素值)的总和。时效化的因素值可以最初为1并且在经过了预定时间段后增大。它可以随着时间的流逝继续增大(例如,周期性地增大预定的量)。在一个实施方式中,不是使用上述时效化的因素值,而是可以按照如下所述建立时效阈值。某些变量的归一化/加权值(例如连接数据和语言)可以在某些时效阈值之上被应用(即使它们不匹配)。
在一个实施方式中,一对请求A与B之间的“适合度”是A对于B的适合度和B对于A的适合度的平均值。此外,对于每个因素,A对于B的适合度可以根据A的时效进行调整(反之亦然)。在一个实施方式中,对于兼容性匹配可能需要1.0的适合度。这意味着只有当NAT兼容性、连接类型以及语言匹配时(导致1.0的归一化值)都匹配时,A和B才能匹配,或者如果A和B已经时效化使得上述变量中的一些(例如连接类型和语言)实际上被忽略(使用上述时效化因素值或者下面的阈值)。
时效——表B
时效 | 阈值1 | 阈值2 | 阈值3 | 阈值4 | 阈值5 |
早于 | 0秒 | 1秒 | 5秒 | 10秒 | 30秒 |
可以按照上面表B中提出的方式建立时效阈值。随着各个时效阈值的经过(即,在请求变得比阈值更早时),时效化的因素值可以增大至越来越大的值(例如1.5、2.0等等)。可选地或者另外地,随着不同的时效阈值经过,用于某些变量的权重可以被添加至所述匹配决定(例如,如下所述的连接类型和语言)。
在一个实施方式中,表B中指定的请求时效限制是根据用于给定MSI的匹配流动速率来调整的。在一个实施方式中,流动速率被规定为在每个指定单位时间(例如每10秒钟、每1分钟等等)执行的匹配数目。因此,流动速率提供了关于特定的MSI设定有多繁忙的指示。在一个实施方式中,该设定越繁忙,则上面表B中的每个上述阈值被设定得越低,以提高尽早成功匹配的可能性并降低匹配器的负载。此外,用于给定的MSI设置的负载也可以提供给终端用户(例如以用于匹配的时间的评估值形式),使终端用户可以选择是否尝试进入特别繁忙的多玩家游戏。负载值可以通过推送通知的形式提供给用户。
现在转向表A中的各个变量,在一个实施方式中,NAT兼容性是根据附图14中示出的NAT兼容性图表1400确定的。如果根据这个图表确定两个NAT是兼容的,则可以应用NAT兼容性权重。
连接类型——表C
A/B | WiFi | Edge | 3G |
WiFi | 1.0 | 0.0 | 0.0 |
Edge | 0.0 | 1.0 | 0.0 |
3G | 0.0 | 0.0 | 1.0 |
可以使用例如上述表C所示的图表来评估连接类型。在这个例子中,如果设备A和B的连接类型是相同的(在单元格中指示为1.0即满足相同连接类型),则表A的加权连接类型值可以包括在对适合度的确定中。如上所述,可以采用每个请求的时效来影响连接类型确定。例如,在一个实施方式中,用于连接类型的适合度是使用表C中的矩阵对于阈值1、2、3处的时效进行选择的。对于阈值4或更高阈值的时效,连接类型可以被设定为1.0(即使对于非匹配连接类型),并可以应用相应的加权连接类型。虽然在一些实施方式中使用了连接“类型”,但也可以确定连接速度并且与连接类型一起使用或者代替连接类型。例如,某些指定范围内的连接速度被认为是“兼容的”(例如,0-100kbps、100-500kbps、500-1000kbps、1000-1500kbps等等)。这里讨论的匹配变量中的任一种也可以给匹配适合度计算及如上所述的时效用作权重。
在一个实施方式中,玩家语言可以从HTTP请求的accept-language头部获得,其可以包括一个或多个具有偏好因子的语言。调度器可以提取最偏好的语言并把该信息传送给匹配器。在一个实施方式中,如果是相同的语言,则来自表A的加权语言值被设定为1.0,如果不是相同的语言,则设定为0.0。但是在一个实施方式中,即使语言不同,但如果时效高于指定阈值,也可以应用加权语言值(例如,如果时效处于表B中的阈值2或更高)。
在一个实施方式中,可以在具有不兼容NAT类型的两个用户之间进行匹配。例如,如果匹配器对于具体的MSI难以匹配用户,则在一段指定的时间之后,它可以采用如上所述的技术通过中继服务1051来对连接进行路由。这样,中继服务1051作为压力阀,尽管NAT类型不兼容也允许发生老化的匹配。还可以响应于检测到一个或多个失败的匹配尝试来使用中继服务1051。在这个实施方式中,由移动设备提交的每个匹配请求可以包括对于此前是否已经尝试过一个或多个失败匹配的指示。
可以对各种附加的匹配准则进行评估并向其提供加权值作为匹配适合度确定的一部分,这些准则包括(例如但不限于)对于下述情况的指示:请求了匹配的那些用户中是否有任何人是朋友。例如,通过将“朋友”权重应用在匹配适合度计算中,匹配器1510可以尝试对于作为朋友的那些用户的任何请求进行匹配。类似的,朋友的朋友也可以被加权(例如,相隔2个或更多)。另外,对于特定的游戏,一个玩家可以评价其他玩家,匹配器可以在执行匹配时评估这些评价(倾向于为用户匹配具有相对较高评价的那些玩家而不为用户匹配具有低评价的玩家)。此外,用户连接的等待时间(latency)也可以被评估(例如,采用简单的ping操作)并作为匹配决定的一部分。
另一个用于匹配玩家的变量可以是设备类型。例如,匹配器1510可以尝试匹配具有相似设备类型的玩家(例如iPad、iPod、iTouch、iPhone、RIM Blackberry等等)。另外的变量还可以包括用户的排行榜等级、当前位置、当前住处、年龄、性别,相似的游戏收藏也可以被类似地受到评估以对匹配进行确定(即,在许多情况下,趋向于在具有相似标准的用户之间进行匹配)。最后,家长控制也可以被匹配器1510评估,以确保用户只能与适合的MSI以及相同年龄的其他用户进行匹配。
匹配器服务111可以从由数据服务100(参见,例如,下面参照附图19描述的数据库1920)管理的一个或多个数据库中获取任何上述变量。例如,用户朋友的数据可以从朋友服务数据库访问,其他信息(例如各个用户的年龄、性别、游戏收藏等)可以从一个或多个其他数据库访问(例如用户简档(profile)、游戏数据库、排行榜数据库等)。在一个实施方式中,这里描述的所有服务能够访问同一个中心数据库(或者一组数据库),该数据库存储用于做出匹配决定的各种不同类型的用户/设备数据。
尽管上面提供了一些具体的例子,但是应该意识到,本发明的根本原则并不限于用于确定匹配的适合度的任一组特定类型变量。在一个实施方式中,设计应用在这里所描述的***和方法上运行的程序设计员可以指定他们自己的一组标准,用于对采用不同MSI标准的请求进行匹配和/或分组。
转回附图18的方法,一旦确定每对之间的匹配“适合度”,在1803,采用降序的适合度来给这些对进行排序(例如,具有最高的适合度的那一对位于列表的最顶部)。在1804,具有高于指定阈值的最高适合度的那些对被作为“匹配设置”的种子。如上所述,“阈值”的值可以被设定为归一化值1.0,如上面表A中示出的。在1805,新的预期伙伴被添加至匹配设置,该预期伙伴与匹配设置中的一个或全部当前成员具有高于指定阈值的适合度值。例如,如果匹配设置最初已经以A和B作为种子,则如果A-C和/或B-C的适合度值高于指定阈值,则C可以被添加至匹配设置。在一个实施方式中,如果对于预期方,只有一个匹配适合度高于阈值,则这个预期方可以被添加至匹配设置(即,如果必要,因为这个预期方将能够通过与其具有合适的匹配适合度的一方来与所有其他各方通信)。在一个或多个新的预期方被添加至匹配设置后,如果在1806确定对于匹配的大小需求已经得到满足,则存储匹配结果并在1807进行报告(例如,通过更新请求表1502并如上所述发送通知)。在一个实施方式中,一个匹配请求可以代表多个用户(例如,如后面所述,当匹配请求紧跟在邀请序列之后时)。在这种情况下,基于由每个匹配请求所代表的用户的数目来评估大小需求。如果未满足大小需求,则处理返回1805,并将新的方添加到匹配设置(即,与组中的一个或全部当前成员的匹配适合度高于指定阈值的那方)。
在1808,匹配器1510将匹配过的请求从当前在处理的那组请求中移除。在1809,选择下一个作为种子的匹配设置且进程返回到1804以进行另外的匹配。尽管在附图18中示出的是依次处理,但应当理解,多个作为种子的匹配设置可以被同时处理,同时仍然满足本发明的根本原则。
尽管上面作为独立的服务来描述,但匹配器服务111和邀请服务112也可以一起操作以连接P2P用户。例如,在一个实施方式中,第一用户可以邀请一个或多个朋友到在线会话,并请求与一个或多个另外用户匹配(例如,INVITE(邀请)朋友“Bob”并为多玩家视频游戏匹配3个另外的玩家)。在这种情况下,邀请服务112可以首先处理第一个用户的邀请请求,以将第一用户和第一用户的(一个或多个)朋友连接起来。邀请请求的结果(例如,成功的P2P连接)然后被报告回该用户的移动设备。匹配服务111然后可以接收来自请求了另外玩家的第一用户的移动设备的匹配请求(或者,在一个实施方式中,直接从邀请服务或者从用户的朋友接收)。作为响应,匹配服务111可以将第一用户与一个或多个其他匹配请求进行匹配,所述其他匹配请求具有与第一用户的请求(如上所述的)相同的MSI。匹配请求可以只包括第一用户的匹配准则,或者也可以包括第一用户的以及第一用户的朋友的匹配准则(例如NAT类型、连接类型、语言、位置等)。在一个实施方式中,如果第一用户的朋友中的一个或多个不能与另一个匹配用户建立直接P2P连接,则可以通过第一用户的数据处理设备建立与第一用户的朋友匹配的用户连接(例如,将第一用户的移动装置作为用于连接的代理)和/或可以使用中继服务连接这些用户(如上所述的)。
在一个实施方式中,可以首先由匹配服务将第一用户与一个或多个用户匹配(如上所述的),然后第一用户可以邀请一个或多个朋友加入与第一用户和已匹配用户的在线会话。在这个实施方式中,用户的信息和已匹配用户的信息(例如NAT/连接数据、用户ID、推送令牌等)都可以通过邀请服务与被邀请的用户进行交换(如上所述)。不管是先发生匹配再进行邀请,还是先发生邀请再进行匹配,本发明的根本原则都相同。
用于协作在线应用的具有应用程序接口的应用程序框架
如附图19中所示的,本发明的一个实施方式是在移动设备120的环境中实施的,该移动设备具有预定的软件框架1912,该软件框架具有用于与一个或多个应用1911进行交互的应用程序接口(“API”)1910以及用于与多个网络服务1901-1903进行通信的服务侧API 1910。如附图19所示,网络服务1901-1903可以由相同的在线数据服务100设计和/或管理(但这样的结构不是必须的)。应用1911(例如P2P游戏应用以及其他类型的协作在线应用)可以设计成:通过向API 1910进行调用,经由API 1910来访问网络服务1901-1903。通过使用由框架1912和网络服务1901-1903的开发人员提供的软件开发工具包(“SDK”),可以便于应用1911的设计。框架1912和API 1910、1913的一个更具体的实现方式在下面参照附图20进行描述。
如所示的,每个服务可以访问数据库1920,该数据库用于储存由这些服务所使用的数据。一个特别的例子是由匹配服务111使用的数据库1512(如上所述)。其他的例子可以包括:用于存储排行榜数据的排行榜数据库、用于存储朋友状态记录的朋友服务数据库、用于存储用户简档数据的简档数据库、用于存储与在线游戏有关的数据的游戏数据库。任何类型的数据库都可以使用(例如MySQL、Microsoft SQL等),但是在一个特别的实施方式中,可以使用例如Berkley DB和/或MZBasic DB的密钥/值数据库。数据库可以扩展到存储区域网络(SAN)中的许多海量存储设备(例如硬盘驱动器)上,也可以采用其他存储配置。
因此,当特定的服务如上所述处理和/或存储数据时,数据可以存储在数据库1920中。但是一些服务可以不使用数据库。例如,如上所述,邀请服务112可以作为无状态服务来实现,因此无需在数据库1920中存储数据(但根据本发明的根本原则,这样的实现方式也是可能的)。
API 1913可以被设计通过使用合适的网络协议栈(例如包括位于网络层的TCP/IP或者UDP/IP,以及位于应用层的HTTPS)与网络服务1901-1903进行通信和交换信息。可以使用在HTTP或者HTTPS上的基于远端过程调用(RPC)的协议(例如SOAP)和/或表述性状态转移(REST)协议。此外,这些服务可以在任何计算平台上实现,这些平台例如包括Xserve或者类似的运行Unix、Linux的服务器或者Apache软件平台。在一个具体的实施方式中,平台包括在Linux上实现的网页对象。前述这些例子仅仅是用于说明的目的。本发明的根本原则并不限于用于将应用连接到服务的任何特定机制或者任何特定的网络协议集合。
附图20示出了更详细的软件结构,其包括可以在本发明的一个实施方式中的无线设备120上实施的应用程序接口(API)2001a-b。尽管结合多玩家游戏框架2000的环境来描述该实施方式,但本发明的根本原则并不限于游戏实施方式。例如,在附图20中示出的软件结构可用于支持各种非游戏的协作应用(例如协作聊天、多方协作音频/视频等)。
在附图20所示的结构中,提供了游戏框架2000以支持本申请中描述的各种多方特性和P2P特性。在一个实施方式中,游戏框架2000被设计成运行于移动设备的操作***2005上。例如,如果移动设备120是iPhone、iPad或者iPodTouch,则操作***2005可以是iPhone OS,这是由本申请的受让人设计的移动操作***。
游戏框架2000可以包括公共的应用程序接口(API)2001b以及私有的或“安全”的API 2001a。在一个实施方式中,被设计来提供这里描述的各种游戏相关特性的游戏中心应用2031既可以调用公共API 2001b也可以调用私有API2001a,而其他应用2030(例如,由第三方设计的应用)只能访问公共API 2001b。例如,移动设备120的设计者可能希望将涉及潜在敏感信息的特定API函数保留在公共API 2001b之外,以免被第三方开发人员滥用(例如朋友请求、朋友列表等)。但是,安全API 2001a和公共API 2001b二者可以被合并在能够由移动设备上的任何应用获取的一个API中(即,符合本发明的根本原则并不要求将API划分成分离的公共组件和私有组件)。名称“API 2001”在下面有时会用来指代公共API2001b和/或私有API2001a任一者中可以存在的操作。
一个游戏中心应用2031的实施方式在共同在审的下述申请中进行了描述:标题为“System and Method for Providing a Game Center”,代理人申请案编号为4860.P9127USP1,序列号为61/321,861,2010年4月7日申请,发明人为MarcelVan Os和Mike Lampell(在下文中称为“游戏中心专利申请”),其被转让给给本申请的受让人并通过引用方式结合于此。简言之,游戏中心应用2031包括游戏中心图形用户接口(GUI),用于在多玩家游戏中导航,购买新游戏;获取与游戏相关的信息(例如排行榜信息、成就、朋友信息等);联系朋友进行游戏;请求与其他用户进行游戏匹配;邀请特定的用户。由游戏中心应用2031执行的各种其他功能在上面指出的游戏中心专利申请中进行了描述。游戏中心的一些功能可以由游戏框架2000提供,并可以通过公共API 2001b而由其他应用2030访问。
在一个实施方式中,由游戏框架2000所公开的API 2001简化了为移动设备120设计多玩家协作游戏的过程。尤其是,在一个实施方式中,API 2001允许开发人员进行简单的API调用来为多玩家P2P游戏会话调用连接用户的相对复杂的进程。例如,可以从API 2001中调用简单的API调用(例如INVITE(玩家B ID,桶ID))以启动上述详细的邀请序列。类似地,可以从API 2001中调用API调用(例如MATCH(玩家AID,桶ID))以启动上述详细的匹配序列。这里,INVITE(邀请)和MATCH(匹配)函数有时统称为“P2P连接函数”。在一个实施方式中,游戏框架2000包括作为对这些API调用的响应而对邀请和匹配操作进行管理所需的程序代码(如下更详细的描述)。应当注意,实际的API函数可以具有与前述稍微不同的数据格式(尽管它们可能导致由游戏框架2000执行的相似的操作)。本发明的根本原则并不限于用于指定API函数的任何特定格式。
各种其他类型的与游戏相关的事务和信息也可以由游戏框架2000代表游戏中心2031和其他应用2030来进行管理。这种信息中的一些已在游戏中心专利申请中进行了描述。例如但并不限于,该信息可以包括与那些已经达到每个游戏最高分的用户相关的“排行榜”信息和用于识别谁已经完成特定游戏指定成就的用户的“成就”信息。每个应用开发人员可以指定他们自己对每个游戏应用2030设置的“成就”(例如,完成等级1-3;在5分钟以内完成等级1,每一等级消灭超过50;打倒20面旗帜,等等)。
游戏框架2000还可以包括用于管理用户的朋友数据和用于在游戏中心2031和其他游戏应用2030的环境中整合朋友数据的程序代码。例如,当用户在游戏中心2031内选择一条到特定游戏的链路时,针对该游戏可以显示与该用户的各个朋友相关的信息(例如朋友在排行榜上的等级、朋友的成就、当该用户与他/她的朋友进行游戏时的结果,等等)。在一个实施方式中,游戏框架2000的API 2001包括用于访问由朋友服务管理的朋友数据的函数,例如在下述共同在审的申请中描述的:标题为Apparatus and Method for Efficiently Managing Datain a Social Networking Service,代理人申请案编号为4860.P9240,序列号为61/321848,于2010年4月7日申请,发明人为Amol Pattekar,Jeremy Werner,Patrick Gates,以及Andrew H.Vyrros(下文中称为“朋友服务申请”),其被转让给给本申请的受让人并通过引用方式结合于此。
如附图20中所示的,在一个实施方式中,游戏后台程序(daemon)2020可以对游戏框架2000与第一组服务2050进行接口,游戏服务组件2010可以对游戏框架2000与第二组服务2051进行接口。例如,第一组服务2050可以包括前述的邀请服务112、匹配服务111和中继服务1051,以及上述朋友服务申请中描述的朋友服务。可以通过游戏后台程序2020而访问的其它服务包括:排行榜服务(提供排行榜数据);游戏服务(提供与每个游戏相关的统计数据和其他数据,以及购买游戏的能力);用户认证服务(用于对移动设备的用户进行认证);以及/或者用户简档服务(用于存储用户简档数据,例如用户偏好)。经由游戏服务组件2010而访问的第二组服务2051可以包括上述的连接数据交换(CDX)服务110以及NAT穿越服务290-291。尽管在附图20中为了说明的目的而被示出为分开的组件,但游戏后台程序2020和游戏服务模块2010实际上可以是游戏框架2000的组成部分。在一个实施方式中,游戏后台程序2020和2010通过预定的API而与各个网络服务2050-2051通信,在一个实施方式中,所述预定的API是私有API(即,不向第三方开发人员公布)。
在一个实施方式中,游戏后台程序2020可以使用HTTPS协议来与匹配服务111、邀请服务112和其他服务2050进行通信,而游戏服务模块2010可以使用相对轻量级的协议(例如UDP套接字)来与CDX服务110和NAT穿越服务290-291通信。但是,如前所述,可以使用各种其他的网络协议,同时仍满足本发明的根本原则。
另外,如附图20中所示的,游戏后台程序2020可以接收由特定服务2052(例如邀请服务和匹配服务)生成的推送通知2052,而其他类型的推送通知2053可以由游戏中心直接接收(例如,朋友服务通知,例如新朋友请求)。在一个实施方式中,这些推送通知2053被直接提供给游戏中心2031,以确保用户的敏感数据不会被由第三方应用开发人员设计的应用2030所访问。
现在返回上面在附图11中提到的游戏邀请的例子,当移动设备A上的应用2030对游戏框架2000的API 2001b进行邀请调用以邀请移动设备B的用户时(例如,INVITE(玩家B ID,游戏/桶ID)),游戏框架2000可以将邀请请求传送到移动设备A的游戏后台程序2020。然后游戏后台程序2020可以与邀请服务112通信以提交邀请请求。邀请服务112然后可以使用推送通知服务1050(如上所述)将邀请推送到移动设备B的游戏后台程序2020。然后移动设备B的游戏后台程序2020可以与移动设备B的游戏框架2000通信,以确定所发送的请求所针对的游戏是否已经在移动设备B上安装。如果已经安装,则游戏框架2000可以触发应用2030和/或生成所述邀请的可视通知。如果该应用未被安装,则游戏框架2000可以对移动设备B的用户触发所述邀请的可视通知,请其购买该游戏(例如,通过游戏中心2031 GUI)。或者,可视通知可以由运行在移动设备120上的推送通知后台程序生成(未示出)。如果移动设备B的用户购买该游戏,则邀请序列可以在进行购买之后继续。如果移动设备B的用户接受邀请请求,则移动设备B的游戏框架2000可以将邀请请求传送至它的游戏后台程序2020,该游戏后台程序然后可以向邀请服务112做出响应。
回到附图11中,兼容性检查1106确定移动设备A和B的NAT类型是兼容的。因此,在1108,移动设备A的游戏后台程序2020可以接收移动设备B的接受信息(例如,在这个例子中通过推送通知),并且,在一个实施方式中,将所述接受信息传递到游戏框架2000。在这一阶段,移动设备A的游戏框架2000可以向进行请求的应用2030通知移动设备B已经接受(通过API 2001),也可以一直等到设备已经成功建立连接时才向进行请求的应用2030作出通知。在任一种情况下,游戏框架2000都可以向游戏服务模块2010传送连接请求,在一个实施方式中,游戏服务模块2010可以发起与移动设备B的连接数据交换。尤其是,游戏服务模块可以采用CDX服务110向移动设备B发送移动设备A的连接数据(参见附图11中的事务1111和1112)。如上所述的,该通信可以以采用安全“标签”数据结构的UDP连接形式来实现。
回到附图12,如果兼容性检查1106确定移动设备A和B的NAT类型是不兼容的,则可以使用中继服务1051来提供这些设备间的连接。因此,移动设备B的游戏后台程序2020可以从邀请服务接收中继响应1203(在附图12中示出),移动设备A的游戏后台程序2020可以从邀请服务接收中继响应1205(通过推送通知服务1050)。移动设备A和B的游戏后台程序2020可以在1206和1207与中继服务通信以获取配置数据。在1210,移动设备B的游戏后台程序2020从移动设备A接收中继更新数据,在1213,移动设备A的游戏后台程序2020从移动设备B接收中继更新数据。
在附图11和12所示处理的最后结果是移动设备A和B相互之间建立连接(可以是直接的P2P连接,也可以是中继连接)。在一个实施方式中,当检测到成功的连接时,游戏框架2000可以使用API调用来向请求进行连接的应用2030作出通知(例如,CONNECTED(玩家A ID,玩家B ID))。移动设备A和B然后可以使用所建立的连接进行指定的游戏或其他协作应用2030。
因此,响应于来自API 2001的相对简单的调用(例如,INVITE玩家B ID,游戏/存储桶ID),游戏框架2000可以管理一系列复杂的事务以在移动设备A和B之间建立P2P或者中继连接。在一个实施方式中,游戏框架2000执行一系列操作以建立移动设备A和B的连接,然后将结果提供给请求应用2030,从而使API调用的细节对于应用设计人员而言保持透明。这样,程序设计人员不需要明白如何在网络上建立移动设备A和B之间的连接,或者如何执行激活设备间的通信所需的各种各样的功能,从而简化了程序设计过程。
以一种类似的方式,游戏框架2000可以采用上面参考附图2a-b的匹配服务111建立介于移动设备A与其他参与者之间的匹配。在这个例子中,应用2030可以对API 2001进行简单的调用,例如MATCH(玩家AID,游戏/包ID)。作为响应,游戏框架2000可以管理匹配和连接数据交换操作。当匹配操作和/或P2P连接已经完成,游戏框架2000将结果提供回应用2030。
例如,在附图2b中,游戏框架2000可以使用游戏服务模块2010与连接数据交换(CDX)服务110以及NAT穿越服务290-291通信,并可以使用游戏后台程序与匹配服务111通信。在作出了匹配后,移动设备A的游戏后台程序2020在229接收标签A,游戏框架2000使用该信息通过游戏服务模块2010实现连接数据交换。例如,在232,它可以通过NAT穿越服务290请求它自己的连接数据,然后在233-234通过CDX服务110交换它的连接数据。在237和240,移动设备A的游戏服务模块2010分别接收用于移动设备B和C的连接数据。在这些交换之后,游戏服务模块2010在241建立P2P连接,游戏框架2000采用API通知来向该应用2030通知该连接进程已经完成(例如,MATCHCOMPLETE(玩家B ID,玩家C ID))。然后可以使用所建立的P2P连接来执行该应用。
在一些实施方式中,可以给用户提供下述选项:与当前注册为“在线”的其他朋友进行游戏。在这种情况中,可以通过推送通知2052或者推送通知2053来提供关于某些朋友在线的通知(由游戏中心2031直接接收)。游戏中心2031和/或应用2030然后可以向用户提供这些通知,并向用户提供与一个或多个所选择的在线朋友玩的选项。但是应当注意,不管是否提供在线通知,这里描述的邀请序列都能工作。在一个实施方式中,用户的在线状态可以由可被游戏后台程序2020访问的服务监视(例如,由上面提到的朋友服务或者被单独的“存在”服务见识)。
游戏框架2000的一个实施方式提供组合的邀请/匹配操作,其中,用户可以邀请一个或多个朋友与一组未知的匹配参与者玩游戏。例如,如果游戏需要4个玩家,第一用户邀请第二用户来玩游戏,则邀请服务112可以首先连接第一用户和第二用户,匹配服务111然后可以将第一用户和第二用户与另外两个(或多个)其他玩家相匹配。在这个实施方式中,游戏框架2000可以首先执行上述的邀请序列以连接第一用户和第二用户。在一个实施方式中,一旦第一用户和第二用户成功连接,游戏框架2000可以实现这些匹配序列,以识别和连接其他用户。如上所述,在一个实施方式中,匹配服务所应用的匹配准则可以包括第一和第二用户二者(例如第一和第二用户的NAT类型、连接类型、语言等)。可选地,可以评估两个用户中一者的准则来做出匹配决定。
一旦所有用户被连接,游戏框架2000可以通过API2001向请求连接的应用2030提供连接结果。再一次,作为应用2030对相对简单的API调用的响应,游戏框架2000进入一组复杂的事务以连接每个设备。一旦设备连接成功,游戏框架2000向进行请求的应用2030提供返回结果。
如附图20中所示的,游戏框架2000可以包括通信缓冲器2003,用于暂时存储用户与其他游戏参与者之间的通信。所述通信例如可以包括文本、音频和/或视频通信。游戏框架2000可以基于每个应用2030的需求来建立缓冲器2003。例如,对于具有较慢网络连接的音频/视频通信,可能需要相对较大的缓冲器2003。在一个实施方式中,每个应用2030可以通过API 2001显式地请求建立某个大小的通信缓冲器(例如,使用BUFFER(size)命令)。可选地,游戏框架2000可以自动地根据每个应用的需求来创建缓冲器。例如,游戏框架2000可以根据是否需要支持文本、音频和/或视频来选择特定缓冲器大小。
在一个实施方式中,在用户之间建立了全部P2P连接之前,通信缓冲器2003可以暂时存储通信流。例如,在邀请服务112或者匹配服务111已经识别每个用户之后、但CDX服务110已经完成连接数据交换操作之前,可以向每个用户通知正在连接进程中的其他游戏参与者。在这个阶段,移动设备120的用户可以发送文本、音频和/或视频通信流至其他参与者。游戏框架2000在通信缓冲器2003中为那些尚未被连接的参与者存储通信流。然后当对于每个设备的连接完成时,游戏框架2000可以从缓冲器2003发送文本、音频和/或视频。
在一个实施方式中,游戏后台程序2020包括用于对每个服务2050上的数据进行缓存的缓存2021,以降低网络的流量。例如,用户的朋友列表、排行榜数据、成就数据、存在数据以及简档数据可以存储在缓存2021中,如由缓存管理策略所指定的。在一个实施方式中,缓存管理策略由存储了数据的各个服务来驱动。因此,对于n个不同的服务,可以对缓存2021应用n个不同的缓存管理策略。另外,因为缓存管理策略是由服务驱动的,它可以基于当前网络和/或服务器负载现状而动态地修改。例如,在服务负载严重的时间段(例如圣诞节、新产品发布日等),服务可以动态地指定缓存管理策略对缓存进行不太频繁的更新(例如每12小时进行更新)。作为比较,在服务负载不严重的时间段,服务可以指定缓冲策略相对频繁地更新缓存(例如每1/2小时、1小时、2小时更新等)。
在一个实施方式中,缓存管理策略是由用于存储在缓存2021中的某些数据记录的生存时间(TTL)值来指定的。当存储在缓存中的数据记录经过了它的TTL值时,则那个数据被认为“陈旧的”,用于那个数据的本地请求可以被直接转发给与那个数据相关联的服务。在一个实施方式中,该请求包括用于识别数据当前版本的ID码。如果该ID码与服务上的ID码匹配,则数据依然是有效的且不需要更新。然后可以从服务发送回响应,以表明缓存中的数据是当前的,用于这些数据的TTL值可以重新设定。
除了如上所述使用缓存管理策略外,在一个实施方式中,用于某些类型数据的缓存更新可以使用推送通知服务1050被推送至移动设备。例如,对用户的朋友列表或用户朋友的当前在线状态进行的改变可以动态地推送至用户的移动设备120。推送通知可以被游戏后台程序2020接收,然后该后台程序可以更新缓存2021以包括由所述服务推送的数据中有关的部分(即,可能不需要对缓存中与那个服务相关的全部数据进行更新)。作为比较,一些推送通知可以指令游戏后台程序2020覆盖缓存的全部内容(或者至少与执行该推送的服务相关的那部分缓存)。
那些利用推送来更新缓存2021的服务可以选择相对较高的TTL值(和/或不设置TTL值),因为它们具有推送通知以更新存储在缓存2021中的数据的能力。在一个实施方式中,每个服务指定一组事件,这些事件可以触发推送通知缓存更新。例如,缓存更新事件可以包括朋友在线状态的改变、新的朋友请求、朋友请求的接受、解除朋友的操作、朋友正在玩特定游戏的指示、朋友达到的游戏成就、特定排行榜前10位的更新、或者被认为足够重要而应进行缓存更新的其他任何事件。以这种方式使用推送通知来更新缓存2021可以降低网络和服务负载,因为随着推送更新,移动设备与设备间的周期性轮询就不需要了。
游戏框架2000的一个实施方式基于用户的国家和/或地理位置唯一地给向终端用户呈现的数据设定格式。例如,对于不同国家和地区的数值(例如用于当前日期、时间以及货币)可以以不同的方式呈现。举例来说,在美国,日期格式可以是【月日,年】(例如,4月25日,2010年),而在其他国家,日期格式可以是【日月,年】(例如,25日4月,2010年)。类似地,当在美国或一些其他国家呈现时间时,可以使用AM/PM的指示并可以在小时和分钟之间使用冒号(例如,3:00PM)。作为比较,许多其他国家并不使用AM/PM指示和/或在小时和分钟之间使用逗号(例如,15,00)。作为另一个例子,世界的许多地方使用公制***而世界的有些地方不使用(例如美国)。应当注意,这些只是可以被本发明的特定实施方式采用的说明性例子。本发明的根本原则并不限于任何特定的数据格式设置。
在一个实施方式中,当显示排行榜数据、成就数据、朋友数据和/或任何其他由游戏框架2000处理的数据时,可以选择这些不同的数据格式。游戏框架2000可以用各种方式确定用户的国家和/或地理位置。例如,在一个实施方式中,该信息简单地在用户的简档数据中提供和/或可以基于用户的蜂窝服务提供商来确定。例如,可以使用全球定位***(GPS)跟踪来确定用户的位置。
与地址位置和/或国家不相关的其他数据格式类型也可由游戏框架2000管理。例如,当显示排行榜数据时,重要的是知道是否最低的得分应当使该用户处于排行榜的顶部或底部。对于一些游戏(例如高尔夫、径赛、竞速、滑雪等),较低的数字代表较好的成绩,而在其他一些游戏中(例如足球、棒球等),较高的数字代表较好的成绩。因此,在一个实施方式中,应用2030通过API 2001指定将要使用的分数类型(例如,“升序”或者“降序”)。然后游戏框架2000可以使用合适的标记和格式设置来显示得分。
游戏框架2000的一个实施方式还可以基于用户与用户的朋友之间的关系来过滤用户数据。例如,本发明的一个实施方式允许有“详细”视图、“朋友”视图以及“公共”视图。在一个实施方式中,详细视图对于拥有该数据(即用户的个人信息)的用户可用。朋友视图对于用户的朋友是可用的;公共视图对于全部其他用户是可用的。
举例来说,公共视图可以仅仅包括与每个用户相关联的“别名”、由该别名进行的游戏和相应的分数、以及进行游戏的日期/时间。这些信息可以由游戏框架2000使用以填入公共排行榜,该排行榜然后可以通过游戏中心2031进行显示。
朋友视图可以包括来自一般视图的所有信息以及在用户的朋友之间共享的附加信息,例如包括:用户拥有的游戏;用户玩过的游戏;用户的成就和分数;用户有多少朋友;那些朋友的身份;对用户的化身(avatar)进行标识的URL和/或该用户的在线状态,这仅是例子。在一个实施方式中,“朋友”视图提供了要与朋友共享的一组缺省信息,但是终端用户可以调整这种缺省设置并指定要由各个朋友或朋友组(例如同事、家庭成员、大学/高中的朋友等)共享的具体类型的信息。
“详细”视图可以包括来自“公共”和“朋友”视图的所有信息以及由各种服务2050代表终端用户而管理的任何其他信息。举例来说,这可以包括该用户的全部简档数据;该用户的通用唯一标识符(“UUID”)(本申请中有时称为“玩家ID”);玩家名字;别名;游戏数目以及游戏的身份;用户的朋友;用户的所有成就等。
在一些情况下,应用2030可以只需要与各个用户相关联的少量信息,例如各个用户的玩家ID。例如,在一个实施方式中,当请求了匹配时,游戏框架2000可以首先只需要各个用户的玩家ID。当匹配是由匹配服务进行的(参见上文)时,游戏框架2000可以确定匹配用户中的任一者是否是朋友(例如,通过与朋友服务进行通信和/或通过查询用户的本地朋友数据)。如果确定,则游戏框架2000可以取得附加的用户数据并提供该数据给任何匹配的朋友。这样,游戏框架2000基于用户的身份和各个用户之间的关系而过滤信息。
在一个实施方式中,如果两个用户不是朋友关系,则游戏框架2000首先在第一用户和第二用户之间提供公共视图。但是,在一个实施方式中,游戏框架2000允许第一用户向第二用户发送朋友请求(例如,使用第二用户的别名)。如果朋友请求被接受,则游戏框架2000将向这些用户中的每一者提供附加的信息(例如,缺省的“朋友”视图)。
其他的API实施方式
在一个实施方式中执行的API是由软件组件(下文中称为“API实现软件组件”)实现的接口,其允许另外的软件组件(下文中称为“API调用软件组件”)访问并使用一个或多个由API实现软件组件提供的函数、方法、程序、数据结构和/或其他服务。例如,API允许API调用软件组件的开发人员(可以是第三方开发人员)支持(leverage)由API实现软件组件提供的指定特性。可以有一个API调用软件组件,也可以有多于一个这样的软件组件。API可以是由计算机***或程序库提供的源代码,以支持来自软件应用的服务请求。可以在当建立应用时能够被解释的或编译的编程语言这方面,而不是在关于数据在存储器中的布置方式的显式低级描述这方面来指定API。
API定义了API调用软件组件访问和使用API实现软件组件的指定特性时使用的语言和参数。例如,API调用软件组件通过由API公开的一个或多个API调用(有时候称为函数或方法调用)来访问API实现软件组件的指定特性。作为对来自API调用软件组件的API调用的响应,API实现软件组件可以通过API返回值。由于API定义了API调用的语法和结果(例如,如何调用API调用以及API调用做什么内容),API通常不公开API调用是如何完成由API调用所指定的函数的。通过一个或多个应用程序接口在调用软件(API调用软件组件)和API实现软件组件之间传递各种函数调用或消息。传递函数调用或消息可以包括对函数调用或消息进行发起、初始化、调用、接收、返回或者响应。因此,API调用软件组件可以传递调用,API实现软件组件也可以传递调用。
举例来说,API实现软件组件2010以及API调用软件组件可以是操作***、库、设备驱动器、API、应用程序或者其他软件模块(应当理解,API实现软件组件以及API调用软件组件可以是彼此相同或者不同类型的软件模块)。API调用软件组件可以是本地软件组件(即,与API实现软件组件在同一数据处理***上),或者在网络上通过API而与API实现软件组件进行通信的远程软件组件(即,与API实现软件组件在不同的数据处理***上)。应当理解,API实现软件组件也可以作为API调用软件组件(即,它可以执行对由其他API实现软件组件公开的API进行的API调用),而通过实现对其他API调用软件组件公开的API,API调用软件组件也可以作为API实现软件组件。
API可以允许以不同编程语言编写的多个API调用软件组件与API实现软件组件进行通信(因此,API可以包括用于对API实现软件组件与API调用软件组件之间的调用和返回进行翻译的特性);但是,API可以根据具体的编程语言来实现。
附图21示出了一个API结构的实施方式,其包括实现API 2120的API实现软件组件2110(例如操作***、库、设备驱动器、API、应用程序或其他软件模块)。API 2120规定了API实现软件组件的一个或多个函数、方法、类、对象、协议、数据结构、格式和/或其他特性,它们可以由API调用软件组件2130使用。API 2120可以规定至少一个调用协定,该协定规定了API实现软件组件中的函数如何从API调用软件组件接收参数以及该函数如何将结果返回到API调用软件组件。API调用软件组件2130(例如操作***、库、设备驱动器、API、应用程序或者其他软件模块),通过API 2120进行API调用以访问和使用由API2120规定的API实现软件组件2110的特性。作为对API调用的响应,API实现软件组件2110可以通过API 2120将值返回到API调用软件组件2130。
应该意识到的是,API实现软件组件2110可以包括未通过API 2120规定、并且对于API调用软件组件2130而言不可用的附加的函数、方法、类、数据结构和/或其他特性。应当理解,API调用软件组件2130可以与API实现软件组件2110在同一***上,或者可以位于远程,并通过在网络上使用API 2120来访问API实现软件组件2110。尽管附图21示出了一个与API 2120交互的API调用软件组件2130,但应当明白,与API调用软件组件2130使用不同语言(或相同语言)编写的其他API调用软件组件也可以使用API 2120。
API实现软件组件2110、API2120以及API调用软件组件2130可以存储在机器可读介质中,该介质包括用于以机器(例如,计算机或其他数据处理***)可读的形式存储信息的任何机制。例如,机器可读形式的介质包括磁盘、光盘、随机存储器、只读存储器、闪存设备等等。
在附图22(“软件堆栈”)的示例性实施方式中,各个应用可以使用几个服务API来对服务1或2执行调用并使用几个OS API对操作***(OS)执行调用。服务1和2可以使用几个OS API对OS执行调用。
注意,服务2具有两个API,其中一个(服务2 API 1)从应用1接收调用并向其返回值,另一个(服务2 API 2)从应用2接收调用并向其返回值。服务1(例如可以是软件库)执行对OS API 1的调用并从OS API 1接收返回值,服务2(例如可以是软件库)执行对OS API 1和OS API 2的调用并从OS API 1和OS API 2接收返回值。应用2执行对OS API 2的调用并从OS API 2接收返回值。
示例性数据处理设备
附图23是示出了可以在本发明的一些实施方式中使用的示例性计算机***的方框图。应当明了的是,尽管附图23示出了计算机***的各种组件,但不应看作展示了将这些组件互连的任何具体结构,因为这些细节并不与本发明密切相关。应该认识到的是,其他具有较少组件或更多组件的计算机***也可以用于本发明。
如附图23所示的,计算机***2300是数据处理***的一种形式,包括与处理***2320、电源2325、存储器2330以及非易失性存储器2340(例如,硬盘、闪存、相变存储器(PCM)等等)耦接的(一个或多个)总线2350。总线2350可以通过本领域熟知的各种桥、控制器和/或适配器互相连接。处理***2320可以从存储器2330和/或非易失性存储器2340取得(一个或多个)指令,并执行所述指令以按照上述方式执行操作。总线2350对上述组件进行互连并将那些组件互连到可选择的扩展坞(dock)2360、显示控制器和显示设备2370、输入/输出设备2380(例如,NIC(网络接口卡)、光标控制(例如鼠标、触摸屏、触摸板等等)、键盘等等)、以及可选的无线收发机2390(例如蓝牙、WIFI、红外等)。
附图24是示出了可以在本发明的一些实施方式中使用的示例性数据处理***的方框图。例如,数据处理***2400可以是手持电脑、个人数字助理(PDA)、移动电话、便携式游戏***、便携式媒体播放器、平板的或手持的运算装置,该装置可以包括移动电话、媒体播放器和/或游戏***。作为另一个例子,数据处理***2400可以是网络计算机,或者另一设备内部的嵌入式处理设备。
根据本发明的一个实施方式,数据处理***2400的示例性结构可以应用于上述的移动设备。数据处理***2400包括处理***2420,***2420可以包括一个或多个微处理器和/或一个集成电路上的***。处理***2420耦接到存储器2410、电源2425(包括一个或多个电池)、音频输入/输出2440、显示控制器及显示设备2460、可选的输入/输出2450、输入设备2470以及无线收发机2430。应该理解,未在附图24中示出的其他组件也可以是本发明特定实施例中数据处理***2400的一部分,在本发明特定实施例中也可以比附图24所示的***采用更少的组件。另外,应该认识到的是,一个或多个总线(未在附图24中示出)可以被用于按照本领域公知的技术对各种组件进行互连。
存储器2410可以存储用于由数据处理***2400执行的数据和/或程序。音频输入/输出2440可以包括麦克风和/或扬声器,例如,用于通过扬声器和麦克风播放音乐和/或提供电话功能。显示控制器和显示设备2460可以包括图形用户接口(GUI)。无线(例如,RF)收发机2430(例如,WIFI收发机,红外收发机,蓝牙收发机,无线蜂窝电话收发机,等等)可用于与其他数据处理***通信。所述一个或多个输入设备2470允许用户向***提供输入。这些输入设备可以是键区、键盘,触摸板,多触摸板,等等。可选的其他输入/输出2450可以是用于扩展坞的连接器。
本发明的实施方式可以包括前面提出的各种步骤。这些步骤可以用机器可执行的指令来实现,所述指令可以使得通用或专用处理器来执行这些步骤。可选地,这些步骤可以由包含执行所述步骤所用的硬连线逻辑的专门硬件组件、或者经过编程的计算机组件和定制硬件组件的任意组合来执行。
本发明的要素还可以以用于存储机器可执行程序代码的机器可读介质形式来提供。机器可读介质可以包括但不限于软盘,光盘,CD-ROM,磁光盘,ROM,RAM,EPROM,EEPROM,磁或光卡,或者其他适合用于存储电子程序代码的媒体/机器可读介质。
在上述说明中,为了说明目的而提出大量的细节以提供对本发明的全面理解。但是对本领域技术人员来说显而易见的是,本发明可以在没有这些具体细节的情况下实施。例如,对本领域技术人员来说显而易见的是,在此描述的功能模块和方法可以以软件、硬件或其任意组合的形式来实现。此外,尽管在移动运算环境中(即,利用移动设备120-123;601-603)对本发明的实施方式进行了说明,但本发明的根本原则并不限于移动运算执行。事实上,一些实施方式中可以使用任何类型的客户端或节点数据处理设备,例如包括台式机或工作站。因而,本发明的范围和精神应当以所附权利要求的方式来判定。
Claims (16)
1.一种计算机实现的方法,用于为点对点(“P2P”)通信建立和保持备份信道,所述方法包括:
开启与一个或多个移动计算设备的主要P2P通信信道,所述主要P2P通信信道用于开启与所述一个或多个移动计算设备的P2P会话;
在所述主要P2P通信信道上与所述一个或多个移动计算设备交换次要信道连接数据;
使用所述次要信道连接数据来开启与所述一个或多个移动计算设备的一个或多个次要P2P通信信道;
对所述主要P2P信道已经衰落到指定阈值以下进行检测;以及
作为响应,将所述次要P2P通信信道中的一个提升为主要P2P通信信道。
2.如权利要求1所述的方法,进一步包括:
通过在所述次要通信信道上周期性的发送心跳分组,来保持所述次要通信信道。
3.如权利要求1所述的方法,其中,开启主要通信信道的步骤包括:与所述一个或多个移动计算设备交换连接数据。
4.如权利要求3所述的方法,其中,交换连接数据的步骤进一步包括:执行一系列网络连接建立(“ICE”)事务。
5.如权利要求1所述的方法,其中,所述指定阈值包括所述主要通信信道的故障。
6.如权利要求1所述的方法,进一步包括:
将与所述主要通信信道和所述一个或多个次要通信信道有关的连接数据与这些通信信道中每一者的当前状态存储在存储设备上。
7.如权利要求1所述的方法,其中,每个通信信道由一组通信链路组成,所述通信链路包括下列项中的一个或多个:第三代(“3G”)无线蜂窝链路,***(“4G”)无线蜂窝链路,Wi-Fi链路,以及蓝牙链路。
8.如权利要求1所述的方法,其中,至少一个主要或次要P2P通信信道包括介于第一移动计算设备与第二移动计算设备之间的私有网络链路,其中,与所述第二移动计算设备的所述P2P连接是通过所述第一移动计算设备建立的。
9.一种数据处理***,包括:
用于开启与一个或多个其它移动计算设备的主要P2P通信信道的装置,所述主要P2P通信信道用于开启与所述一个或多个移动计算设备的会话;
用于在所述主要P2P通信信道上与所述一个或多个移动计算设备交换次要信道连接数据的装置;
用于使用所述次要信道连接数据来开启与所述一个或多个其它移动计算设备的一个或多个次要P2P通信信道的装置;
用于对所述主要P2P通信信道已经衰落到指定阈值以下进行检测的装置;以及
用于作为响应而将所述次要P2P通信信道中的一个提升为主要P2P通信信道的装置。
10.如权利要求9所述的***,进一步包括:
用于通过在所述次要通信信道上周期性的发送心跳分组来保持所述次要通信信道的装置。
11.如权利要求9所述的***,其中,开启主要通信信道包括:与所述一个或多个移动计算设备交换连接数据。
12.如权利要求11所述的***,其中,交换连接数据进一步包括:执行一系列网络连接建立(“ICE”)事务。
13.如权利要求9所述的***,其中,所述指定阈值包括所述主要通信信道的故障。
14.如权利要求9所述的***,进一步包括:
用于将与所述主要通信信道和所述一个或多个次要通信信道有关的连接数据与这些通信信道中每一者的当前状态存储在存储设备上的装置。
15.如权利要求9所述的***,其中,每个通信信道由一组通信链路组成,所述通信链路包括下列项中的一个或多个:第三代(“3G”)无线蜂窝链路,***(“4G”)无线蜂窝链路,Wi-Fi链路,以及蓝牙链路。
16.如权利要求9所述的方法,其中,至少一个主要或次要P2P通信信道包括介于第一移动计算设备与第二移动计算设备之间的私有网络链路,其中,与所述第二移动计算设备的所述P2P连接是通过所述第一移动计算设备建立的。
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US32184110P | 2010-04-07 | 2010-04-07 | |
US61/321,841 | 2010-04-07 | ||
US12/832,013 US8819244B2 (en) | 2010-04-07 | 2010-07-07 | Apparatus and method for establishing and utilizing backup communication channels |
US12/832,013 | 2010-07-07 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN102215121A true CN102215121A (zh) | 2011-10-12 |
CN102215121B CN102215121B (zh) | 2014-10-15 |
Family
ID=43479274
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201010552053.6A Active CN102215121B (zh) | 2010-04-07 | 2010-09-25 | 用于建立和利用备份通信信道的装置和方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN102215121B (zh) |
Cited By (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102546105A (zh) * | 2011-12-28 | 2012-07-04 | 深圳市新为软件有限公司 | 一种网络资源传输的方法和装置 |
CN103891395A (zh) * | 2011-10-17 | 2014-06-25 | 国际商业机器公司 | 多设备监视及控制 |
CN104885500A (zh) * | 2012-12-30 | 2015-09-02 | Lg电子株式会社 | 在无线通信***中执行装置对装置通信的设备和方法 |
CN105009519A (zh) * | 2012-11-23 | 2015-10-28 | 卡尔加里科技股份有限公司 | 用于来自协作应用会话的对等式发现和连接的方法和*** |
CN105262853A (zh) * | 2015-09-23 | 2016-01-20 | 上海斐讯数据通信技术有限公司 | 一种p2p连接nat穿越的路径建立方法、装置及*** |
CN105722244A (zh) * | 2014-12-02 | 2016-06-29 | 联想(北京)有限公司 | 一种信息处理方法及电子设备 |
CN105744046A (zh) * | 2014-12-08 | 2016-07-06 | 联想(北京)有限公司 | 一种信息处理方法及电子设备 |
CN105991697A (zh) * | 2015-02-06 | 2016-10-05 | 深圳富泰宏精密工业有限公司 | 点对点通信实现方法及*** |
CN106161750A (zh) * | 2015-04-14 | 2016-11-23 | 联想(北京)有限公司 | 一种信息处理方法及电子设备 |
CN106209328A (zh) * | 2016-07-12 | 2016-12-07 | 邦彦技术股份有限公司 | 一种信道智能冗余备份方法和*** |
CN106899493A (zh) * | 2017-02-22 | 2017-06-27 | 广东网金控股股份有限公司 | 基于UDP与Https实现的消息推送方法及其装置 |
CN107210912A (zh) * | 2014-12-29 | 2017-09-26 | 维萨国际服务协会 | 对应用程序库的授权访问 |
CN107370764A (zh) * | 2017-09-05 | 2017-11-21 | 北京奇艺世纪科技有限公司 | 一种音视频通信***及音视频通信方法 |
CN107426811A (zh) * | 2013-02-12 | 2017-12-01 | 英特尔Ip公司 | 用于同步设备和nan配置的方法、无线通信站和*** |
CN109039915A (zh) * | 2018-08-24 | 2018-12-18 | 珠海迈越信息技术有限公司 | 一种建立数据连接通道的方法及*** |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1209233A (zh) * | 1995-12-18 | 1999-02-24 | 艾利森公司 | 卫星分集方法 |
CN101222551A (zh) * | 2006-12-30 | 2008-07-16 | 虹软(上海)科技有限公司 | 使用次级信道来传送ip地址以用于点对点通信 |
-
2010
- 2010-09-25 CN CN201010552053.6A patent/CN102215121B/zh active Active
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1209233A (zh) * | 1995-12-18 | 1999-02-24 | 艾利森公司 | 卫星分集方法 |
CN101222551A (zh) * | 2006-12-30 | 2008-07-16 | 虹软(上海)科技有限公司 | 使用次级信道来传送ip地址以用于点对点通信 |
Cited By (29)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103891395A (zh) * | 2011-10-17 | 2014-06-25 | 国际商业机器公司 | 多设备监视及控制 |
US10028134B2 (en) | 2011-10-17 | 2018-07-17 | International Business Machines Corporation | Multi-device monitoring and control using intelligent device channel sharing |
US9913133B2 (en) | 2011-10-17 | 2018-03-06 | International Business Machines Corporation | Multi-device monitoring and control using intelligent device channel sharing |
CN103891395B (zh) * | 2011-10-17 | 2018-08-28 | 国际商业机器公司 | 多设备监视及控制 |
US10609550B2 (en) | 2011-10-17 | 2020-03-31 | International Business Machines Corporation | Multi-device monitoring and control using intelligent device channel sharing |
CN102546105A (zh) * | 2011-12-28 | 2012-07-04 | 深圳市新为软件有限公司 | 一种网络资源传输的方法和装置 |
CN105009519A (zh) * | 2012-11-23 | 2015-10-28 | 卡尔加里科技股份有限公司 | 用于来自协作应用会话的对等式发现和连接的方法和*** |
US9894153B2 (en) | 2012-11-23 | 2018-02-13 | Calgary Scientific Inc. | Methods and systems for peer-to-peer discovery and connection from a collaborative application session |
CN104885500B (zh) * | 2012-12-30 | 2019-04-16 | Lg电子株式会社 | 在无线通信***中执行装置对装置通信的方法 |
CN104885500A (zh) * | 2012-12-30 | 2015-09-02 | Lg电子株式会社 | 在无线通信***中执行装置对装置通信的设备和方法 |
CN107426811B (zh) * | 2013-02-12 | 2021-03-19 | 英特尔Ip公司 | 用于同步设备和nan配置的方法、无线通信站和*** |
CN107426811A (zh) * | 2013-02-12 | 2017-12-01 | 英特尔Ip公司 | 用于同步设备和nan配置的方法、无线通信站和*** |
CN105722244B (zh) * | 2014-12-02 | 2020-07-24 | 联想(北京)有限公司 | 一种信息处理方法及电子设备 |
CN105722244A (zh) * | 2014-12-02 | 2016-06-29 | 联想(北京)有限公司 | 一种信息处理方法及电子设备 |
CN105744046B (zh) * | 2014-12-08 | 2019-07-26 | 联想(北京)有限公司 | 一种信息处理方法及电子设备 |
CN105744046A (zh) * | 2014-12-08 | 2016-07-06 | 联想(北京)有限公司 | 一种信息处理方法及电子设备 |
CN107210912A (zh) * | 2014-12-29 | 2017-09-26 | 维萨国际服务协会 | 对应用程序库的授权访问 |
CN105991697A (zh) * | 2015-02-06 | 2016-10-05 | 深圳富泰宏精密工业有限公司 | 点对点通信实现方法及*** |
CN106161750A (zh) * | 2015-04-14 | 2016-11-23 | 联想(北京)有限公司 | 一种信息处理方法及电子设备 |
CN105262853A (zh) * | 2015-09-23 | 2016-01-20 | 上海斐讯数据通信技术有限公司 | 一种p2p连接nat穿越的路径建立方法、装置及*** |
WO2018010238A1 (zh) * | 2016-07-12 | 2018-01-18 | 邦彦技术股份有限公司 | 一种信道智能冗余备份方法和*** |
CN106209328B (zh) * | 2016-07-12 | 2019-09-06 | 邦彦技术股份有限公司 | 一种信道智能冗余备份方法和*** |
CN106209328A (zh) * | 2016-07-12 | 2016-12-07 | 邦彦技术股份有限公司 | 一种信道智能冗余备份方法和*** |
CN106899493A (zh) * | 2017-02-22 | 2017-06-27 | 广东网金控股股份有限公司 | 基于UDP与Https实现的消息推送方法及其装置 |
CN106899493B (zh) * | 2017-02-22 | 2020-04-24 | 广东网金控股股份有限公司 | 基于UDP与Https实现的消息推送方法及其装置 |
CN107370764A (zh) * | 2017-09-05 | 2017-11-21 | 北京奇艺世纪科技有限公司 | 一种音视频通信***及音视频通信方法 |
CN107370764B (zh) * | 2017-09-05 | 2020-06-05 | 北京奇艺世纪科技有限公司 | 一种音视频通信***及音视频通信方法 |
CN109039915A (zh) * | 2018-08-24 | 2018-12-18 | 珠海迈越信息技术有限公司 | 一种建立数据连接通道的方法及*** |
CN109039915B (zh) * | 2018-08-24 | 2021-07-23 | 珠海迈越信息技术有限公司 | 一种建立数据连接通道的方法及*** |
Also Published As
Publication number | Publication date |
---|---|
CN102215121B (zh) | 2014-10-15 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN102215249B (zh) | 用于为在线会话匹配用户的装置和方法 | |
CN102215121B (zh) | 用于建立和利用备份通信信道的装置和方法 | |
CN102215274B (zh) | 用于邀请用户到在线会话的设备和方法 | |
KR101408560B1 (ko) | 사용자를 온라인 세션에 초대하기 위한 장치 및 방법 | |
CN103348633B (zh) | 用于管理不同的服务提供方之间的点对点连接的装置和方法 | |
TWI458369B (zh) | 用於建立及使用備用通信頻道之裝置及方法 | |
CN103597783B (zh) | 用于安全即时消息传输的***与方法 | |
US20110207528A1 (en) | Game supply system using personal area network, a game supply method thereby, a service server, a relay method, a mobile phone and a storage means |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant |