本文介绍了移动游戏中实现断线重连的机制，包括TCP和HTTP连接方式、断线重连策略（静默重连、显式重连、服务器故障重连）以及重连后的处理，确保玩家在断线后能无缝返回游戏，提供良好的用户体验。
网络游戏-断线重连
1、背景
移动网络信号波动频繁，给移动游戏开发者带来诸多困扰，处理不好会造成较差的用户体验以及重复扣道具等严重问题
2、网络连接方式
通常游戏客户端都是通过创建socket与服务器取得连接，但也会根据使用场景划分成两种连接方式：TCP连接和HTTP连接。
1) TCP连接即我们常说的长连接。这种连接方式下socket连接一旦建立，通信双方即可相互发送数据，直到一方终止连接。目前公司的移动端联网游戏多采用这种数据通讯方式。
2) HTTP连接即我们常说的短连接。这种连接采用的是“请求-响应”的通讯方式，每次交互由客户端发起请求，服务器收到请求后才能回复数据，数据传输完成后，socket连接便断开。在下载CDN资源或云配置时通常会采用这种连接方式。
3、断线重连机制
当检测到断线后，便可以启动重连模式。根据当前的游戏状态确定重连策略，一般有以下三种方式：
1) 静默重连，即在用户无感知的情况下进行重连。一般检测到断线后，可以先尝试静默重连一定次数（比如3次）。如果在游戏对战过程中断线，一般也会尽量尝试静默重连并且忽略重连次数，因为此时弹出提示框会打断对战体验的完整性。静默重连提供了一种友好的用户体验，能应付一些短暂的网络中断（比如进出电梯或者进程从后台唤醒等）。
2) 显式重连，在静默重连一定次数（假定3次）之后，仍然无法连接成功的情况下，此时需要弹出提示框，中断游戏流程，告知用户当前网络环境较差，引导用户在网络较好时再尝试连接。
3) 服务器故障重连，这种情况下客户端无论如何是连接不到游戏服务器的。此时客户端也需要给出正确的引导，而不是误当作断线故障处理。因此我们在断线重连失败之后多加一个步骤：尝试连接CDN（Content Delivery Network，即内容分发网络）服务器，若CDN服务器可以正常连接，那么说明网络畅通，我们去获取CDN上的云配置，检查是否有服务器日常维护的标识，如果有则给出服务器日常维护的公告，否则可以认为服务器宕机，则给出服务器故障的公告。此步骤中若CDN服务器也无法连接，说明网络确实不畅通，可以继续走重连流程或者等待。
4、重连后的相关处理
在程序断线重连的过程中除非重连失败，否则最理想的情况是希望玩家在断线前后无感知，可以流畅的继续游戏而不受到断线的影响。
1 对于大厅的后续处理
A.拉取相关属性和物品。再重新连接后，由于在断开过程中可能会有相关数据的变化，会拉取人物相关属性和物品
B.重发断线前的相关请求：这个和具体的系统相关，如果断线前的系统进行的是一些对数据敏感的操作，比如合成物品，购买物品等，在发起的时候会做无法二次点击的处理并加入到重发列表中，在网络恢复之后重发。此时如果服务器未做处理便会直接处理，如果做了处理需要服务器忽略（注，这个需要服务器配合）
2对于战斗的后续处理
A．重新拉取战斗状态数据：这个是由于我们游戏是对战斗实时性要求较高的游戏，所以在断线过程中的战斗状态可能会发生很大的改变，这些改变必须需要重新同步，比如可能会死亡，球变大或变小，位置改变等都有可能，所以在重连之后，我们是全量拉取玩家战斗数据，同步到最新的状态。
5、对重连的一些说明
在战斗过程中，其实还伴随这大厅这个连接，所以很多情况下，战斗连接的断开也会伴随着大厅连接的同时断开。对此，我们对于不同连接建立不同的重连器，从而达到两个连接相互独立，无论只是单个连接的断开还是两者同时断开，都不会相互影响，各自走各自的重连过程。
参考：
扫一扫
3万+
到【灌水乐园】发言
