Pushlet的工作原理

在介绍comet的基本理论之后，pushlet是comet的一种实现，它主要利用Servlet容器（Tomcat和Jetty）在Servlet没有运行完毕（线程一直没有运行完毕），server不会主动关闭连接，这给web的进行长连接由server push data 到client端提供了基本的理论依据。

 

注：本文在修改之前说的Com是利用keep-alive功能，server不会主动关闭连接，这个说法经过笔者实践有点错误。我们知道在Tomcat线程模型图如下（BIO的方式）：

阻塞式的IO的线程模型是，一个请求会用一个线程维护一个socket，以阻塞的方式读取数据。当socketServer accept客户端的请求后，会生成一个新的socket，同时从线程池中拿出一个线程attach到这个socket上。当Servlet的线程未完毕时，socket即使在keep-alive关闭的情况下，Tomcat也不会关闭socket，显然这种方式对Comet而言，不是很好的方式，因为一个线程维护一个socket，本身就是开销比较大。Pushlet同样是利用Servlet的工作线程，对于一个user维护一个这样的线程，pushlet的性能在高并发的情况下，线程开销较大，性能肯定是不好的，因此，有必要看看Tomcat里面对于Comet的支持了。

 

 

Pushlet作为一种comet理论的实现，其工作原理也比较简单，笔者花了两天时间看了它的源码，总结了它的工作原理如下图：

 

 

1.browser发送join命令到server，server产生唯一的ID给client端，用于标识这次会话的唯一性，Pushlet是用java.rmi.server.UID产生的唯一的标志会话的标志，此时server会把sessionID作为key，session对象作为value，存放到HashMap里面，然后通过response.getWriter().println()回调给browser

 

注意：server接收client的请求是通过一个统一的servlet入口，pushlet.java来接收，下同。

 

2.browser拿到sessionID，并发送listen命令，listen命令，有subject，提交给server，server首先验证Session HashMap里面有没有这个sessionID，验证通过后，回调给客户端listen_ack消息，同时开始从eventQueue取出数据，并update给客户端，这里的queue符合生产消费模式，eventsource是生产线程，它负责把数据enqueue入队列，如果满则等待，直到消费线程消费，消费线程负责消费，由于eventsource是sleep一段时间才enqueue，消费线程没有sleep，它采取的是while（alive）的方式，因此，从这里来说，消费速度应该快于生产速度的。