基于Web的IM概览

By admin

- 7 minutes read - 1432 words

基于 WEB 的实时事件通知方式大致有五种方案：HTTP拉取方式(pull)，HTTP流，Long Polling，Flash XMLSocket方式，Java Applet。 首先说下Comet这个词，Comet 这个词是最早由Alex Russell（Dojo Toolkit 的项目 Lead）提出的，称基于 HTTP 长连接、无须在浏览器端安装插件的“服务器推(Push)”技术为“Comet”。 1.HTTP拉取方式(pull) 在这种传统的方法中，客户端以用户可定义的时间间隔去检查服务器上的最新数据。这种拉取方式的频率要足够高才能保证很高的数据精确度，但高频率可能会导致多余的检查，从而导致较高的网络流量。而另一方面，低频率则会导致错过更新的数据。理想地，拉取的时间间隔应该等于服务器状态改变的速度。常见的实现如利用 “” tag，当然利用xmlHttpRequest定时取也是一种方法。 2.HTTP流(Push机制)

HTTP流有两种形式：

  • Page Stream: 页面上不间断的HTTP连接响应(HTTP 1.1 Keep Alive). 通过在 HTML 页面里嵌入一个隐蔵帧（iframe），然后将这个隐蔵帧的 SRC 属性设为对一个长连接的请求，服务器端就能源源不断地往客户端输入数据。
  • Service Stream: XMLHttpRequest连接中的服务器数据流。 客户端是在 XMLHttpRequest 的 readystate 为 4（即数据传输结束）时调用回调函数，进行信息处理。当 readystate 为 4 时，数据传输结束，连接已经关闭。Mozilla Firefox 提供了对 Streaming AJAX 的支持，即 readystate 为 3 时（数据仍在传输中），客户端可以读取数据，从而无须关闭连接，就能读取处理服务器端返回的信息。IE 在 readystate 为 3 时，不能读取服务器返回的数据，目前 IE 不支持基于 Streaming AJAX。 注：使用 Page Stream(iframe) 请求一个长连接有一个很明显的不足之处：IE、Morzilla Firefox 下端的进度栏都会显示加载没有完成，而且 IE 上方的图标会不停的转动，表示加载正在进行。Google 的天才们使用一个称为“htmlfile”的 ActiveX 解决了在 IE 中的加载显示问题，并将这种方法用到了 gmail+gtalk 产品中。Alex Russell 在 “What else is burried down in the depth’s of Google’s amazing JavaScript?”文章中介绍了这种方法。Zeitoun 网站提供的 comet-iframe.tar.gz，封装了一个基于 iframe 和 htmlfile 的 JavaScript comet 对象，支持 IE、Mozilla Firefox 浏览器，可以作为参考。（ http://alex.dojotoolkit.org/?p=538） 3.长时间轮询(Long Polling) 也就是所谓的异步轮询(Asynchronous Polling)，这种方式是纯服务器端推送方式和客户端拉取方式的混合。它是基于BAYEUX协议( http://svn.xantus.org/shortbus/trunk/bayeux/bayeux.html)的。这个协议遵循基于主题的发布——订阅机制。在订阅了某个频道后，客户端和服务器间的连接会保持打开状态，并保持一段事先定义好的时间（默认为45秒）。如果服务器端没有事件发生，而发生了超时，服务器端就会请求客户端进行异步重新连接。如果有事件发生，服务器端会发送数据到客户端，然后客户端重新连接。 1.  服务器端会阻塞请求直到有数据传递或超时才返回。
  1. 客户端 JavaScript 响应处理函数会在处理完服务器返回的信息后，再次发出请求，重新建立连接。
  2. 当客户端处理接收的数据、重新建立连接时，服务器端可能有新的数据到达；这些信息会被服务器端保存直到客户端重新建立连接，客户端会一次把当前服务器端所有的信息取回。 4.Flash XMLSocket(push机制) 如果 Web 应用的用户接受应用只有在安装了 Flash 播放器才能正常运行，那么使用 Flash 的 XMLSocket 是一个可行的方案。 这种方案实现的基础是：
  3. Flash 提供了 XMLSocket 类(Flash 7.0.14以上版本)。
  4. JavaScript 和 Flash 的紧密结合：在 JavaScript 可以直接调用 Flash 程序提供的接口。 具体实现方法：在 HTML 页面中内嵌入一个使用了 XMLSocket 类的 Flash 程序。JavaScript 通过调用此 Flash 程序提供的套接口接口与服务器端的套接口进行通信。JavaScript 在收到服务器端以 XML 格式传送的信息后可以很容易地控制 HTML 页面的内容显示。 关于如何去构建充当了 JavaScript 与 Flash XMLSocket 桥梁的 Flash 程序，以及如何在 JavaScript 里调用 Flash 提供的接口，我们可以参考 AFLAX（Asynchronous Flash and XML）项目提供的 Socket Demo 以及 SocketJS（请参见 [ http://www.aflax.org/ Asynchronous Flash and XML，提供了强大的 Flash、Javascript 库和很多范例。]）。 Javascript 与 Flash 的紧密结合，极大增强了客户端的处理能力。从 Flash 播放器 V7.0.19 开始，已经取消了 XMLSocket 的端口必须大于 1023 的限制。Linux 平台也支持 Flash XMLSocket 方案。但此方案的缺点在于：
  5. 客户端必须安装 Flash 播放器；
  6. 因为 XMLSocket 没有 HTTP 隧道功能，XMLSocket 类不能自动穿过防火墙；
  7. 因为是使用Socket接口，需要设置一个通信端口，防火墙、代理服务器也可能对非 HTTP 通道端口进行限制；
  8. 必须使用XML格式作为消息格式，数据冗余增大。 此方案在一些网络聊天室，网络互动游戏中得到广泛使用。 5. Java Applet(Push机制) 类似于Flash XMLSocket方式。目前已经很少使用，原因极可能是因在手机等移动终端缺少支持。 总结和建议： 如果我们想要高数据一致性和高网络性能，我们就应该选择推送方式。但是，推送会带来一些扩展性问题；服务器应用程序CPU使用率是拉取方式的7倍。根据TUD（ http://swerl.tudelft.nl/twiki/pu … D-SERG-2007-016.pdf）的测试结果，服务器性能会在350-500个用户时趋于饱和。对于更大数量的用户，服务器端需要维护大量并发的长连接。在这种应用背景下，服务器端需要考虑负载均衡和集群技术；或是在服务器端为长连接作一些改进。 使用拉取方式，要想达到完整的数据一致性以及很高的网络性能是很困难的。如果拉取的时间间隔大于数据更新的时间间隔，就会发生一些数据的遗失。而如果小于数据更新的时间间隔，网络性能就会受到影响。拉取方式只有在拉取时间间隔等同于数据更新时间间隔时，才会恰到好处。但是，为了达到那样的目标，我们就需要提前知道准确的数据更新时间间隔。然而，数据更新的时间间隔很少是静态不变并可以预知的。这使得拉取方式只有在数据是根据某种特定模式发布的情况才有用。 控制信息与数据信息使用不同的 HTTP 连接 使用长连接时，存在一个很常见的场景：客户端网页需要关闭，而服务器端还处在读取数据的堵塞状态，客户端需要及时通知服务器端关闭数据连接。服务器在收到关闭请求后首先要从读取数据的阻塞状态唤醒，然后释放为这个客户端分配的资源，再关闭连接。所以在设计上，我们需要使客户端的控制请求和数据请求使用不同的 HTTP 连接，才能使控制请求不会被阻塞。 在实现上，如果是基于 iframe 流方式的长连接，客户端页面需要使用两个 iframe，一个是控制帧，用于往服务器端发送控制请求，控制请求能很快收到响应，不会被堵塞；一个是显示帧，用于往服务器端发送长连接请求。如果是基于 AJAX 的长轮询方式，客户端可以异步地发出一个 XMLHttpRequest 请求，通知服务器端关闭数据连接。 在客户和服务器之间保持“心跳”信息 在浏览器与服务器之间维持一个长连接会为通信带来一些不确定性：因为数据传输是随机的，客户端不知道何时服务器才有数据传送。服务器端需要确保当客户端不再工作时，释放为这个客户端分配的资源，防止内存泄漏。因此需要一种机制使双方知道大家都在正常运行。在实现上：
  9. 服务器端在阻塞读时会设置一个时限，超时后阻塞读调用会返回，同时发给客户端没有新数据到达的心跳信息。此时如果客户端已经关闭，服务器往通道写数据会出现异常，服务器端就会及时释放为这个客户端分配的资源。
  10. 如果客户端使用的是基于 AJAX 的长轮询方式；服务器端返回数据、关闭连接后，经过某个时限没有收到客户端的再次请求，会认为客户端不能正常工作，会释放为这个客户端分配、维护的资源。
  11. 当服务器处理信息出现异常情况，需要发送错误信息通知客户端，同时释放资源、关闭连接。 【附】开源项目资源 Cometd( http://cometd.com/)              Comet framework sponsored by the Dojo foundation. Orbited( http://orbited.org/)                可缩放的分布式Comet 服务器 （python 语言实现） Pushlets（ http://www.pushlets.com/）一个开源框架，可以让服务器端java对象推送事件到浏览器端javascript，java applet，或者flash应用程序 Jetty( http://jetty.mortbay.org/)          Servlet server java 实现 Pushup( http://pushup.causology.net/)  Comet server (C++实现)

Web IM的特性：无需安装客户端，穿透防火墙，与社区的紧密结合

Web IM的应用：社区用户的交流，在线客服，CRM。

Web IM实现技术 Web IM的实现技术主要有：

基于插件的技术：如ActiveX，插件相对稳定，但插件需要用户自己允许并下载安装，而大多数用户担心安装了黑客软件或插件对计算机系统不好而不愿意安装，并且上网助手等软件也拦截插件，导致很多用户无法使用。另外，ActiveX受平台限制，只能在IE下使用。

基于Flash的技术：典型的如Yahoo web messenger，结合Flash和Ajax；Google Talk Gadget

纯粹的基于HTTP的技术：

前端使用Ajax的Web IM：meebo, ebuddy, ILoveIm, MSN Web Messenger, KoolIM等。

后台使用comet的Web IM：meebo, gtalk等。

支持wap的有ebuddy, Yahoo Web Messenger, MSN Web Messenger, Google Talk, Mabber, AIM Express （Web Messengers Handbook）

Web IM

  1. 国内有独立IM的Web版：Web Popo, WebQQ, 也有与论坛等结合的IM：sohu小纸条，新浪“纸条箱”，QQ空间“小纸条”，淘宝旺旺等，

  2. 国外：基于上都是独立IM的Web版。或者集成多种IM的Web版，如meebo, flcikim, ebuddy等。

相关技术 Comet (Server-Push) Comet技术的一个重要组成部分就是event-drived web server，目前商用的实现已经出现，如lightstreamer，Lightstreamer Dojo Demo：http://app.lightstreamer.com/DojoDemo/

几个开源的支持Comet的Library。

Orbited ：一种开源的分布式Comet服务器 AjaxMessaging ：Ruby on Rails的Comet插件 Pushlets ：一个开源框架，可以让服务器端java对象推送事件到浏览器端javascript，java applet，或者flash应用程序 Lightstreamer ：提供基于AJAX-COMET模式的HTTP流的商业实现 Pjax ：Ajax的推送技术 Scalability（可伸缩性，可扩展性） Because Comet applications send events in real time, they typically use more resources than other types of web applications, making them more difficult to scale (grow to support large numbers of users).

Comet relies on continually keeping at least one server–client connection open for each client. Traditional web servers, designed for the page-by-page application architecture, cannot cope with such large numbers of open connections. This is a vertical scalability problem: it is difficult to handle many users on each server. Additionally, because Comet applications are often interactive, allowing arbitrary groups of users to communicate with each-other, splitting tasks among servers is more difficult than for applications in which each user acts independently. This is a horizontal scalability problem: it is difficult to add more servers to the application. Comet在可伸缩性上的提升：

http://cometdaily.com/2008/01/07/20000-reasons-that-comet-scales/

性能：After some recent optimizations, the Dojo Cometd implementation of the Bayeux protocol running on the Jetty web server can now handle up to 20,000 simultaneous users per server while maintaining sub-second latency.

测试环境：mid-sized Amazon EC2 virtual servers: 7.5 GB of memory, 2×2 EC2 Compute Units, 64-bit platform running Ubuntu 7.10 and Sun JVM 1.5.0_13. A single virtual machine was used as the Cometd server and between 1 and 3 virtual machines were used to generate the load of 20,000 clients.

DWR DWR(Direct Web Remoting)是一个WEB远程调用框架.利用这个框架可以让AJAX开发变得很简单.利用DWR可以在客户端利用JavaScript直接调用服务端的Java方法并返回值给JavaScript就好像直接本地客户端调用一样(DWR根据Java类来动态生成JavaScrip代码)。

可以使用DWR实现Comet Web应用程序，当前支持Comet的容器有Grizzly 、Tomcat 和Jetty等，其中，Jetty是做Ajax+Java开发的首选服务器端开发平台。

面向 Java 开发人员的 Ajax: 使用 Jetty 和 Direct Web Remoting 编写可扩展的 Comet 应用程序：http://www.ibm.com/developerworks/cn/java/j-jettydwr/index.html

Ajax推送与拉取方式的比较：http://www.infoq.com/cn/news/2007/07/pushvspull

实现基于web的实时事件通知的方法：

Dojo Dojo的Comet库，dojo.io.bind()

DWR has joined the Dojo Foundation, AJAX Frameworks: Mixing Dojo & DWR

几个典型的Web IM 分析 国内与论坛结合的众多Web IM中，sohu的小纸条是比较有特色和代表性的。

Sohu 小纸条 搜狐小纸条是基于Web的即时通讯工具。基于搜狐统一登录系统（Passport），它被搜狐几乎所有重要产品（包括搜狐博客、搜狐社区、ChinaRen等）运用到各自的好友系统中去。成为多数搜狐用户交流沟通的重要工具。借助用户的既存关系，搜狐小纸条的沟通交流显得更加安全，粘性更高。搜狐小纸条将作为搜狐主线产品的联络工具，它不再只是交流沟通的工具，还将成为一个资源共享、信息传递、关系传递等多元化，全方位的产品。

sohu论坛在线人数：69264（中午11:49），88688（下午3点），

http://luxuelin.blog.sohu.com/63653813.html

http://xiaonei.chinaren.com/blog/zoud

http://messenger.blog.sohu.com/

http://sohume.q.sohu.com/topics

ChinaRen/SOHU 小纸条系统核心 核心为3个小server系统：online2(在线系统业务逻辑)，userv(用户资料系统)，cserv(LRU缓存) 这三个子系统都是UDP+线程池结构，单进程+多线程。配备java接口，apache_mod的json和xml接口。 online2包括了大部分业务逻辑，包括，上线，好友系统，纸条系统。 userv包括设置用户各种属性，信息。 cserv是个大的lru缓存，用于减小磁盘IO。可以放各种信息块，包括用户信息，好友，留言等。目前配备4台服务器（DL380，xeon:3G*2，SCSI:146G raid，Ram:2G），用户分布到4台服务器上，相互交互。服务器可以由1台到2台，到4台，到8台。底层存储为文件存储（无数据库），用reiserfs。 配套系统： mod_online，两个版本，apache和lighttpd版本，用于页面上显示蜡烛人。请求量巨大，目前用lighttpd版本的 mod_online。放在sohu的squid前端机器上，运行在8080，大概8台，每台请求量大概500-800个每秒。蜡烛人在所有ChinaRen页面有ID的地方显示用户是否在线。 目前这套在线系统，作为SOHUIM的内核原型。准备开发WEBIM系统，用户所有SOHU矩阵用户的联络。

（引自：http://luxuelin.blog.sohu.com/63653813.html）

Sohu 小纸条目前共有8台服务器（2006年的数据）

问题：由于没有采用Ajax，聊天延迟非常大，网上有反映：“非常的费资源，聊着聊着，网页越来越慢，而且输入法也会因为资源的占用而发生一些不好的表现”；对Firefox技术不好；

http://images.sohu.com/cs/sohuim/xiaozt/version/2.0/js/webim.1.3.7.js

对比新浪的“纸条箱” 与搜狐小纸条相比，新浪的“纸条箱”还不是IM，只是有好友，发纸条功能，但是不能即时聊天，没有IM窗口，不能看用户的状态，而且一个非常不好的功能就是：每次发纸条都要输入验证码。

新浪“纸条箱”的附加功能：对好友进行了自动分类，如博客好友，论坛好友等。

Meebo http://blog.meebo.com/?p=129

支持特性：文件传输，Meebo Rooms，

前端Ajax，后端Comet，http server为lightTPD

Meebo的Load Balancing：http://blog.meebo.com/?p=127

服务器端用fastCGI实现（C/C++），

http://blog.meebo.com/?p=23

Meebo的三层：client-side (JavaScript), the communication layer, and then Gaim，

Ajax的使用：Use modified versions of the prototype.js $ function and dojo.require，通过使用Ajax，meebo可以做到无刷新的显示新的内容。使用Ajax有两种方式，一是每隔3~4秒轮询，发信息给服务器询问是否有更新，但是这个延迟也很大，Meebo使用Comet (long-polling)技术，

Meebo的通信方式：为了有更快响应，Simulate event-driven communication between the client and the communication layer. The client pings our servers occasionally to tell the server that the IM session (browser window) is still open. If there are any messages that the client or server needs to communicate, those messages are sent immediately. When there are no events, the communication layer sleeps until it sees a new event that needs to be handled. By doing so, we don’t hammer the servers and minimize the amount of network traffic.

当用户启动一个IM Session，meebo就创建一个与AOL, Jabber, MSN, and Yahoo’s等新的连接（通过开源的GAIM库），moobo的作者（Sandy）对GAIM进行了优化，这样，在每台服务器上可以运行很多GAIM实例，

文件传输：使用Amazon S3/EC2中转，http://blog.meebo.com/?p=355

meebo me：allows users to embed a version of Meebo on their personal website

On October 29, 2007, Meebo announced the abilitly to use applications of Video Conferencing(from MeBeam), Voice Chat(from Pudding Media), Video/Audio Call(from TokBox), Group Voice Call(from TalkShoe), Live Broadcast(from Ustream.tv), and you can create your own applications to play games or anything you’d like.

Google Talk on the web (Google Talk Gadget) Google Talk Gadget：Flash实现，可以把Google Talk嵌入到各种网页里去。

开源的Web IM IM 客户端软件最重要的有Pidgin和Miranda，它们实现了流行IM软件的各种协议。

JWChat：一个基于web的Jabber客户端。

IM协议 http://www.answers.com/topic/comparison-of-instant-messaging-protocols

用web2.0朏务(三) – 在线IM篇 由. Riku 将文章归档于 评论

如果你是Gmail用户，并且使用过Gmail内置的Gtalk客户端，那么你应该对在线版的IM软件有所了解，并且有可能你会鏞常喜欢它，下鏢介经几款在线IM软件，供叄住参考。

1』Meebo–支挏AIM』ICQ』Yahoo! Messenger』Jabber』Gtalk和MSN多秏IM平台。描供中文界鏢，速度较快。注册収可以双时添加多个丏双类型的IM帏户，支挏IE和FireFox。另外，如果你使用的是Flock的诏，通过一个插件可以让Meebo与Flock相结又(觏这里)，使用更加方便。

2』Mabber–描供的IM平台与Meebo差丏多，双样都支挏AIM』ICQ』Yahoo! Messenger』Jabber』Gtalk和MSN等。Mabber目剏还没有中文界鏢，而且速度也比较慢，它必须注册一个帏号収扏能使用，丏像Meebo那样在剏台描供独立的IM登录口。双样支挏IE和FireFox，目剏还处于Beta阶段。

3』Ebuddy–目剏只描供MSN』Yahoo和AIM三秏IM平台，而且它无需注册，直接在剏台描供每个IM的登录口，它的特色在于描供了与IM软件相类似的使用界鏢，擏作方便』支挏IE和FireFox。另外一个特色在于，它还描供WAP登录界鏢』也就是说可以通手机揥登录到IM平台，这样无论走到哪都能与网友进行沟通。

4』AIM Express–这是AIM描供的独立在线客户端，也就是说它只支挏AIM的右时通软件。

5』MSN Web Messenger–与AIM Express相类似，由微软描供的一款MSN独立在线客户端。

6』ICQ2GO–ICQ公司描供的ICQ独立在线客户端，使用JAVA技术。

7』JWChat–一个基于web的Jabber客户端。它其实是一个开溏软件，你可以下载収在自已的朏务器上安装，描供在线IM应用朏务，当然它也描供了一个在线DEMO，你可以试用它的功能。

8』KoolIM–最新发现的一个，与Meebo类似，描供AIM』ICQ』Yahoo! Messenger』Jabber』Gtalk和MSN多秏IM平台，并且在剏台就可以多帏号双时登录。你也可以注册一个帏号収把多个IM帏号集戏在一起。支挏IE和Firefox。（via Web2.0Fan.net)

9』Imhaha–也是与Meebo鏞常相似的一个在线IM朏务，丏过关键在于它支挏QQ，详细介经觏PARK17的QQ也web-based。

10』RadiusIM–又是一个与Meebo相类似的基于web的IM客户端，它支挏AIM』Yahoo messager!』MSN和Gtalk四秏IM，使用Ajax技术构建。

总的揥说，对于我们常用的一些IM软件，Meebo』Mabber或Ebuddy这三款就足以胜任，而在这三款当中，个人认为Meebo相对而言比较出色一点，丏仅功能比较齏全，而且速度也较快，所以我个人推菏Meebo。

相关报道: 开源软件商Zimbra拟明年增加Web邮箱IM功能

一.要点

1.采用长连接，及时响应消息； 使用Tomcat6的Comet特性 注：Read事件在POST数据情况下发生，GET方式不会产生Read事件。

2.消息机制 参与对象： 用户：User 群：Group 参与者：Peer(群成员)

服务端： 集群主机(A类) 1…n主机(B类) A—-Database A、B之间通过http/tcp…协议通讯 职责： A类主机负责数据存取以及产生消息事件; B类主机传递消息，并根据消息更新自身状态(集群主机同步); B类主机状态包含：Logined User/Active Group/Group Peer

客户端： 客户端保持对服务器的长连接(setTimeout，确保只有一个连接)； 连接返回信息(消息)再分派：系统消息、Group消息… 消息传递： Client—监听消息(长连接)； B类主机为长连接添加事件监听； B类主机监听A类主机事件； Client—>发送请求(普通请求，短连接)—>B类主机接收，转至—->A类主机; A类主机根据请求处理DB，并fireEvent…—>B类主机接收，B类主机根据Event信息，更新Group/User/Peer信息，并转发给Group/User—> 1)Group接收，遍历Peer，发送给Peer对应的在线User 2)User接收，长连接监听，写消息并close event.(客户端在连接关闭后将再次请求长连接)

