６、重连后的相关处理在程序断线重连的过程中除非重连失败，否则最理想的情况是希望玩家在断线前后无感知，可以流畅的继续游戏而不受到断线的影响。1 对于大厅的后续处理A.拉取相关属性和物品。再重新连接后，由于在断开过程中可能会有相关数据的变化，会拉取人物相关属性和物品B.重发断线前的相关请求：这个和具体的系统相关，如果断线前的系统进行的是一些对数据敏感的操作，比如合成物品，购买物品等，在发起的时候会做无法二次点击的处理并加入到重发列表中，在网络恢复之后重发。此时如果服务器未做处理便会直接处理，如果做了处理需要服务器忽略（注，这个需要服务器配合）2对于战斗的后续处理A．重新拉取战斗状态数据：这个是由于我们游戏是对战斗实时性要求较高的游戏，所以在断线过程中的战斗状态可能会发生很大的改变，这些改变必须需要重新同步，比如可能会死亡，球变大或变小，位置改变等都有可能，所以在重连之后，我们是全量拉取玩家战斗数据，同步到最新的状态。7、对重连的一些说明在战斗过程中，其实还伴随这大厅这个连接，所以很多情况下，战斗连接的断开也会伴随着大厅连接的同时断开。对此，我们对于不同连接建立不同的重连器，从而达到两个连接相互独立，无论只是单个连接的断开还是两者同时断开，都不会相互影响，各自走各自的重连过程。8、对之前版本游戏更加容易掉线的一些思考虽然其实很多时候确实是wifi不稳定导致的网络问题，但之前版本确实比其他游戏更容易掉线，具体体现在在同一个网络下，两个差不多的手机，玩我们游戏的时候掉线的频率更高，对此以下是我的一些想法。对于网络经常触发异常的原因，除了网络本身的不稳定外，主要还是TCP协议中，客户端缓冲区在网络不稳定的时候容易写满导致的问题。对于这个问题，一方面可以适当的扩大缓冲区的大小，对此把客户端网络的缓冲区扩大，从1024*100，扩大到1024*2000，也确实改善了游戏的网络状况。但这种方式只是并没有从本质上解决这个问题，网络其实的压力还是很大，流量过大也是我们遇到的问题之一。由于包头和TCP持续计时器的原因，在每个包的包头都会有一些不属于游戏协议内容的造成的流量，对于一些能够合并到一起发送的小包，合并小包和减少包量可以很大幅度的减少流量。而且也容易避免由于滑动窗口可发送部分的迅速充满导致的网络拥塞。另一方面，单个包的大小过大也会迅速的撑大缓冲区，而且在传输过程中造成传输峰值，造成网络延迟，拆分过大的包，比如一瞬间全量拉取排行榜等的数据通过分批拉取，减缓网络压力，也能达到优化网络的目的。9、对于为什么会有wait状态其实对于一般的想法来说，其实断线重连只需要Start，Reconnect，End三种状态，确实，这三种状态可以把整个断线重连的过程完成，对于wait，主要一下几个原因。Wait 状态和Reconnect状态的区别在于Wait状态手机网络并没有连接，而Reconnect状态的网络已经恢复了，这个其实是有差别的，可以对网络的状态进行不同的处理。因为由于一些原因（比如在wait状态可能由于Apollo错误原因而无法收到网络恢复的消息等）我们也低频尝试了重新和服务器建立连接，但是其目的是发现是否能够建立连接，更多的时候会返回失败的消息，是一种double check 的保证策略，而Reconnect状态下的重连是我们知道了网络已经恢复，尝试去连接服务器，目的是为了真正的建立连接，这两种情况无论在目的上还是在连接的频率上都有差别，而且将两个状态区分便于我们在不同状态下做不同处理