文章搜索:

腾讯某百万大作的弱网处理及断线重连方案

2017-10-09 13:54:57   阅读

一 背景及问题描述

这款游戏采用的是TCP长连接方式,消息交互使用的是TDR方案,弱网问题以及断线重连的情况在手游运营中都是非常普遍的,也会相互交叉出现。这款游戏属于比较重度的RPG手游,玩家在实际游戏过程中更容易碰到“网络差”,“掉线重登”等情况,最常见的一个场景是玩家正在酣畅淋漓的闯关副本,结果此时网络不稳定,导致玩家掉线需要重登再来打一次副本,会直接造成容忍度比较低的玩家流失,游戏口碑也会受到影响。

此游戏的一个副本玩法中会有多个版面,玩家只有清掉前一个版面的所有敌人后才能请求进入下个版面,服务器才会下发下个版面的敌人信息给客户端。炫斗早期没有对下行包进行管理和缓存,很容易出现玩家清完一个版面的所有敌人后请求进入下个版面时断线了导致没有收到服务器下发的回复包,所以会出现客户端重连成功了但是卡在当前版面进入不了后面的流程,体验会非常差。

针对上面出现的问题,在服务器端专门针对断线重连做了相应的优化,在服务器设置了下行包缓存机制,这样重连上来后,服务器会判断客户端是否有丢失下行包,丢失了多少包,会把所有丢失的包再push给客户端一次,保证客户端能够继续前面断线时的流程。对于玩家来说,这个重连过程是透明的,能够有效提升玩家的游戏体验。下文也主要是针对这个优化进行描述,如有疏漏之处也请各位大侠指正。

二 弱网处理

1 上行包包序

客户端维护上行包的包序,服务器会记录下最近一次客户端的上行包的包序,如果客户端上报的上行包包序小于等于记录的时,服务器判断为重复发包的行为,会做丢包处理,防止重复处理同一个包的情况,造成客户端数据异常。比如:客户端购买商品之类的消息,如果不判断重复包的话,会造成多次扣费的可能,让玩家造成经济损失。

此游戏的服务器端会严格校验上行包的包序,通过判断上行包的包序跟服务器记录的上次的包序大小来判断该消息是否已经处理,处理过的消息将被直接丢弃,如果客户端一直收不到消息会走断线重连的方式,到时会收到服务器在断线期间为它缓存的所有消息。

2 下行包包序

服务器维护下行包的包序,客户端同样通过判断服务器的下行包包序来做对应处理,过滤已经处理过的下行包,防止出现数值和界面异常的情况

三 断线重连

客户端会保存最近一次收到的下行包的包序,每个Player的下行包的包序由服务器维护,如果客户端需要重连登录时,需要带上这个包序给服务器。

客户端正常情况下会先连目录服务器,选择小区后自行选择一台gamesvrd登录,之后客户端如果断线会直连上次登录过的gamesvrd,走重连流程。

下图为客户端断线重连时,直连gamesvrd的情况。

客户端的断线重连流程如下,关键的步骤为判断客户端上报的下行包包序,以及下发缓存池中的满足条件的下行包。

过滤过旧的消息以及下发满足条件的cache消息时都不移动BeginBuf, 只需要记录下一个tempBeginBuf,整个过程移动tempBeginBuf即可,这样做是因为实际上客户端处在网络不稳定时,有一定几率会持续重连失败,等到客户端再次重连时,缓存的消息可以再次被下发,不会遗漏关键的消息。

有了缓存机制后的断线重连,对于像这类RPG游戏来说,游戏体验会提升很多,玩家进入单局副本如果断线了,重连之后又能收到前面断线期间丢失的包,重新继续单局后面的流程,整个过程对于玩家来说是透明的,重连过程丝滑顺畅。

四 缓存机制

消息缓存是整个机制的核心部分,在本章节先对存储结构详细介绍下,服务器端在每个player对象内开辟块专门的下行包的缓存池,CS各个消息大小差异巨大,每一个下行包都经过TDR的pack方法后再存入缓存池,以节约内存。

4.1 结构设计


上一篇:智能发展的“天津方案”产业基础做支撑
下一篇:吉林省轻纺产业转型升级实施方案