3.同账号多次/多处登录限制方法：UserLoginEvent中带B类主机ID， 1)该用户在别的主机已登录：主机检测本机用户–断线处理。 2)本主机重复登录：检查已登录User，把之前登录用户断线。

4.Tomcat6配置： server.xml，修改为NIO Connector：

URIEncoding为URI设置编码(对GET方式生效)，POST方式情况增加EncodeFileter。

5.客户端请求：采用Ajax请求，避免页面刷新。

会打开一个网页，你若还没Gmail帐号就点击下面的“Create an account now ”若有Gmail帐号就点

击上面的“Sign In ”输入用户名和密码即可

7、目前还没有发现UC的Web版

目前web网页版的即时聊天层出不穷，下面是几款web版整合（QQ、msn、icq、yahoo通、Gtalk等）即时聊天工具，请大家根据自己的爱好择优选之。

像imhaha这样先入为主的大亨，它是第一个推出了网页版的qq 对国内朋友来说是个不小的福音，还有比较出名的像meboo等等

  1. www.imtata.com 主要集成了qq和msn两种聊天软件，看来主要针对的是国内市场，和web msn相比除了基本的聊天功能以外，还添加了文件传输，视频和音频等功能，网站宣传上说到可以完成MSN和QQ的群聊（我没有找到相应的按键），色彩上选择了淡雅的色系，没有给人以很强的视觉冲击力，外形比较像外国一个老牌web im集成网站meebo，但是meebo没有集成qq，所以对中国市场应该影响不大。就产品使用体验而言现在imtata还存在很多和其他web版im一样的问题，无法显示全部的好友，容易漏话，反映速度不如客户端等，但这个产品的出现还是以傲人的姿态给正在埋头苦干的腾讯一个下马威。 web2.0时代到来之后，网站建设似乎显得更加焦急，没有仔细思考就以迅雷不及掩耳之势轰轰烈烈的呈现在网友面前，这其中更不乏很多网站都是来也匆匆，去也匆匆，没有经得起2.0浪潮的洗礼，这次还要让我们拭目以待，看看imtata网站能否走的更远。把以前知道基于web的即时聊天站点做了一个小小的整理

