引用：taotao4580 发表于 2017-06-23 15:45
感谢耐心解答，问题大多明白了，还有些问题没搞清楚，可能我表达的不明白。还得麻烦下：

1.最开始的问题 ...

答案我已经回答的很仔细了，好吧，再补充一下吧：

1.最开始的问题，也是最重要的问题还没有解答，就是错误日志分析，我的问题出在哪里？不知我后续回答的内容对分析错误是否有帮助。
看到日志里显示你发送的对象的user_id都是-1吗？那表示你没有在客户端刷新它们的user_id，默认值就是-1，-1表示未定的user_id。

2.我问的第一个问题您提到客户端可以获得服务器维护的映射表，以更新自己和在线好友的userId，问下客户端怎么才能获得这个映射表呢？
服务端从你的db或redis里接出好友的列表后，通过你自已维护的上线用户表，把user_id填到你的好友列表再回传给客户端。

3.我的第二个问题您提到服务端OnVerify回调可以拿到extra，确实是的，但这时还没有分配userId。我要建立以userId为key，loginName为value的map，只有用ServerLancher里的getNextUserId接口了，里面的PLoginInfo对象包括我要的所有数据（也有extra）好像没有其他更好的办法了。
你可以做两个在线列表，一个是key=user_id、velue=loginName，一个是key=loginName、value=user_id，这样通过哪种方式不都能找到对应的结果吗。

4.问下重发次数和超时时间是多少。
看下源码。

5.IP地址218.244.55.14就在我上传的日志里，有很多，能帮看下日志里指的是什么的ip？
网络编程中，socket=ip+端口号，你同在一个局域网的话，ip当然都是一样，但端口一定是不一样。

感谢耐心解答，问题大多明白了，还有些问题没搞清楚，可能我表达的不明白。还得麻烦下：

1.最开始的问题，也是最重要的问题还没有解答，就是错误日志分析，我的问题出在哪里？不知我后续回答的内容对分析错误是否有帮助。

2.我问的第一个问题您提到客户端可以获得服务器维护的映射表，以更新自己和在线好友的userId，问下客户端怎么才能获得这个映射表呢？

3.我的第二个问题您提到服务端OnVerify回调可以拿到extra，确实是的，但这时还没有分配userId。我要建立以userId为key，loginName为value的map，只有用ServerLancher里的getNextUserId接口了，里面的PLoginInfo对象包括我要的所有数据（也有extra）好像没有其他更好的办法了。

4.问下重发次数和超时时间是多少。

5.IP地址218.244.55.14就在我上传的日志里，有很多，能帮看下日志里指的是什么的ip？

引用：taotao4580 发表于 2017-06-23 13:25
这里信息更新慢，还有几个问题一并问了，感谢耐心指导：
1.掉线重新登录和服务器重新登录回调接口完全一样 ...

我来一条条回复你：

1.掉线重新登录和服务器重新登录回调接口完全一样吧？只有上线、下线回调吧？
》客户端的调线重新登陆回调，主要用于你刷新好友列表的user_id和更新自已的user_id，因为重登陆后自已的user_id服务端理论上会重新分配新的，而在掉线的过程中可能好友的user_id也变了，所以要刷新好友列表的user_id。
》服务端的上线、下线回调可以用于你管理你自已的上线列表（上线就加进去、下线就从列表去掉），用户刷新好友的user_id时通过登陆名在这个列表里找就是了。

2.框架自动重新登录，那么一定记录了原来登录的用户名和密码，问下extra参数记录吗？
服务端是不会额外记录extra参数的，extra参数只有用户登陆（或掉线重登陆）时带过来（服务端的onVerify那个回调里可以拿到），所以如果要存储，你自已在你的在线列表维护时把它存储好就行了。

3.自动重新登录后的id好像有时是原id，有时是新的id，能否详细解释下？
如果你没有改过服务端的User_id生成算法，那重新登陆的话理论上一定会是新的（有一种情况下不是新的，就是重登陆包是重复发的，而服务端判定这个session还是有效的话的时，不会再生成新的，会把刚才的user_id再发回来就是了）。

