zz: comet

_Comet：__一种编程技术，使用它可以在Web Server上向client发送数据而无须来自client的请求。使用此技术可以建立定位于浏览器上的“事件驱动Web应用”。
!!动机：
传统的Web应用仅在client发出请求后才把页面发送回去。对于每个client请求，浏览器进行连接到Web Server的Http连接的初始化工作，当数据返回后这个连接便被关闭了。这种方式的缺点是只有在用户明确地刷新页面或是转移到新页面时被显示的页面才被更新。由于传输这个页面需要一段较长的时间，刷新页面便要花费一段较长的延迟。为了解决这个问题，AJAX被用来通过使Web浏览器只对页面中需要改变的部分发出请求的方式减少数据的更新量。因为传输数据总量被减少了，延迟也相应减少了，整个web站点的反应能力增强了。进一步讲，通过使用异步后台数据传输，当数据正在被接收时用户部分地接收数据，这样Web应用的反应能力被进一步提高了。
但是这样的实践也遇到了一个问题：client必须在请求发送到 Server之前发出一些数据请求。在设计那些需要等待Server端事件发生的应用时（例如一些用户发送数据到Server，在Server处理这些请求之前、事件将发生之前没有任何信息产生），这个问题成为了主要障碍。
一种解决方案被设计出来：应用周期性地轮询Server已发现是否有事件发生。但这不是优雅的：因为应用将浪费大量的时间来对事件完成情况的查询，因此它直接对应用的回应能力造成了破坏。另外，一些网络带宽也被浪费掉了。
一种更好的解决方案：服务器在事件发生时发送消息给client，而不需要client进行询问。这样client将不再周期性地检查server；它能够继续其它的工作并处理事件发生后被server推送过来的数据。这就是Comet所实现的。
Netscape [server push|http://www.it315.org/articles/web/web1.htm]浏览器扩展就是这样的解决方案，但它不与Internet Explorer等其它的浏览器相兼容。
!!技术：
与在Web Server与浏览器之间的一般数据传输不同，使用Comet完成到Server的连接需要特定的结构。Client端应用必须在异步初始化到 Server的连接时保持工作。在Server端，即使不能马上对请求做出回应，连接也要保持直到所期待的事件发生。当事件发生时，server通过之前已经建立的连接把产生的数据推送到client。
连接在此后可能被切断，或者当存在并发事件时可以被保持下去。如果存在并发的多个事件，Server可在此连接上发送事件数据而无须client每次都明确地发送请求。
!!可测量性和可靠性：
这里存在一些潜在的概念：认为一个实现了Comet的Web Server具有很好可测量性。因为连接被保持直到事件发生，所以如果事件不频繁地发生，它能应付一定的连接。但如果不同的连接等待不同的事件，那么这个问题将更糟。管理这样大量连接引发了可观的系统负载。但是Server和其它支持应用正在被开发来更好的支持这样的长连接。
[AJAX/Comet Request Router|http://rphd.sourceforge.net/]是一种机制：提供可测量的Server端（支持低延迟异步和双向的Comet 应用）。它被用作针对任何web或者应用Server的前端，用于部署client请求到某个匹配的Server，这个Server可能是一个特定的程序或者一个针对相应的请求而执行特定应用代码的、通用的Server。[Java Jetty|http://www.mortbay.org/]和[Apache 2.2|http://httpd.apache.org/]提供在使用异步网络操作情况下的内在的支持，它可以减少连接管理上的overhead。这样的话，Web Server逻辑仅在事件发生时发送消息给用户。由于多数操作系统都具有事件驱动I/O子系统，所以这不成问题。
防火墙和HTTP代理在浏览器和Web Server之间能够造成进一步的网络问题。防火墙常常被配置为丢弃超长时间的连接，因此一些商业品质的框架被迫拆卸、重建周期性的“push”连接。而 HTTP代理可能缓冲32Kb或者64Kb的推送信息，无奈之下用来适配检测代理缓冲区大小的系统称为了必要之物。
浏览器造成了进一步的限制：[HTTP1.1规范的8.1.4章节|http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html]说明：“一个单独用户的 client不应该对同一Server或者代理服务器维护两个以上的连接”，这被大多数常见的浏览器（包括Internet Explore盒Firefox）作为推荐。保有一个为HTTP流而打开的连接之做法对于AJAX应用来言是建立了一个性能问题，这样就没有能力在一系列图片被装载时启动一个新的用户发起的数据请求。这个问题常被这样绕过：在推送连接时建立不同的主机名（虽然是同一个物理主机）。在集群Server环境下，信息需要被路由到当前正连接到指定client的Web Server上，有保证的传送需要在Web Server宕机事件发生时被确认。这由典型的管理面向中间件系统（常常被JMS封装）处理。
!!Comet实现：
* [Virgil's One™|http://one.virgil.nl/]
* [SmartClient|http://smartclient.com/]
* [Lightstreamer|http://www.lightstreamer.com/]
* [Fjax|http://www.fjax.net/]
* [Pjax|http://www.icetechnology.com/products/ipushv2/ria.shtml]
* [Server-Sent Events|http://whatwg.org/specs/web-apps/current-work/#scs-server-sent]
* [COMETd|http://cometd.com/]
* [Ajax for IBM WebSphere Platform|https://www14.software.ibm.com/iwm/web/cc/earlyprograms/websphere/ibmajaxw/]
!!外部链接：
* [KnowNow - pioneering implementation of Comet|http://www.knownow.com/article/?id=154]
* [Push Technology for RIA: Two ways of introducing iPush Server to a RIA project|http://www.icetechnology.com/products/ipushv2/ria.shtml]
* [Beyond AJAX: Accelerating Web Applications with Real-Time Event Notification, by Dr. Rohit Khare|http://www.knownow.com/products/docs/whitepapers/KN-Beyond-AJAX.pdf]