2、imhaha http://www.imhaha.com 最近最热的要属IMhaha，并不是因为IMhaha 功能上有什么重大的突破 而在于IMhaha支持国内的QQ!IMhaha 是一家”硅谷一家就叫Imhaha的公司”创办的，布局方面和 meebo 很类似，最大的优越就是支持QQ!其他的倒没什么。喜欢 QQ 的朋友可以去试试看。

3、meebo http://www.meebo.com/ meebo.com是一种和eMessenger一样的基于Web的多协议IM，目前可以同时支持GTalk、MSN、AOL or ICQ、Yahoo!这五个即时通讯服务。和MYIM、Gaim、Trillian等集成式即时通信软件一样，提供了文字信息的聊天交流，但它不能语音视频，不能群聊，没有Email提醒。不同的是，meebo.com使用了AJAX，不用在客户端进行软件安装，登录meebo.com即可使用，提供完全的Windows客户端用户体验。偶尔需要在没有安装GTalk、MSN、AOL or ICQ、Yahoo!的计算机上使用，还是很值得推荐的。

4、Ebuddy http://www.ebuddy.com/ Ebuddy又一家WEB集成式IM工具，它还同时支持移动IM交流。目前Ebuddy支持MSN、YAHOO、AIM等国外主流IM工具。虽然前面介绍的Meebo也提供类似服务，不过Ebuddy更突出的是它支持MOBILE移动终端，在目前颇为热门的移动应用领域，Ebuddy走在了前面。

