CN109510882B - 游戏客户端之间的通信方法、装置、存储介质和电子装置 - Google Patents

Abstract

本发明公开了一种游戏客户端之间的通信方法、装置，存储介质和电子装置。其中，该方法包括：将确定的第一客户端的第一中继地址注册至第一服务器中，其中，第一服务器中还包括第二客户端注册的第二中继地址；接收第一服务器发送的第二中继地址，其中，第一中继地址通过第一服务器发送至第二客户端；利用第一中继地址和第二中继地址建立第一客户端与第二客户端之间的通信。本发明解决了相关技术中通信方式转换方式复杂，用户体验差的技术问题。

Description

游戏客户端之间的通信方法、装置、存储介质和电子装置

技术领域

本发明涉及游戏技术领域，具体而言，涉及一种游戏客户端之间的通信方法、装置，存储介质和电子装置。

背景技术

有一些网络游戏在网络模型实现上，可以选择端到端的通信(Peer to Peer，简称为P2P)方法。P2P通信方式在理想情况下，可以走最短的路由，是通信效率较高的模型。但在一些网络环境中，P2P模式存在诸多限制，需要将其P2P通信模式改造为客户端服务器通信(Client/Server，简称为C/S)的方式。

但现有技术中在进行通信方式转换时，存在着一系列转换问题。

针对上述的问题，目前尚未提出有效的解决方案。

发明内容

本发明实施例提供了一种游戏客户端之间的通信方法、装置，存储介质和电子装置，以至少解决相关技术转换通信方式复杂，用户体验差的技术问题。

根据本发明实施例的一个方面，提供了一种游戏客户端之间的通信方法，包括：将确定的第一客户端的第一中继地址注册至第一服务器中，其中，第一服务器中还包括第二客户端注册的第二中继地址；接收第一服务器发送的第二中继地址，其中，第一中继地址通过第一服务器发送至第二客户端；利用第一中继地址和第二中继地址建立第一客户端与第二客户端之间的通信。

根据本发明实施例的另一方面，还提供了一种游戏客户端之间的通信装置，确定第二服务器向第一客户端分配第一中继地址，以指示第一客户端向第一服务器注册第一中继地址；在第一客户端与第二客户端之间利用第一中继地址和第二中继地址建立通信时，确定第一客户端与第二客户端之间的通信方式从第一通信方式转换为第二通信方式。

根据本发明的又一个实施例，还提供了一种存储介质，所述存储介质中存储有计算机程序，其中，所述计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。

根据本发明的又一个实施例，还提供了一种电子装置，包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行上述任一项方法实施例中的步骤。

在本发明实施例中，采用将确定的第一客户端的第一中继地址注册至第一服务器中，其中，第一服务器中还包括第二客户端注册的第二中继地址；接收第一服务器发送的第二中继地址，其中，第一中继地址通过第一服务器发送至第二客户端；利用第一中继地址和第二中继地址建立第一客户端与第二客户端之间的通信。即是通过第一服务器实现第一客户端与第二客户端之间中继地址的交换，从而实现了通信方式的转换，进而解决了相关技术中通信方式转换方式复杂，用户体验差的技术问题。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是本发明实施例的一种游戏客户端之间的通信方法的移动终端的硬件结构框图；

图2是根据本发明实施例提供的游戏客户端之间的通信方法的流程示意图(一)；

图3是基于STUN协议的P2P通信方式的示意图；

图4是本实施例中基于TURN协议的C/S通信方式的示意图；

图5是本实施例中的两个客户端均基于TURN协议进行通信的基本模式示意图；

图6是本实施例中交换中继地址的示意图；

图7根据本发明实施例提供的游戏客户端之间的通信方法的流程示意图(二)；

图8是根据本发明实施例提供的游戏客户端之间的通信装置的结构示意图(一)；

图9是根据本发明实施例提供的游戏客户端之间的通信装置的结构示意图(二)。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

根据本发明实施例，提供了一种游戏客户端之间的通信方法实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

本发明实施例所提供的方法实施例可以在移动终端、计算机终端或者类似的运算装置中执行。以运行在移动终端上为例，图1是本发明实施例的一种游戏客户端之间的通信方法的移动终端的硬件结构框图。如图1所示，移动终端10可以包括一个或多个(图1中仅示出一个)处理器102(处理器102可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)和用于存储数据的存储器104，可选地，上述移动终端还可以包括用于通信功能的传输设备106以及输入输出设备108。本领域普通技术人员可以理解，图1所示的结构仅为示意，其并不对上述移动终端的结构造成限定。例如，移动终端10还可包括比图1中所示更多或者更少的组件，或者具有与图1所示不同的配置。

存储器104可用于存储计算机程序，例如，应用软件的软件程序以及模块，如本发明实施例中的游戏客户端之间的通信方法对应的计算机程序，处理器102通过运行存储在存储器104内的计算机程序，从而执行各种功能应用以及数据处理，即实现上述的方法。存储器104可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器104可进一步包括相对于处理器102远程设置的存储器，这些远程存储器可以通过网络连接至移动终端10。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