4.框架已实现掉线重新登录，那么任何场景下，开发者都不需要再监听掉线回调（MessageQosEvent）并登录了吗？
掉线重连逻辑跟MessageQoSEvent没有关系，MessageQoSEvent只跟消息的送达事件有关。

5.自动重新登录是否有配置参数关掉？
自动重新登陆不能关掉，因为客户端掉线时，有时候可能是手机的网络发生了变化（比如从一个基站走到另一个基站）而发生了掉线，此时通过重新登陆才可能再次建立正常的socket，这是基于的移动端网络编程问题了，没有办法避免，移动网络跳变正常。

6.框架发送消息到达超时时间仍未收到指纹数据，会有自动重发机制，有参数配置重发次数和超时时间吗？
可以调置，但通常建议不要去动它就好了，现在的配置都是经过生产测试调优化后的结果，如果你没有更好的方案建议不要轻易去动它。重传和超时这些考虑不仅是送达，还要考虑性能负载等，所以没读懂算法前不要妄动。

7.我们应用场景是不需要离线发送的，有参数可关掉吗？
不需要离线处理的话，服务端的离线回调你不用管它就好了，你不处理它就会自动抛弃，默认代码就是这样的，log只是为了给你debug看的，你不处理它自已不会存（也没办法决定怎么存）。

8.我前面的日志里有客户端ip：218.244.55.14，在单位和家里都是这个ip，不应该呀
这是不可能的，框架没有这种能让你两个地方的网络保持同一个ip的能力，你一定是看错了。框架的网络层其实不复杂，你可以把它理解为一个简单的网络程序就是了，所以没有你想的这么复杂。

这里信息更新慢，还有几个问题一并问了，感谢耐心指导：
1.掉线重新登录和服务器重新登录回调接口完全一样吧？只有上线、下线回调吧？
2.框架自动重新登录，那么一定记录了原来登录的用户名和密码，问下extra参数记录吗？
3.自动重新登录后的id好像有时是原id，有时是新的id，能否详细解释下？
4.框架已实现掉线重新登录，那么任何场景下，开发者都不需要再监听掉线回调（MessageQosEvent）并登录了吗？
5.自动重新登录是否有配置参数关掉？
6.框架发送消息到达超时时间仍未收到指纹数据，会有自动重发机制，有参数配置重发次数和超时时间吗？
7.我们应用场景是不需要离线发送的，有参数可关掉吗？
8.我前面的日志里有客户端ip：218.244.55.14，在单位和家里都是这个ip，不应该呀

userId的map表掉线重连时没有处理。问下：掉线重连是框架自动进行的，框架会记录原来登录的loginName和password，但extra字段会记录吗？

用户我用extra字段在登录时分辨，也是登录时新建userId的map表，但登出时没有extra字段，我直接查map表里是否有userId，如果有，就从map表里删除。上线回调由于没有extra字段，我没有处理。

我看核心是好友列表自己维护userId的问题。是这样的，服务器端我分用户类型的，一类用户我维护了userId，但只有登入登出维护；一类用户我没有管理userId。

Ok，看完你的日志了，大致猜出问题所在了，你先回答我几个问题，我再确定是否是我想的问题。

1）你现在做的是否是客户端有好友列表这种东西的全功能IM？
2）如果是全功能IM，则好友列表里的user_id什么时候刷新的？只在登陆成功后取一次最新的user_id吗？
3）这个好友列表里的user_id怎么来的？服务端你自已通过上、下线回调自已维护了一个在线列表（主要是保存user_id列表）吗？
4）客户端的掉线重连的情况下有没有刷新当前在线好友（或所有好友）的user_id？

请仔细回答我上述问题后，我告诉你病因！

这日志看起来有点奇怪，我来帮你看看。
理论上服务端重启没有关系（而框架在设计时也考虑这一点，对于框架而言，重启后的恢复意味是框架健壮性的一部分，是必然会考虑和解决好的），即使客户端状态丢了也不要紧，因为客服端接下来会把它作为掉线重连处理，接着就能重连成功。