5、Kool IM http://www.koolim.com/ Koolim是另一个在线即时通讯服务器。基本上与前面两个介绍的没有什么差别，只是由于是新服务，所以速度尚可，目前支持 AIM、MSN、Y! IM、Gtalk、ICQ 和 Jabber 等主流 IM 通讯协议。

6、i love im http://www.iloveim.com/ 这个就没什么好介绍的，基本上跟前面的一样，目前只支持 MSN、Y! IM、AOL

7、Goowy http://www.goowy.com/ goowy本身并不是web聊天工具，goowy是一款基于Web的桌面系统（类WebOS的Desktop），不过里面内置了MSN、Y! IM、AOL等im，纯flash的操作界面，用着很舒服

二. 技术资料 1.   web msn的开发资料 ■MSN协议 英文： http://www.hypothetic.org/docs/msn/general/overview.php 中文： http://blog.csdn.net/fanccYang/category/106184.aspx

■TJMSN 网址： http://tjmsn.tomjudge.com 简介： TjMSN was started as due to a lack of decent MSN Messenger clients for Linux, so I decided that I would write a client that was platform independent, so that I would run on both my desktop and laptop.

TjMSN is licensed under the terms of the GNU General Public License.

就是一个平台无关的msn客户端 使用情况： 可正常运行，不过对于中文支持较差。在发送中文消息后，就出现发送其他消息失败的情况。

