用 PHPRPC 如何实现 Comet 效果

icewubin 写道

andot 写道

最后，PHPRPC 不仅仅用于 JavaScript 到 Java 的通讯，因此 Comet 这种方式不直接提供支持，但是使用 PHPRPC 你仍然可以做到这种效果。

很感兴趣，不用JS客户端轮询的方式，能做到服务端推么？难道是不断开的HTTP长连接（目前的Comet好像都是这样的）？

嗯，是类似轮询方式，但无需定时频繁轮询。

目前的 Comet 实现好一点的是，客户端发送一个请求后，服务器以 chunked 编码方式返回数据，但是不返回 chunked 结束标示，因为 chunked 编码可以分块发生分块接收，因此客户端可以收到一部分执行一部分，如果以后服务器有消息会继续通过这个连接发送后续的 chunked 编码。这种方式唯一的好处是，在最大程度的减少了 http 请求的数量的情况下，保证服务器消息到客户端传递的实时性。

而 PHPRPC 是一个类似于调用本地函数一样的 RPC 协议，所以，不可能一个调用，分多次返回多个结果，一次只有一个完整结果。但是 PHPRPC 是支持 Keep-alive 连接的，也就是一个 HTTP 请求结束之后，实际的 TCP 连接并不断掉，下次请求仍然可以复用该 TCP 连接。因此，可以采用以下方式模拟 Comet 行为：

首先，也是客户端向服务器端进行调用，但是服务器端如果没有需要返回的消息，就挂起等待，而不返回数据，直到有数据可用时或者超过某个时间设定阈值时，再返回结果。而客户端在收到并处理完服务器端返回的结果后，立即发送下一次调用请求，因此可以复用 Keep-alive 连接，同时也保证了数据的实时性，还保证了无需定时轮询。唯一比 chunked 方式差一点的地方就是每次都会有一个请求。但实际上一般请求的数据都是远远小于返回的数据的，基本上可以忽略不计。这样就可以做到 Comet 效果了。通过对 Gmail 中的 Gtalk 抓包进行分析，发现也是这种方式来实现的。

不过我不认为基于 HTTP 协议来做 Comet 会带来很大好处，毕竟一台服务器能够承受的总连接数是有限的，Comet 会大量占用并浪费这些宝贵的连接资源。使原本可以服务于几万甚至几十万人的服务器只能服务于几千人，这是对服务器的极大浪费。我认为只有 UDP 协议才适合做这种服务，它既可以保证数据实时性，又可以最大限度的节省服务器资源。不过除了 ActiveX 以外，好像还没有那种浏览器端的技术支持 UDP 编程。