|
锁定老帖子 主题：Comet，下一代Ajax？
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2006-10-16
最近在看comet（server push）技术，经过一番google之后，大致理清了头绪，目前已经研究完一个开源的comet实现：pushlet（[url]http://www.pushlets.com），包括前台的js，html代码以及后台的java代码，也基本搞清楚了关于pushlet的处理机制并且胡乱写了一部分pushlet的学习笔记，目前还在整理中，到时候将与大家分享！
接下来的打算看另外两个开源的comet实现：dwr 2.0的reverse ajax和dojo的io.bind()， 如果有志同道合者大家可以一起来研究共同提高！ 概念 关于comet的最初定义来自这篇blog文章：http://alex.dojotoolkit.org/?p=545。 简单的说就是客户端发送一个请求，服务器接收它，并使用一个无限循环，将客户端需要的数据push到response中，并进行刷新，但是该response并不关闭，继续接收新的数据并刷新，直到客户端断开连接，该循环才结束退出。 我们可以认为ajax解决了单用户响应的问题，而comet则解决了在保证性能的前提下进行协同多用户的响应问题。 comet的优点在于它可以在任何时候向客户端发送数据，而不仅仅只是响应用户的输入请求。而发送数据是在一个已有的单连接上进行的。因此可以大大降低发送数据的延迟时间（建立connection的开销，以及客户端发送请求的等待时间）。 关于Event Web Server comet技术的一个重要组成部分就是event-drived web server，目前商用的实现已经出现，如lightstreamer（http://www.lightstreamer.com），这个我没有仔细看，只是跑了一下他给出的demo，还行！开源的实现就是apache+jetty（还要加一个mod）这个我还没有具体用过！ 有国人声称实现了comet server（http://cnc.agile.com/read.php?tid=319），还没去仔细研究，不知道如何。 pushlet目前使用的是client pull做法，当然它的server push也将在不久的将来实现，它没有声称只能在专用的event-drived web server上运行，目前在tomcat运行环境下是可以的，不知道最多能承受多少用户同时访问还有待考证！ comet新体验 我看了一下comet技术的一些实现，其中meebo（http://wwwm.meebo.com/）算是做的比较好的一个（gmail有谁用过？说说感受），我觉得它的web版本msn messager，比微软自己的web msn就要好用的多。 声明：ITeye文章版权属于作者，受法律保护。没有作者书面许可不得转载。
推荐链接
|
| 返回顶楼 | |
|
发表时间：2006-10-16
我实现的Comet Server，如果用电信宽待访问地址是http://agile.com/read.php?tid=319。我凭兴趣随便做的，做好了不知道该在什么项目里用，就这么闲摆着。
如果想试一试的话，下载后，放到tomcat的webapps目录下就行，然后访问index.jsp或者login.jsp。你可以看到一个很简单的聊天室的效果。 因为时间不多，所以用了很讨巧的方式来实现的。没有修改tomcat的源代码，而是在contextLoader的时候，另外开了一个socket端口用来接受comet连接。 |
| 返回顶楼 | |
|
发表时间：2006-10-17
几年前的几乎所有国内的CGI聊天室都是这么搞得，活生生把无状态高并发的HTTP给挤兑成了个占用Server端一个进程的长连接，服务器支持的并发数直线下降。
现在已经没这么玩得啦。 |
| 返回顶楼 | |
|
发表时间：2006-10-17
pi1ot 写道 几年前的几乎所有国内的CGI聊天室都是这么搞得，活生生把无状态高并发的HTTP给挤兑成了个占用Server端一个进程的长连接，服务器支持的并发数直线下降。
现在已经没这么玩得啦。 那现在一般怎么做的，都是定期刷新吗？ |
| 返回顶楼 | |
|
发表时间：2006-10-17
robbin 写道 pi1ot 写道 几年前的几乎所有国内的CGI聊天室都是这么搞得，活生生把无状态高并发的HTTP给挤兑成了个占用Server端一个进程的长连接，服务器支持的并发数直线下降。
现在已经没这么玩得啦。 那现在一般怎么做的，都是定期刷新吗？ 现在一般用flash通过socket与server通信，再用flash结合js输出，不再经CGI进程转手了。 楼主说的comet其实就是： while(1) { printf("<html>xxx</html>"); fflush(stdout); } CGI直接输出HTML或者JS到浏览器。 |
| 返回顶楼 | |
|
发表时间：2006-10-17
我认为基于http的聊天类应用，自始自终都只有两类做法(如果有其他类别，请指正我)，
1.client pull。用JS等定时去服务器取数据。 好处是保持了http server的无状态高并发，坏处是大量的pull动作其实是白费的。 2.server push。服务端的JSP等程序的响应永不关闭，定时输出新内容。 好处是有新内容才输出，比较节省带宽等资源，坏处是长期占用了连接，丧失了无状态高并发的特点。 连接时有状态长期保持还是相反，这个也是传统意义上C/S与B/S的一大区别。所以看上去C/S会比B/S的并发负载能力低。但C/S的响应会更灵活和快速。 所以，server push不会是一个没有副作用的解决方案，是否适合还要仔细权衡。 补充一点，还能用Applet、flash、COM做基于UDP的应用，但那跟QQ差不多了，不在HTTP协议应用的范围内。 |
| 返回顶楼 | |
|
发表时间：2006-10-17
Lucas Lee 写道 我认为基于http的聊天类应用，自始自终都只有两类做法(如果有其他类别，请指正我)，
1.client pull。用JS等定时去服务器取数据。 好处是保持了http server的无状态高并发，坏处是大量的pull动作其实是白费的。 2.server push。服务端的JSP等程序的响应永不关闭，定时输出新内容。 好处是有新内容才输出，比较节省带宽等资源，坏处是长期占用了连接，丧失了无状态高并发的特点。 连接时有状态长期保持还是相反，这个也是传统意义上C/S与B/S的一大区别。所以看上去C/S会比B/S的并发负载能力低。但C/S的响应会更灵活和快速。 所以，server push不会是一个没有副作用的解决方案，是否适合还要仔细权衡。 补充一点，还能用Applet、flash、COM做基于UDP的应用，但那跟QQ差不多了，不在HTTP协议应用的范围内。 总结的非常有道理，server push通过维持长连接来得到快速将数据push到所有已连接的客户端，正因为如此所以不能采用传统的http web server，必须使用专用的event-drived web server来解决keep-alived connection的问题。 所以comet也没有什么新技术，一个成熟的comet应用除了需要一定的客户端脚本和服务器端代码的支持还需要特定的web server的支持！而一个成熟的comet framework则需要对这些客户端脚本和服务器代码进行良好的封装并能与各种event-drived web server能进行很好的结合，目前还没有比较成熟的event－drived web server出现，因此comet应用也没有象ajax那样普及。 与ajax应用相比，comet技术主要适用于即时通讯，实时数据监控，多用户协同交互的系统，所以comet应该算是ajax的一个有力补充和延伸！ |
| 返回顶楼 | |
|
发表时间：2006-10-17
hexiaodong 写道 我实现的Comet Server，如果用电信宽待访问地址是http://agile.com/read.php?tid=319。我凭兴趣随便做的，做好了不知道该在什么项目里用，就这么闲摆着。
如果想试一试的话，下载后，放到tomcat的webapps目录下就行，然后访问index.jsp或者login.jsp。你可以看到一个很简单的聊天室的效果。 因为时间不多，所以用了很讨巧的方式来实现的。没有修改tomcat的源代码，而是在contextLoader的时候，另外开了一个socket端口用来接受comet连接。 现在还没时间去看comet server，希望在了解了其他几个comet实现之后能跟你交流交流！ |
| 返回顶楼 | |
|
发表时间：2006-10-17
pi1ot 写道 楼主说的comet其实就是： while(1) { printf("<html>xxx</html>"); fflush(stdout); } CGI直接输出HTML或者JS到浏览器。 简单的说，就是这样，所以comet不存在什么新技术，没有什么神秘可言！瓶颈主要集中在web server这一块，一般成熟的comet商业应用都会有一套它自己专用的web server，比如lightstreamer就是这样！ |
| 返回顶楼 | |
|
发表时间：2006-10-17
我比较害怕和喜欢用感叹号的人交流，好像有个人在我面前冲着我大喊一样。
|
| 返回顶楼 | |
