近日,由于工作上要用到即时推送的技术,翻阅了许多资料,其中有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。大大的改善了轮询所带来的弊端。