■TjMSNLib 网址： http://tjmsn.tomjudge.com 简介： About TjMSNLib TjMSNLib was was split from the original TjMSN development tree to aid in the seperation of the Networking Code from the GUI to a) simplify the GUI code, b) to remove large repeated code chunks, c) to make it easyer to manage the networking as it is now all in a single package rather than spread accross the GUI classes.

TjMSNLib is licensed under the terms of the GNU General Public License

就是一个MSN协议的Java实现的包，提供了3个小例子，一个简单的客户端，一个只会回复“OK”的msn机器人，另一个也是一个msn机器人，可以在用户改变状态时发送“hey”给改用户。

客户端，还有第一个msn机器人已经好用。 本包提供了docapi文档： http://tjmsn.tomjudge.com/docs/lib/

利用以上可以实现web msn 文档地址： http://tjmsn.tomjudge.com/developers/tjmsnlib.php

■libmsn 网址： http://libmsn.bdash.net.nz/ 简介： libmsn is a C++ library for Microsoft’s MSN Messenger service. It provides a high-level interface that allows an application to access instant messaging features with ease.

The libmsn 3 series is a complete refactoring of Meredydd Luff’s original libmsn, which is used by several popular instant messaging clients, including Fire, Everybuddy Lite, and attym. The result of the refactoring is that the library is more object-oriented, consistent and maintainable. This has made it possible to simplify the code, add new features, and squash a number of existing bugs.

