近期关于comet的一些简单总结

一直关注的comet已经陆续出现了很多解决方案，自己也收集了一些资料，对其中的一些问题进行了思考，特做一个简单的总结。

1、comet的价值

早期的comet，仅仅考虑的是解决客户端不断轮询带来的压力问题，逐渐发展到今天，各类的网站，开始考虑为众多用户提供同时在线的互动服务，所以今天的comet方案逐渐开始以下面几个目标来衡量其价值：
a、同时连接数
b、处理能力
一些早期的方案，往往几百人同时在线就已经无法负荷，实际上没有多少应用需要处理同时几百人在线互动（注意：这里说的是实时性在线互动，比如MMORPG里面一次城战这样的，IM的世界频道广播这类并不算），所以上述问题可以通过增加机器来解决（把同步问题压到后端的数据同步，前端计算压力通过web服务器的分布来解决）

不过随着技术和产品的发展，更好的性能指标总是会提出来的，下面就谈谈一些更好的选择方案。

2、comet的方案

可以说各种主流语言和各种web server都有，因本人能力有限，涉及到的信息较少，达人们请多多指教。
a、c/c++有nginx_http_push_module, ape-project，这些都是号称5~10w同时在线的solution，这下子用脚本语言的同学们有福了
b、java因为其主流的影响力，相信解决方案是最有市场需求的，java的包括有：atmosphere--号称通用的解决方案，可惜只有0.4版本，dwr+jetty，成熟可用，商业应用应该没有问题，cometd，也是jetty basic的方案，1.0rc，tomcat/resin这类只有基础api支持，比较原始，还有一个pushlet，可惜性能不行（后面会谈谈pushlet的解决方案）
c、iis的htpmodule，是使用long polling的方式来解决的，long polling也可以算是解决方案之一，我看到的是http://www.codeproject.com/KB/aspnet/CometAsync.aspx
d、有不少方案是基于mailbox的消息存储方式（比如lighttpd的构思）
e、要提一下erlang的mochiweb，看过一些基于mochiweb的解决方案，long polling的

3、comet的生命力，来自websocket的挑战

个人窃以为，websocket的发展速度，肯定要比comet快（从来商业行为的速度都比技术行为要来的快），前端问题一旦解决，后端许多成熟的socket服务器就等着冒头了，从这个角度考虑，comet可能也就这几年的命……或许不值得投入太多资源去做技术研发

注：经过一段时间的思考，发现在国内因为盗版的原因，IE6占据了国内浏览器过半的使用率，导致comet的应用无法升级为websocket，取代方案只能考虑flash