收集并确定用例，这也是写这个笔记的目的，希望大家能提供宝贵的问题列表，讨论得出解决方案
1 [大重连] 和客户端和服务器的Session都已断开。此时希望玩家回到登录界面重新登录(而不是杀APP）。
解决方案：静默重建session，询问服务器当前账号状态，服务器可能如下回答，第一种：在维护，你登录不上来。第二种：已经有账号在线。第三种：没有账号在线，但是你的Player数据还存在。第四种：没账号在线，且Player数据也销毁了。大重连处理的是第四种回复。收到服务器回复直接切场景返回登录场景，走正规登录流程即可。
2 [保活重连] 客户端和服务器的Session都已断开，但是此时希望静默重连Session，自动走登录流程（而不是回到登录界面重新登录）
解决方案：静默重建session，询问服务器当前账号状态。还是那4种回复。只有第三种才能走“保活重连”，客户端不需要特殊逻辑，还是走正规流程即可。服务器触发保活机制，只需要重新绑定客户端session并且对player移除保活态组件。
3 [小重连] 客户端与服务器的Session没有断开，但是网络波动导致路由断开了。此时希望玩家无感知，网络波动后原地继续玩。此时需要完整有序地接受到所有网络波动期间的逻辑包。
解决方案：不必关注，ET底层已经处理，在以后的研究中，这种情况不必考虑。
4 [接电话] 游戏客户端切到后台，此时游戏的路由（socket）可能被操作系统强制断开。在ET框架下，应当分析此时路由是TCP路由还是Udp路由。给与不同的解决方案。
解决方案：返回APP焦点函数回调后，先检查当前主Session是否断开，没断开啥事没有，走"小重连"。如果Session断开，需要询问服务器账号状态，服务器还是四种回复，根据回复来走分支即可化解为讨论过的问题。”接电话“往往会被认为是一种简单的情况，其实是最复杂的情况。
5 [顶号登录] 游戏客户端A登录时，游戏客户端B以同一账号登录。此时希望A被自动踢下线，B正常登录。
解决方案：自动踢下线会造成连环飞踢，因此将需求改为询问是否踢下线（授权顶号，客户端A享受授权权利）。客户端A授权顶号后，服务器先会强制断开客户端B的Session，并且说明原因：被顶号，客户端B先收到原因后显示UI，UI中可能允许客户端B踢回去（此时客户端B享有授权权利，如果B选择顶号，则会造成流程锁的问题，所以拿出来研究）。Player无需摧毁，在Player的视角上来说，是”保活登录“的一种。A正常走流程登录。
细扣一下B踢回去会怎么样：我们简单对完整登录流程加协同锁即可，Type为LoginAccount，Id为账号：翻译成不这么好听的人话就是：我们要用协同锁保证了登录流程的原子性。因此，即使B马上踢回去，他的登录流程也会在A登录完毕后，才会执行。而不是与A穿插执行。
思维上分析混合造成的问题（请水友们开脑洞，Review一下~）
前边4种情况和【顶号登录】混合发生时，会造成不少问题
1 [接电话x顶号登录]：男主正在【接电话】，他老婆用另一个设备上了他的号玩，论男主接完电话后看游戏，合理的表现。合理的表现是：男主会收到一条已经被踢下线的通知，而不是发现自己被踢下线之后，反过来飞起一腿给他老婆的号也踢下线（至少要让男主确认，是否飞踹）
解决方案：一旦发生【接电话】，那么在返回APP时，询问Realm此时账号是否在线，以做出合法逻辑。推广可得，在完整登录流程中都要加入这个询问，如果当前账号在线，则要询问玩家是否将在线得苦主踢下去。
