近日，由于工作上要用到即时推送的技术，翻阅了许多资料，其中有androidpn、C2DM(android Cloud to Device Messaging)、MQTT和RSMB，从中发现大多数即时推送消息协议框架的服务器底层都是采用XMPP协议进行封装。于是，顺藤摸瓜的发现了一个原生框架-openfire。

项目的雏形来源于车载预警系统。该系统保证车载设备及时获取服务器上最新的消息。一旦车辆发生突发事件时，车载设备就发送出一个预警信号到服务端进行处理。服务端处理完成后将预警信息发送到离当前车辆最近的车辆上。具体工作模式如下：

场景：车辆在行驶或者静止时发生突发的状况,并且中断与车载预警系统的连接。

步骤一：正常行驶

车载设备A–>发送真实地理———————————————>车载预警系统（保持长期链接）

 

车载预警系统<——————————————– 车载设备A

<——————————————– 车载设备B

<——————————————– 车载设备C

步骤二：发生预警突发状况

车载设备A(突发状况)-〉发送预警消息（包含当前坐标、预警消息、语音呼叫）————————————————–>车载预警系统

 

车载预警系统

<——————————————– 车载设备B

<——————————————– 车载设备C

步骤三：准备推送

车载预警系统(接收到预警信息)<—————————–车载设备A(突发状况)

车载预警系统->接收到预警信息->存储预警信息->获取周边车载设备->判断方位->处理方位-〉准备推送。

 

步骤四：推送数据

车载预警系统————————————————-〉车载B                                                                      车载C

注意：

—-> 代表长链接方式

->代表步骤

对于这种场景来讲，有两种方案：第一种是客户端使用Pull（拉）的方式，就是隔一段时间就去服务器上获取一下信息，看是否有更新的信息出现。第二种就是服务器使用Push（推送）的方式，当服务器端有新信息了，则把最新的信息Push到客户端上。这样，客户端就能自动的接收到消息。

对于这两种方案，业界还是比较赞成push的方式。因为Pull方式必须要考虑到轮训的频率，如果太慢都可能导致某些消息的延迟，如果太快，则会大量的消耗网络带宽。push方式，可以在CPU休眠时正常运行，在预设的时间到达时，通过中断唤醒CPU。大大的改善了轮询所带来的弊端。