■MSN Client 简介： http://www.sourceshock.com/details_snippet/37/ 用php实现的msn 客户端。使用msn的MSNP8通讯。

没有用起来。

■Blobsy 网址： http://www.blobsy.org/ 简介： Blobsy is an Open Source MSN Messenger bot, designed for easy setup, flexibility and ease of use. It is highly customizable and adding more functionality is extremely easy. It is freely distributable under the GNU General Public License (GPL).

没有用起来。 ■JMSN 简介：和TJMSN类似

http://jmsn.sourceforge.net/ ■msnmlib 简介：和TjMSNLib类似 不过都是韩文，看不懂 DOCAPI地址： http://jmsn.sourceforge.net/msnmlib/docs/index.html

■PHP MSN Messenger Class http://flumpcakes.co.uk/php/msn-messenger 简介： This is a simple to use class file which can be used to connect to the MSN Messenger Network. For the SSL authentication the php_curl modules can be used, or a curl executable (binary).

Currently the MSN9 Protocol is supported, and IM messages can be sent and received.

– Script updated to fix auth failures –

http://www.meebo.com/

已经见过不少了，例如ebay.com.cn得客服。还有一些公司在线客服 b/s版有个很大得优势，就是不要另外安装软件 公司产品中也有这一块功能，正如楼主所说，用得是Ajax技术 客户用得不多，算是个噱头而已。

