如果您只想使用HTTP解决此问题,
long polling将是最好的方法.这很容易.首先,您需要在服务器端设置URL以进行通知(例如http://example.com/notify),并定义通知协议.协议可以像一些文本行一样简单,每行都是一个事件.例如,
MSG user1
PHOTO user2 album1
EMAIL user1
HEARTBEAT 300
手机上的轮询线程是这样的,
>建立与通知URL的HTTP连接.在J2ME中,您可以使用GCF HttpConnection.
>如果没有要推送的事件,服务器将阻止.
>如果服务器响应,则获取每一行并生成一个新线程以通知应用程序并回送到#1.
>如果连接因任何原因而关闭,请暂停一段时间并返回步骤1.
您必须注意以下实施细节,
>在客户端和服务器上调整HTTP超时.超时越长,效率越高.超时连接将导致重新连接.
>在手机和服务器上启用HTTP keepalive. TCP的3次握手在GPRS术语中很昂贵,所以尽量避免使用它.
>检测陈旧的连接.在移动环境中,很容易获得陈旧的HTTP连接(连接已经消失,但轮询线程仍在等待).您可以使用心跳恢复.说心跳率是5分钟.服务器应每5分钟发送一次通知.如果没有要推送的数据,只需发送HEARTBEAT即可.在电话上,如果5分钟内没有收到任何内容,则轮询线程应该尝试关闭并重新打开轮询连接.
>仔细处理连接错误.当存在连接问题时,长轮询不能很好地工作.如果处理不当,它可能是交易破坏者.例如,如果睡眠时间不够,您可以在步骤4中浪费大量数据包.如果可能,请检查手机上的GPRS可用性,并在GPRS无法使用时将轮询线程置于保持状态以节省电池电量.
>如果没有正确实施,服务器成本可能会非常高.例如,如果使用Java servlet,则每个正在运行的应用程序将至少具有一个相应的轮询连接及其线程.根据用户的数量,这可以快速杀死Tomcat :)您需要使用资源高效的技术,如Apache Mina.
我被告知还有其他更有效的方法可以将通知推送到手机,例如使用短信和一些IP级别的技巧.但是你要么必须做一些低级别的非便携式编程,要么遇到专利侵权的风险.使用仅HTTP解决方案,长轮询可能是最好的.