传输装置106用于经由一个网络接收或者发送数据。上述的网络具体实例可包括移动终端10的通信供应商提供的无线网络。在一个实例中，传输装置106包括一个网络适配器(Network Interface Controller，简称为NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输装置106可以为射频(Radio Frequency，简称为RF)模块，其用于通过无线方式与互联网进行通讯。

图2是根据本发明实施例提供的游戏客户端之间的通信方法的流程示意图(一)，如图2所示，该方法包括如下步骤：

步骤S202，将确定的第一客户端的第一中继地址注册至第一服务器中，其中，第一服务器中还包括第二客户端注册的第二中继地址；

步骤S204，接收第一服务器发送的第二中继地址，其中，第一中继地址通过第一服务器发送至第二客户端；

步骤S206，利用第一中继地址和第二中继地址建立第一客户端与第二客户端之间的通信。

通过上述步骤，采用将确定的第一客户端的第一中继地址注册至第一服务器中，其中，第一服务器中还包括第二客户端注册的第二中继地址；接收第一服务器发送的第二中继地址，其中，第一中继地址通过第一服务器发送至第二客户端；利用第一中继地址和第二中继地址建立第一客户端与第二客户端之间的通信。即是通过第一服务器实现第一客户端与第二客户端之间中继地址的交换，从而实现了通信方式的转换，进而解决了相关技术中通信方式转换方式复杂，用户体验差的技术问题。

需要说明的是，上述中的执行主体可以是第一客户端，但不限于此。

需要说明的是，利用第一中继地址和第二中继地址建立第一客户端与第二客户端之间的通信，用于确定将第一客户端与第二客户端之间的通信方式从第一通信方式转换为第二通信方式，其中，第一通信方式为第一客户端与第二客户端之间直接进行的通信，第二通信方式为第一客户端与第二客户端借助第一服务器进行的通信。

需要说明的是，第一客户端与第二客户端之间的第一通信方式可以是P2P通信方式，也可以是其他终端与终端之间直接进行通信的方式。第一通信方式的效率比较高，例如，图3是基于STUN协议的P2P通信方式的示意图，STUN协议全称是Simple Traversal ofUDP Through Network，是一种基于用户数据协议(User Date Protocol，简称为UDP)协议的通过内网穿透方式实现的P2P通信方式。如图3所示，在外网架设一台STUN server，内网的client向server发送一条捆绑binding请求，获取到自己在gateway(网关)上的NAT出口地址；通过其它方式将出口地址通知给需要通信的peer(对端)；peer向出口地址发送UDP数据包，gateway利用NAT将数据转发给内网中的client。

需要说明的是，第二通信方式可以是C/S通信方式，图4是本实施例中基于TURN协议的C/S通信方式的示意图，TURN协议全称为Traversal Using Relay NAT，支持UDP/TCP协议，是基于C/S模式的通信方式。如图4所示，在外网架设TURN server，内网的client向TURNserver发起allocate请求，在server上创建一个relayed address(中继地址)；Client将relayed address通过其它方式告知给peer(对端)；对端直接与relayed address通信，server会将通信内容转发给对应的client。

需要说明的是，采用P2P的通信方式存在以下问题：

1.受NAT类型限制，NAT分两类，对称型和圆锥型，圆锥型才支持此通信方式；

2.只能使用UDP通信，而国内部分运营商屏蔽了UDP协议；该原因导致国内有近1/4的用户不能采用此通信方式；

3.游戏的对战过程完全依赖客户端，缺乏服务器进行仲裁，可以被恶意利用；

4.现今是移动网络时代，存在用户接入点频繁变化的情况，比如说4G与Wi-Fi的切换，原方式很难处理接入点变化，因为一旦接入点变化，NAT出口地址也会变化

5.因为历史原因，国内跨运营商的线路存在种种限制，分属不同运营商的用户通过P2P直连可能会走相当迂回的线路，导致通信质量低下

C/S通信方式是基于标准的TURN协议，可以克服P2P通信方式中的部分问题，比如NAT类型限制，UDP通信限制、移动网络接入等，但依然存在以下问题：未提供客户端间交换中继地址的方案；不提供服务器仲裁(针对断线判定与网络质量的)；不提供协议回退机制(协议回退机制是指，因为部分网络运营商不支持UDP协议，需要提供在UDP不能工作的情况下，转换到TCP协议的机制。)

基于上述原因，本实施例要解决的技术问题分别为：提供标准TURN协议未提供的交换中继地址信息的机制；提供标准TURN协议未提供的服务器仲裁功能；提供标准TURN协议未提供的协议回退机制。

在一个可选的实施例中，第一中继地址至与第一客户端连接的第二服务器基于网络协议分配的。第二中继地址是与第二客户端连接的第三服务器基于网络协议分配的。在中继地址交换问题上，第一服务器提供中继地址交换功能，第一服务器可以是一个第三方的服务，也可以是游戏服务自身。第一服务器与第二服务器可以是相同的服务器，也可以是不同的服务器。

在一个可选的实施例中，第二服务器与第三服务器，除了支持标准的基于TURN协议的数据转发功能之外，还需要提供保活机制和网络状况检查机制，来为服务器实现仲裁功能提供基础数据。

传统的保活机制通常是server/client任意一方发起保活协议，另一方接收到保活协议后回复一个保活协议。设定一个超时时间，任意一方在超时时间内没有收到保活协议，视作通信断开。在本实施例中，在确定与第二服务器之间的连接第一次断开时，在预定时间内恢复与第二服务器之间的连接；在确定与第二服务器之间的连接第二次断开时，标记第一客户端与第二服务器之间处于断开连接的状态。即二阶段保活：传统的保活机制只有一阶段，在通信状态中一旦保活失败则进入断开阶段；本实施例中的保活机制则有两阶段，一旦保活失败，先进入等待重连阶段；在重连阶段中，客户端重连恢复通信，则回到正常通信；再度保活失败则进入断开阶段；重连阶段向不主动向应用层通知客户端已断开通信，但要求仲裁时需要视客户端为已断开连接。

三向保活：传统保活机制的协议是一来一回的，本实施例是向第二服务器发送第一保活指令，其中，第一保活指令中包括第一客户端发送第一保活指令时的第一时间点；接收第二服务器发送的第二保活指令，其中，第二保活指令中包括第二服务器发送第二保活指令时的第二时间点和第一时间点；基于第一时间点和当前时间点计算出第一客户端与第二服务器之间的第一网络延迟时间；向第二服务器发送第三保活指令，其中，第三保活指令中包括第二时间点，以指示第二服务器基于第二时间点确定第一客户端与第二服务器之间的网络延迟；基于第一网络延迟时间处理第一客户端与第二服务器之间的网络延迟。第一保活指令、第二保活指令以及第三保活指令均是通过保活协议封装的。例如，由client发起保活协议1，保活协议1包含发起方的当前时间t1；第二服务器收到后回复保活协议2，保活协议2包含协议1中的发起方的时间数据t1，并再附带本方的当前时间t2；客户端收到保活协议2后，根据t1与本地当前时间，计算出网络延迟，再回复保活协议3，保活协议3包含时间t2；第二服务器收到保活协议3，根据t2与本地当前时间，计算出网络延迟。

另一部分仲裁内容是第二服务器判定网络状况，三向保活保证了第二服务器一定能拿到每次的网络延迟。通过设定两个阈值，阈值TL和阈值TA，当单次延迟时间L超过TL时，将此T累加到A，当A达到TL时，判定为网络质量下降到我们不能容忍的程度。

在一个可选的实施例中，第一客户端方面，还增加了协议回退的机制。即确定与第二服务器之间通过用户数据协议UDP协议进行通信；在确定与第二服务器之间的通信断开时，将UDP协议替换为传输控制协议TCP协议与第二服务器重新建立连接。

例如，在单局游戏启动时，尝试UDP通信，如果失败，则回退至TCP，并且在整个进程生命周期内保持TCP通信；在单局游戏中，如果UDP通信发生错误，则重连时回退至TCP，并且在此局游戏过程中保持TCP通信，下一局游戏开始时依然优先采用UDP通信。

综上所述，二阶段保活能够更准确地提供仲裁结果。在重连阶段中，游戏对战的其它参与方要求仲裁时，服务器会将在重连阶段的客户端视作断开。有一些带重连机制的服务也有此阶段，但通常应用层会将重连阶段视作客户端依然在通信中，但此时客户端实际上是没有通信的，如果视作通信中则会得到错误的判断结果。三向保活可以更全面地搜集服务器客户端之间的网络信息。传统的双向保活，只能让发起方搜集到网络延迟数据。因为服务器IP固定，一般UDP通信都是客户服发起保活，因此服务器不能获得网络状况。有玩家通过修改路由器的单向流量来干扰正常的通信，比如限制己方下行，对于特定游戏类型可以不正当获利。三向保活则能够避免上述情况的发生。

服务器网络状况检查机制，可以忽略网络波动以何种形式在时间上分布，从整体层面来判定网络状况，提供更为宏观的判定机制。

客户端协议回退机制，保证了尽量优先采用UDP协议，因为UDP协议的通信速率较TCP更优。大部分情况下玩家的网络环境是不会变化的，在游戏启动时，如果UDP不通，说明当前玩家网络不支持UDP的可能性更高，此时回退至TCP并保持整个进程生命周期更为合理。而在比赛中UDP通信失败，是网络临时变化或波动的可能性更高，因此只在单局游戏剩余时间内回退至TCP更为合理。

下面结合具体实施例对本发明进行进一步说明：

图5是本实施例中的两个客户端均基于TURN协议进行通信的基本模式示意图，如图所示，每个客户端依照TURN协议过程分配中继地址，两个客户端之间均通过中继地址通信。两个客户端可以分配到同一服务器，也可以是不同的服务器，都利用socket进行通信。

图6是本实施例中交换中继地址的示意图，如图6所示，建立通信过程的时序如下：

客户端A(对应于上述中的第一客户端)获得第一中继地址，并向第一服务器来注册此地址，开始轮询获取第二客户端的第二中继地址；

客户端B(对应于上述中的第二客户端)获得第二中继地址，并向第一服务器注册此地址，发现第一客户端已注册了第一中继地址，开始进行通信；

客户端A轮询获得客户端B的第二中继地址，开始进行通信。

保活与网络状况检查的过程包括：

通信会话初始化时状态设置为通信中；将所有通信会话的数据结构组织为一个链表；

client发起保活协议1，协议1包含发起方的当前时间t1；

TURN服务器(以下均简称服务器)收到后回复协议2，保活协议2包含协议1中的发起方的时间数据t1，并再附带本方的当前时间t2；

第一客户端收到协议2后，根据t1与本地当前时间，计算出网络延迟，再回复协议3，保活协议3包含时间t2；

服务器收到协议3，根据t2与本地当前时间计算出网络延迟，进行网络状况检查，记录下当前时间为最后收到保活协议的时间，并且将此会话放置到链表头部(只通过协议3来保活的原因是，避免客户端通过限制下行来作弊，限制下行不会影响协议1的收发，会使客户端收不到协议2，也就无法激活协议3)；

服务器每隔一定时间从链表尾部开始检查，此时链表尾部一定是最久没有收到保活协议3的会话，如果距离当前时间超过设定的超时时间，则视作超时；

超时的会话依据其状态进行相应的处理，通信中的会话将会置为等待重连状态，重新放置到超时链表头部，等待第二阶段超时判定，并且通知上层应用客户端超时；如果是等待重连状态，则将会话设置为断开状态，从超时链表中删除，关闭会话，并通知上层应用进行善后处理；

服务器收到保活协议3后的网络状况检查的过程为，判断本次延迟L是否超过设定的阈值TL，如果不超过，认定为正常延迟，不做任何处理；

如果L超过TL，认定为异常延迟，将L累加到累计异常延迟A上，判定A是否超过阈值TA，如果不超过，则不做处理；

如果A超过TA，则认定为网络状况较差，将其会话直接设定为断开状态，并进行相应处理；

协议回退机制：

在单局游戏启动时，尝试UDP通信，如果失败，则回退至TCP，并且在整个进程生命周期内保持TCP通信；

失败的状况包括：创建udp socket失败，发送udp协议包失败，尝试分配中继地址失败或超时，获取对方中继地址失败或超时。

在单局游戏中，如果UDP通信发生错误，则重连时回退至TCP，并且在此局游戏过程中保持TCP通信，下一局游戏开始时依然优先采用UDP通信。

通信失败的状况包括：客户端socket函数调用发生错误，客户端保活失败，客户端认定网络状况下降超过阈值(与服务器检测方式相通)。

需要说明的是，上述步骤的执行主体可以是上述图1所示的终端，但并不限于此。

图7根据本发明实施例提供的游戏客户端之间的通信方法的流程示意图(二)，如图7所示，该方法包括如下步骤：

步骤S702，确定第二服务器向第一客户端分配第一中继地址，以指示第一客户端向第一服务器注册第一中继地址；

步骤S704，在第一客户端与第二客户端之间利用第一中继地址和第二中继地址建立通信时，确定第一客户端与第二客户端之间的通信方式从第一通信方式转换为第二通信方式。

通过上述步骤，采用服务器向第一客户端分配第一中继地址，以指示第一客户端向第一服务器注册第一中继地址，在第一客户端与第二客户端之间利用第一中继地址和第二中继地址建立通信时，确定第一客户端与第二客户端之间的通信方式从第一通信方式转换为第二通信方式，其中，第一通信方式为第一客户端与第二客户端之间直接进行的通信，第二通信方式为第二客户端与第二客户端借助第一服务器进行的通信。从而实现了通信方式的转换，进而解决了相关技术中通信方式转换方式复杂，用户体验差的技术问题。

需要说明的是，上述中的执行主体可以是第二服务器，但不限于此。

需要说明的是，第一通信方式为第一客户端与第二客户端之间直接进行的通信，第二通信方式为第二客户端与第二客户端借助第一服务器进行的通信。

在一个可选的实施例中，第二服务器向第一客户端分配第一中继地址包括：基于网络协议向第一客户端分配第一中继地址。

在一个可选的实施例中，第二服务器与第三服务器，除了支持标准的基于TURN协议的数据转发功能之外，还需要提供保活机制和网络状况检查机制，来为服务器实现仲裁功能提供基础数据。

传统的保活机制通常是server/client任意一方发起保活协议，另一方接收到保活协议后回复一个保活协议。设定一个超时时间，任意一方在超时时间内没有收到保活协议，视作通信断开。在本实施例中，在确定与第二服务器之间的连接第一次断开时，在预定时间内恢复与第二服务器之间的连接；在确定与第二服务器之间的连接第二次断开时，标记第一客户端与第二服务器之间处于断开连接的状态。即二阶段保活：传统的保活机制只有一阶段，在通信状态中一旦保活失败则进入断开阶段；本实施例中的保活机制则有两阶段，一旦保活失败，先进入等待重连阶段；在重连阶段中，客户端重连恢复通信，则回到正常通信；再度保活失败则进入断开阶段；重连阶段向不主动向应用层通知客户端已断开通信，但要求仲裁时需要视客户端为已断开连接。

三向保活：传统保活机制的协议是一来一回的，本实施例是向第二服务器发送第一保活指令，其中，第一保活指令中包括第一客户端发送第一保活指令时的第一时间点；接收第二服务器发送的第二保活指令，其中，第二保活指令中包括第二服务器发送第二保活指令时的第二时间点和第一时间点；基于第一时间点和当前时间点计算出第一客户端与第二服务器之间的第一网络延迟时间；向第二服务器发送第三保活指令，其中，第三保活指令中包括第二时间点，以指示第二服务器基于第二时间点确定第一客户端与第二服务器之间的网络延迟；基于第一网络延迟时间处理第一客户端与第二服务器之间的网络延迟。第一保活指令、第二保活指令以及第三保活指令均是通过保活协议封装的。例如，由client发起保活协议1，保活协议1包含发起方的当前时间t1；第二服务器收到后回复保活协议2，保活协议2包含协议1中的发起方的时间数据t1，并再附带本方的当前时间t2；客户端收到保活协议2后，根据t1与本地当前时间，计算出网络延迟，再回复保活协议3，保活协议3包含时间t2；第二服务器收到保活协议3，根据t2与本地当前时间，计算出网络延迟。

另一部分仲裁内容是第二服务器判定网络状况，三向保活保证了第二服务器一定能拿到每次的网络延迟。通过设定两个阈值，阈值TL和阈值TA，当单次延迟时间L超过TL时，将此T累加到A，当A达到TL时，判定为网络质量下降到我们不能容忍的程度。

在一个可选的实施例中，第一客户端方面，还增加了协议回退的机制。即确定与第二服务器之间通过用户数据协议UDP协议进行通信；在确定与第二服务器之间的通信断开时，将UDP协议替换为传输控制协议TCP协议与服务器重新建立连接。

例如，在单局游戏启动时，尝试UDP通信，如果失败，则回退至TCP，并且在整个进程生命周期内保持TCP通信；在单局游戏中，如果UDP通信发生错误，则重连时回退至TCP，并且在此局游戏过程中保持TCP通信，下一局游戏开始时依然优先采用UDP通信。

本发明实施例还提供了一种游戏客户端之间的通信装置，图8是根据本发明实施例提供的游戏客户端之间的通信装置的结构示意图(一)，如图8所示，该装置包括：

注册模块82，用于将确定的第一客户端的第一中继地址注册至第一服务器中，其中，第一服务器中还包括第二客户端注册的第二中继地址；

接收模块84，用于接收第一服务器发送的第二中继地址，其中，第一中继地址通过第一服务器发送至第二客户端；

建立模块86，用于利用第一中继地址和第二中继地址建立第一客户端与第二客户端之间的通信。

需要说明的是，利用第一中继地址和第二中继地址建立第一客户端与第二客户端之间的通信，用于确定将第一客户端与第二客户端之间的通信方式从第一通信方式转换为第二通信方式，其中，第一通信方式为第一客户端与第二客户端之间直接进行的通信，第二通信方式为第二客户端与第二客户端借助第一服务器进行的通信

在一个可选的实施例中，第一中继地址至与第一客户端连接的第二服务器基于网络协议分配的。第二中继地址是与第二客户端连接的第三服务器基于网络协议分配的。在中继地址交换问题上，第一服务器提供中继地址交换功能，第一服务器可以是一个第三方的服务，也可以是游戏服务自身。第一服务器与第二服务器可以是相同的服务器，也可以是不同的服务器。

在一个可选的实施例中，第二服务器与第三服务器，除了支持标准的基于TURN协议的数据转发功能之外，还需要提供保活机制和网络状况检查机制，来为服务器实现仲裁功能提供基础数据。

传统的保活机制通常是server/client任意一方发起保活协议，另一方接收到保活协议后回复一个保活协议。设定一个超时时间，任意一方在超时时间内没有收到保活协议，视作通信断开。在本实施例中，在确定与第二服务器之间的连接第一次断开时，在预定时间内恢复与第二服务器之间的连接；在确定与第二服务器之间的连接第二次断开时，标记第一客户端与第二服务器之间处于断开连接的状态。即二阶段保活：传统的保活机制只有一阶段，在通信状态中一旦保活失败则进入断开阶段；本实施例中的保活机制则有两阶段，一旦保活失败，先进入等待重连阶段；在重连阶段中，客户端重连恢复通信，则回到正常通信；再度保活失败则进入断开阶段；重连阶段向不主动向应用层通知客户端已断开通信，但要求仲裁时需要视客户端为已断开连接。

三向保活：传统保活机制的协议是一来一回的，本实施例是向第二服务器发送第一保活指令，其中，第一保活指令中包括第一客户端发送第一保活指令时的第一时间点；接收第二服务器发送的第二保活指令，其中，第二保活指令中包括第二服务器发送第二保活指令时的第二时间点和第一时间点；基于第一时间点和当前时间点计算出第一客户端与第二服务器之间的第一网络延迟时间；向第二服务器发送第三保活指令，其中，第三保活指令中包括第二时间点，以指示第二服务器基于第二时间点确定第一客户端与第二服务器之间的网络延迟；基于第一网络延迟时间处理第一客户端与第二服务器之间的网络延迟。第一保活指令、第二保活指令以及第三保活指令均是通过保活协议封装的。例如，由client发起保活协议1，保活协议1包含发起方的当前时间t1；第二服务器收到后回复保活协议2，保活协议2包含协议1中的发起方的时间数据t1，并再附带本方的当前时间t2；客户端收到保活协议2后，根据t1与本地当前时间，计算出网络延迟，再回复保活协议3，保活协议3包含时间t2；第二服务器收到保活协议3，根据t2与本地当前时间，计算出网络延迟。

另一部分仲裁内容是第二服务器判定网络状况，三向保活保证了第二服务器一定能拿到每次的网络延迟。通过设定两个阈值，阈值TL和阈值TA，当单次延迟时间L超过TL时，将此T累加到A，当A达到TL时，判定为网络质量下降到我们不能容忍的程度。

在一个可选的实施例中，第一客户端方面，还增加了协议回退的机制。即确定与第二服务器之间通过用户数据协议UDP协议进行通信；在确定与第二服务器之间的通信断开时，将UDP协议替换为传输控制协议TCP协议与服务器重新建立连接。

例如，在单局游戏启动时，尝试UDP通信，如果失败，则回退至TCP，并且在整个进程生命周期内保持TCP通信；在单局游戏中，如果UDP通信发生错误，则重连时回退至TCP，并且在此局游戏过程中保持TCP通信，下一局游戏开始时依然优先采用UDP通信。

综上所述，二阶段保活能够更准确地提供仲裁结果。在重连阶段中，游戏对战的其它参与方要求仲裁时，服务器会将在重连阶段的客户端视作断开。有一些带重连机制的服务也有此阶段，但通常应用层会将重连阶段视作客户端依然在通信中，但此时客户端实际上是没有通信的，如果视作通信中则会得到错误的判断结果。三向保活可以更全面地搜集服务器客户端之间的网络信息。传统的双向保活，只能让发起方搜集到网络延迟数据。因为服务器IP固定，一般UDP通信都是客户服发起保活，因此服务器不能获得网络状况。有玩家通过修改路由器的单向流量来干扰正常的通信，比如限制己方下行，对于特定游戏类型可以不正当获利。三向保活则能够避免上述情况的发生。

服务器网络状况检查机制，可以忽略网络波动以何种形式在时间上分布，从整体层面来判定网络状况，提供更为宏观的判定机制。

客户端协议回退机制，保证了尽量优先采用UDP协议，因为UDP协议的通信速率较TCP更优。大部分情况下玩家的网络环境是不会变化的，在游戏启动时，如果UDP不通，说明当前玩家网络不支持UDP的可能性更高，此时回退至TCP并保持整个进程生命周期更为合理。而在比赛中UDP通信失败，是网络临时变化或波动的可能性更高，因此只在单局游戏剩余时间内回退至TCP更为合理。

本发明实施例还提供了一种游戏客户端之间的通信装置，图9是根据本发明实施例提供的游戏客户端之间的通信装置的结构示意图(二)，如图9所示，该装置包括：

分配模块92，用于向第一客户端分配第一中继地址，以指示第一客户端向第一服务器注册第一中继地址；

确定模块94，用于在第一客户端与第二客户端之间利用第一中继地址和第二中继地址建立通信时，确定第一客户端与第二客户端之间的通信方式从第一通信方式转换为第二通信方式。

需要说明的是，第一通信方式为第一客户端与第二客户端之间直接进行的通信，第二通信方式为第二客户端与第二客户端借助第一服务器进行的通信。

在一个可选的实施例中，第二服务器向第一客户端分配第一中继地址包括：基于网络协议向第一客户端分配第一中继地址。

在一个可选的实施例中，第二服务器与第三服务器，除了支持标准的基于TURN协议的数据转发功能之外，还需要提供保活机制和网络状况检查机制，来为服务器实现仲裁功能提供基础数据。

传统的保活机制通常是server/client任意一方发起保活协议，另一方接收到保活协议后回复一个保活协议。设定一个超时时间，任意一方在超时时间内没有收到保活协议，视作通信断开。在本实施例中，在确定与第二服务器之间的连接第一次断开时，在预定时间内恢复与第二服务器之间的连接；在确定与第二服务器之间的连接第二次断开时，标记第一客户端与第二服务器之间处于断开连接的状态。即二阶段保活：传统的保活机制只有一阶段，在通信状态中一旦保活失败则进入断开阶段；本实施例中的保活机制则有两阶段，一旦保活失败，先进入等待重连阶段；在重连阶段中，客户端重连恢复通信，则回到正常通信；再度保活失败则进入断开阶段；重连阶段向不主动向应用层通知客户端已断开通信，但要求仲裁时需要视客户端为已断开连接。

三向保活：传统保活机制的协议是一来一回的，本实施例是向第二服务器发送第一保活指令，其中，第一保活指令中包括第一客户端发送第一保活指令时的第一时间点；接收第二服务器发送的第二保活指令，其中，第二保活指令中包括第二服务器发送第二保活指令时的第二时间点和第一时间点；基于第一时间点和当前时间点计算出第一客户端与第二服务器之间的第一网络延迟时间；向第二服务器发送第三保活指令，其中，第三保活指令中包括第二时间点，以指示第二服务器基于第二时间点确定第一客户端与服务器之间的网络延迟；基于第一网络延迟时间处理第一客户端与第二服务器之间的网络延迟。第一保活指令、第二保活指令以及第三保活指令均是通过保活协议封装的。例如，由client发起保活协议1，保活协议1包含发起方的当前时间t1；第二服务器收到后回复保活协议2，保活协议2包含协议1中的发起方的时间数据t1，并再附带本方的当前时间t2；客户端收到保活协议2后，根据t1与本地当前时间，计算出网络延迟，再回复保活协议3，保活协议3包含时间t2；第二服务器收到保活协议3，根据t2与本地当前时间，计算出网络延迟。

另一部分仲裁内容是服务器判定网络状况，三向保活保证了服务器一定能拿到每次的网络延迟。通过设定两个阈值，阈值TL和阈值TA，当单次延迟时间L超过TL时，将此T累加到A，当A达到TL时，判定为网络质量下降到我们不能容忍的程度。

在一个可选的实施例中，第一客户端方面，还增加了协议回退的机制。即确定与第二服务器之间通过用户数据协议UDP协议进行通信；在确定与第二服务器之间的通信断开时，将UDP协议替换为传输控制协议TCP协议与服务器重新建立连接。

例如，在单局游戏启动时，尝试UDP通信，如果失败，则回退至TCP，并且在整个进程生命周期内保持TCP通信；在单局游戏中，如果UDP通信发生错误，则重连时回退至TCP，并且在此局游戏过程中保持TCP通信，下一局游戏开始时依然优先采用UDP通信。

本发明的实施例还提供了一种存储介质，该存储介质中存储有计算机程序，其中，该计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。

可选地，在本实施例中，上述存储介质可以被设置为存储用于执行以上各步骤的计算机程序。

可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(Read-Only Memory，简称为ROM)、随机存取存储器(Random Access Memory，简称为RAM)、移动硬盘、磁碟或者光盘等各种可以存储计算机程序的介质。

本发明的实施例还提供了一种电子装置，包括存储器和处理器，该存储器中存储有计算机程序，该处理器被设置为运行计算机程序以执行上述任一项方法实施例中的步骤。

可选地，上述电子装置还可以包括传输设备以及输入输出设备，其中，该传输设备和上述处理器连接，该输入输出设备和上述处理器连接。

可选地，在本实施例中，上述处理器可以被设置为通过计算机程序执行以上各步骤。

可选地，本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例，本实施例在此不再赘述。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，可以为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (11)

1.一种游戏客户端之间的通信方法，其特征在于，包括：

将确定的第一客户端的第一中继地址注册至第一服务器中，其中，所述第一服务器中还包括第二客户端注册的第二中继地址；

接收所述第一服务器发送的所述第二中继地址，其中，所述第一中继地址通过所述第一服务器发送至所述第二客户端；

利用所述第一中继地址和所述第二中继地址建立所述第一客户端与所述第二客户端之间的通信；

所述方法还包括：确定将所述第一客户端与所述第二客户端之间的通信方式从第一通信方式转换为第二通信方式，其中，所述第一通信方式为所述第一客户端与所述第二客户端之间直接进行的通信，所述第二通信方式为所述第一客户端与所述第二客户端借助所述第一服务器进行的通信;

其中，所述方法还包括：接收与所述第一客户端连接的第二服务器基于网络协议分配的所述第一中继地址；

在利用所述第一中继地址和所述第二中继地址建立所述第一客户端与所述第二客户端之间的通信之后，向所述第二服务器发送第一保活指令，其中，所述第一保活指令中包括所述第一客户端发送所述第一保活指令时的第一时间点；

接收所述第二服务器发送的第二保活指令，其中，所述第二保活指令中包括所述第二服务器发送所述第二保活指令时的第二时间点和所述第一时间点；

基于所述第一时间点和当前时间点计算出所述第一客户端与所述第二服务器之间的第一网络延迟时间；

向所述第二服务器发送第三保活指令，其中，所述第三保活指令中包括所述第二时间点，以指示所述第二服务器基于所述第二时间点确定所述第一客户端与所述第二服务器之间的网络延迟；

基于所述第一网络延迟时间处理所述第一客户端与所述第二服务器之间的网络延迟；

其中，所述基于所述第一网络延迟时间处理所述第一客户端与所述第二服务器之间的网络延迟，包括：判断所述网络延迟是否超过第一预设阈值，如果所述网络延迟未超过所述第一预设阈值，则不做额外处理；

如果所述网络延迟超过所述第一预设阈值，则将所述网络延迟累加到累计异常延迟上，判断所述累计异常延迟是否超过第二预设阈值，如果所述累计异常延迟未超过所述第二预设阈值，则不做额外处理，如果所述累计异常延迟超过所述第二预设阈值，则确定所述第一客户端与所述第二服务器之间的状态为断开连接的状态。

2.根据权利要求1所述的方法，其特征在于，利用所述第一中继地址和所述第二中继地址建立所述第一客户端与所述第二客户端之间的通信之后，所述方法还包括：

在确定与所述第二服务器之间的连接第一次断开时，在预定时间内恢复与所述第二服务器之间的连接；

在确定与所述第二服务器之间的连接第二次断开时，标记所述第一客户端与所述第二服务器之间处于断开连接的状态。

3.根据权利要求1所述的方法，其特征在于，所述第一保活指令、第二保活指令以及所述第三保活指令均是通过保活协议封装的。

4.根据权利要求1所述的方法，其特征在于，利用所述第一中继地址和所述第二中继地址建立所述第一客户端与所述第二客户端之间的通信之后，所述方法还包括：

确定与第二服务器之间通过用户数据协议UDP协议进行通信；

在确定与所述第二服务器之间的通信断开时，将所述UDP协议替换为传输控制协议TCP协议与所述第二服务器重新建立连接。

5.一种游戏客户端之间的通信方法，其特征在于，包括：

确定第二服务器向第一客户端分配第一中继地址，以指示所述第一客户端向第一服务器注册所述第一中继地址；

在所述第一客户端与第二客户端之间利用第一中继地址和第二中继地址建立通信时，确定所述第一客户端与所述第二客户端之间的通信方式从第一通信方式转换为第二通信方式，其中，所述第一通信方式为所述第一客户端与所述第二客户端之间直接进行的通信，所述第二通信方式为所述第一客户端与所述第二客户端借助所述第一服务器进行的通信；

其中，确定所述第二服务器向所述第一客户端分配所述第一中继地址，包括：基于网络协议向所述第一客户端分配所述第一中继地址；

在确定所述第一客户端与所述第二客户端之间的通信方式从第一通信方式转换为第二通信方式之后，接收所述第一客户端发送的第一保活指令，其中，所述第一保活指令中包括所述第一客户端发送所述第一保活指令时的第一时间点；

向所述第一客户端发送第二保活指令，以指示所述第一客户端基于所述第二保活指令计算与所述第二服务器之间的网络延迟，其中，所述第二保活指令中包括所述第二服务器发送所述第二保活指令时的第二时间点和所述第一时间点；

接收所述第一客户端发送的第三保活指令，其中，所述第三保活指令中包括所述第二时间点；

基于所述第二时间点和当前时间点计算与所述第一客户端之间的第二网络延迟时间；

基于所述第二网络延迟时间处理所述第一客户端与所述第二服务器之间的网络延迟；

其中，所述基于所述第二网络延迟时间处理所述第一客户端与所述第二服务器之间的网络延迟，包括：判断所述网络延迟是否超过第一预设阈值，如果所述网络延迟未超过所述第一预设阈值，则不做额外处理；

如果所述网络延迟超过所述第一预设阈值，则将所述网络延迟累加到累计异常延迟上，判断所述累计异常延迟是否超过第二预设阈值，如果所述累计异常延迟未超过所述第二预设阈值，则不做额外处理，如果所述累计异常延迟超过所述第二预设阈值，则确定所述第一客户端与所述第二服务器之间的状态为断开连接的状态。

6.根据权利要求5所述的方法，其特征在于，在确定所述第一客户端与所述第二客户端之间的通信方式从第一通信方式转换为第二通信方式之后，所述方法还包括：

确定与所述第一客户端通过用户数据协议UDP协议进行通信；

在确定与所述第一客户端之间的连接断开时，将所述UDP协议替换为传输控制协议TCP协议与所述第一客户端重新建立连接进行通信。

7.根据权利要求5所述的方法，其特征在于，所述第一保活指令、第二保活指令以及所述第三保活指令均是通过保活协议封装的。

8.一种游戏客户端之间的通信装置，其特征在于，包括：

注册模块，用于将确定的第一客户端的第一中继地址注册至第一服务器中，其中，所述第一服务器中还包括第二客户端注册的第二中继地址；

接收模块，用于接收所述第一服务器发送的所述第二中继地址，其中，所述第一中继地址通过所述第一服务器发送至所述第二客户端；

建立模块，用于利用所述第一中继地址和所述第二中继地址建立所述第一客户端与所述第二客户端之间的通信；

所述装置还用于确定将所述第一客户端与所述第二客户端之间的通信方式从第一通信方式转换为第二通信方式，其中，所述第一通信方式为所述第一客户端与所述第二客户端之间直接进行的通信，所述第二通信方式为所述第一客户端与所述第二客户端借助所述第一服务器进行的通信；

其中，所述装置还用于接收与所述第一客户端连接的第二服务器基于网络协议分配的所述第一中继地址；

在利用所述第一中继地址和所述第二中继地址建立所述第一客户端与所述第二客户端之间的通信之后，向所述第二服务器发送第一保活指令，其中，所述第一保活指令中包括所述第一客户端发送所述第一保活指令时的第一时间点；

接收所述第二服务器发送的第二保活指令，其中，所述第二保活指令中包括所述第二服务器发送所述第二保活指令时的第二时间点和所述第一时间点；

基于所述第一时间点和当前时间点计算出所述第一客户端与所述第二服务器之间的第一网络延迟时间；

向所述第二服务器发送第三保活指令，其中，所述第三保活指令中包括所述第二时间点，以指示所述第二服务器基于所述第二时间点确定所述第一客户端与所述第二服务器之间的网络延迟；

基于所述第一网络延迟时间处理所述第一客户端与所述第二服务器之间的网络延迟；

其中，所述基于所述第一网络延迟时间处理所述第一客户端与所述第二服务器之间的网络延迟，包括：判断所述网络延迟是否超过第一预设阈值，如果所述网络延迟未超过所述第一预设阈值，则不做额外处理；

如果所述网络延迟超过所述第一预设阈值，则将所述网络延迟累加到累计异常延迟上，判断所述累计异常延迟是否超过第二预设阈值，如果所述累计异常延迟未超过所述第二预设阈值，则不做额外处理，如果所述累计异常延迟超过所述第二预设阈值，则确定所述第一客户端与所述第二服务器之间的状态为断开连接的状态。

9.一种游戏客户端之间的通信装置，其特征在于，包括：

分配模块，用于确定第二服务器向第一客户端分配第一中继地址，以指示所述第一客户端向第一服务器注册所述第一中继地址；

确定模块，用于在所述第一客户端与第二客户端之间利用第一中继地址和第二中继地址建立通信时，确定所述第一客户端与所述第二客户端之间的通信方式从第一通信方式转换为第二通信方式，其中，所述第一通信方式为所述第一客户端与所述第二客户端之间直接进行的通信，所述第二通信方式为所述第一客户端与所述第二客户端借助所述第一服务器进行的通信；

其中，确定第二服务器向第一客户端分配第一中继地址，以指示所述第一客户端向第一服务器注册所述第一中继地址，包括：基于网络协议向所述第一客户端分配所述第一中继地址；

在确定所述第一客户端与所述第二客户端之间的通信方式从第一通信方式转换为第二通信方式之后，接收所述第一客户端发送的第一保活指令，其中，所述第一保活指令中包括所述第一客户端发送所述第一保活指令时的第一时间点；

向所述第一客户端发送第二保活指令，以指示所述第一客户端基于所述第二保活指令计算与所述第二服务器之间的网络延迟，其中，所述第二保活指令中包括所述第二服务器发送所述第二保活指令时的第二时间点和所述第一时间点；

接收所述第一客户端发送的第三保活指令，其中，所述第三保活指令中包括所述第二时间点；

基于所述第二时间点和当前时间点计算与所述第一客户端之间的第二网络延迟时间；

基于所述第二网络延迟时间处理所述第一客户端与所述第二服务器之间的网络延迟；

其中，所述基于所述第二网络延迟时间处理所述第一客户端与所述第二服务器之间的网络延迟，包括：判断所述网络延迟是否超过第一预设阈值，如果所述网络延迟未超过所述第一预设阈值，则不做额外处理；

如果所述网络延迟超过所述第一预设阈值，则将所述网络延迟累加到累计异常延迟上，判断所述累计异常延迟是否超过第二预设阈值，如果所述累计异常延迟未超过所述第二预设阈值，则不做额外处理，如果所述累计异常延迟超过所述第二预设阈值，则确定所述第一客户端与所述第二服务器之间的状态为断开连接的状态。

10.一种存储介质，其特征在于，所述存储介质中存储有计算机程序，其中，所述计算机程序被设置为运行时执行所述权利要求1至4任一项中所述的方法，或者，执行所述权利要求5至7任一项中所述的方法。

11.一种电子装置，包括存储器和处理器，其特征在于，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行所述权利要求1至4任一项中所述的方法，或者，执行所述权利要求5至7任一项中所述的方法。

Images