# re: 基于Web的IM实现思考 回复 2006-05-09 20:12 by 补丁 不是很清楚怎么实现的,但是gmail里的googletalk似乎是实时的…有谁知道的可否告知一下 很久以前装过个googletalk，似乎是c/s的？

如今绝大多数IM软件都是基于桌面的，通常使用Tcp/Udp，并且都实现了防火墙穿透（代理）和基于Udp的NAT穿透的P2P技术。创建一个基于Web的IM是否可行（我们这里不考虑在浏览器中嵌入类似ActiveX控件的伪B/S，因为它实际上还是一个C/S，我们要讨论的是纯的Web方式）？答案无疑是肯定的，但是有些限制，这是因为： （1）基于Web的IM不可避免的采用Http作为主要的通信协议，而Htpp的非连接、无状态特性使得状态管理比较困难。当然，使用Http的好处是能轻易的穿过防火墙。（大多数网关都默认开放http的80端口） （2）单向性。只有客户端（Web浏览器）主动去联系服务器，而服务端无法主动联系特定的客户。

这些Web特性将会导致哪些限制了？ （1）客户与客户之间无法实现直接的P2P。因为基于Web时，一个客户无法直接“找到”另一个客户，就更别提NAT穿透了。 （2）客户与客户之间的消息交互是“伪实时”的，所有的消息都必须通过服务器进行“被动”地中转。比如，当客户A要把某个聊天消息Msg发送给B时，它首先将msg提交给服务器，因为服务器无法主动找到B，所以服务器需要暂存这个Msg（比如放入数据库），等到B来请求时，才能将这个Msg转发。这就是“被动”的含义了。

