Tigase 如何避免丢失消息

     转载自： http://www.cnblogs.com/apem/p/4367365.html 

       即时通讯网上有第三方的解决方案，比如环信，融云等。我们是自己搭的xmpp服务器，服务器使用的tigase，之前写过相关的博客，自己去年也做了对应的webim。前段时间看了环信webim的sdk，使用的也是strophe的js类库，相关实现跟我们的差不多，但是自己搭建xmpp会遇到了不少问题，比如丢消息！所以如果想比较快速的实现im，推荐使用第三方的解决方案。 

       移动端的丢消息大概是这个样子。A和B通讯，A发了一条消息给服务器，服务器发给B，但是B网络不好掉线了，而服务器却不知道B退出了（B正常退出会给服务器发下线通知），所以消息丢失了。XMPP中有xep-0184协议（消息回执），A给B发消息，消息体中带一行代码（要求消息回执），当B收到消息后发送一条回执，证明我收到了。后来XMPP又有了xep-0198协议（流管理），断线后快速重链，同时判断一定时间收不到消息，就把消息写离线消息，减少丢消息情况。但是可能网络情况复杂，加上各种不确定因素，还会出现丢消息的问题。

        目前比较靠谱的方法就是存所有的聊天记录，由手机端根据时间点去数据库拉消息，只要别人发出的消息就不会丢。这次即时通讯模块进行了相关改动，也是参考了之前开发人员的一些建议。比如用户返回home的时候，断开xmpp连接（iOS进入后台后，只有5秒的处理时间，特殊方法可延长到10分钟，如果内存不够，应用随时就被杀死了）。所以返回home时就断开，进入应用再连接。同时应用使用状态下，有心跳检测，判断是否保持连接。考虑到iOS的特殊性，我们采取了xmpp和远程推送都走的方法，推送的自定义消息体和xmpp消息体一样，消息的处理方法一样。用户聊天发送xmpp消息的同时也调用我们的消息推送接口调用友盟push（push可以设置过期时间，避免特殊情况，推送延时，聊天结束了才收到推送）。一是解决iOS应用未启动时的推送接收，二是解决xmpp丢消息的问题。关于推送，AppDelage中有两个方法，一个是使用中收到推送，不会提示，会直接处理推送信息。另外是程序非使用状态，收到推送，会进行提示，可以点击推送消息进入应用，获取这一条推送消息的推送消息（需要注意，点击推送启动应用拿到信息时view还没有加载，消息不能立刻处理）。 android端因为是真后台，可以后台一直保持运行，无论收到xmpp消息还是友盟推送，都可以自己进行处理，然后自己弹一个本地推送（也有弊端，如果android程序杀死，就无法接受消息和推送）。iOS端因为后台不可控，所以推送使用远程推送，进入应用连接xmpp再收全部离线消息（不保证友盟推送能否保证及时）。当然大部分都还是正常情况，网络情况比较好的条件下，就实时收到了xmpp的消息或者远程推送。我们又不是QQ和微信，只要保证用户看到的数据能保持一致性就行了（所以QQ和微信就是diao啊）。根据测试反馈的情况，iOS这个应用的丢消息情况比上个应用有一定改善。具体情况再进一步观察把。我们的即时通讯也包括语音和图片，采用的是http的解决方案（xmpp也支持二进制的传输，但是估计没人那样用）。具体流程就是先把附件传到附件服务器拿到附件服务器的地址，再封装到消息体。接收方收到消息解析的时候，再从附件服务器拿到对应的资源，加载到本地。同时屏蔽，取消屏蔽等一些实时操作也都会发xmpp，第一时间双方更新状态。