有效的沟通非常重要
下面将描述一下今天发生的案例。
这些日子客户端开发和测试人员反馈，APP程序经常跳转到登录页面。从他们的描述中我一直以为都是Session Token过期造成。
服务器是这样设计的：
服务器提供维护Token和websocket之间的关系。
token 生成和 websoket连接建立不区分先后顺序。
但websocket一旦断开，就会清空session和token
这里存在一个问题，每次打开APP，APP会记住上次打开页面，并实现自动登录。如果这个页面有好多API请求返回的数据组成，那么同一时刻，可能发起好多HTTP请求,这些API都会返回Token无效。 就会发起HTTP登录请求。这样就会返回多个token,其实这里完全可以忽略，因为websocket只建立一次，只管把每次的返回token通过websocket发送到服务器即可。
(client) (server)
| |
|-------http request -------------------> |
| | 生成token并返回给客户端，
| | 以后客户需要用此token表示身份
|-------http request2-------------------> | 并通过websocket发送到服务器来建立关联
| |
| |
|<------- response1--------------------- |
| |
| |
|<------- response2--------------------- |
| ｜
|
按照以上原则是没有问题的。
事实客户端请求时没有遵循以上原则，比如建立了多次websocket连接。
客户端曾反馈过，说请求死循环，我一直以为是这里的http请求出现死循环。当时也许是他们没有说清楚，也许是我自己以为，但我应该继续追问（在实际工作中，继续追问常常会惹人厌烦的）。
仔细核对客户端提供的日志，发现日志中出现大量relogin信息，并且都是1s后又继续尝试登录。登录超过规定次数后，客户端会把原先缓存在手机中的密码和用户名清空的。这时候就会出现类手动似注销效果，跳转到登录页面。
这里的重复登录其实就应该是客户端人员反馈的死循环请求问题。
同样的问题，测试人员反馈的是应用程序总是自动注销。
看到relogin日志后，很明显是因为第一次自动登录API，请求后一直没有返回数据造成的应用程序自动注销的假象。
分析到这里，问题定位在登录API上了。
要么客户端的请求服务器没有收到，例如断网的情况下（相信客户端人员会处理过此情况），
要么服务起相应客户端的时间超过了服务器的等待时间，如果是这样，这个API存在大缺陷。
问题到这里大家该干嘛的干嘛了，看来我先前说在下个版本分离token和websocket 说的过早了，惹祸上身。
眼看快下班了，讨论的那些方案个人感觉不靠普。在各方压力之下，我只好放弃先前的设计，取消了断开websocket清空session token功能。这样当然会引起其他问题的。比如：无用的token是否越来越多，一个用户多个设备登录问题等等，怎么去实现等等。 之前都已经考虑过，才采取断开websocket清空的。当下没那么多时间去考虑了，什么样的要求，就有什么样的结果。再说了架构马上又要变了，重构后自然就没这问题了。 只是......
该洗洗睡了。