即使有这么多限制，我们仍然可以实现一个像模像样的基于Web的IM，这只是需要一些简单的技术/技巧。 （1）客户端使用Ajax技术实现页面局部刷新。如果每当有新消息来临或状态通知来临时，都需要整个页面刷新，这个Web IM一定不及格。 （2）客户端使用定时器不断的询问服务器是否有新的通知。比如是否有别人发给我的Msg、某个好友的状态是否发生的变化等，如果有，则向服务器提取这些信息。 （3）文件传输功能，仍然可以实现，同文字聊天消息一样。发送方先将文件上载到服务器，接收方通过轮询发现有传送给自己的文件时，则下载文件。 （4）视频聊天功能，仍然可以实现。首先是视频的捕捉、编码、解码，这可能需要在浏览器中嵌入类似ActiveX的控件。其次是视频数据的传递，可以采用与文件传输类似的方式。无疑，这种方式是非常的丑陋。 （5）群功能。简单思考一下，会发现这个实现起来比较简单。

尽管，通过种种技巧，我们可以实现一个基于Web的IM，但是它还能当之无愧的称为“即时通讯”吗？从前面的分析我们可以看到，所有的P2P通信都是“伪”即时的，并且如此实现的IM的服务端在用户量稍微大一点的时候的负载可想而知（特别是视频聊天功能，服务器需要暂存多大的数据量？）。 所以，据我所认识的来推断，基于纯Web的IM现在还没有办法做成产品（你自己写个玩玩当然没问题）。当然，也许在我的认识之外可能有更好的解决方案，如果你知道这样的解决方案，请一定要留言告诉我。 我想，有一点是真的，那就是B/S永远也无法吞并C/S的所有领地，有很多应用一定还是非C/S不可的。

目前最强大的开源Comet解决方案是： Dojo+Jetty Cometd+Jetty Continuation+Bayeux协议

一些相关的文档先放在这里，我就不多介绍了，大家都完全有能力读懂。 Jetty的作者，Servlet规范专家组成员Greg Wilkins写的两篇文章： Ajax, Comet and Jetty：

Cometd with Jetty：

Bayeux协议：

一种基于JSON的、平台中立的分路复用协议，可以由任何Comet客户端和服务器端实现。目前客户端的Dojo、服务器端的Jetty Cometd已经实现了对这个协议的支持。

一个使用这个解决方案的实例： Active AJAX based live dashboards：

根据Greg Wilkins的测试，最后Jetty Cometd服务10000个用户875个线程，只用了57M内存。

Pushlets作者Just van den Broecke也承认，Pushlets存在着可伸缩性的问题： “Yes, I am aware of the scalability limitations of the Pushlets framework. A dedicated server-side technique based on NIO (such as Greg, hi there, is working on ?) could help.” 并且申请加入Cometd的开发工作：

“With great interest I have been following recent COMET developments and would like to join cometd developments in whatever way.” 本文来自CSDN博客，转载请标明出处：