Meebo 和 GMail + Talk 等 WebIM 的实现方式
2006-10-22 15:35
127 查看
我用Fiddler监听过Meebo和GMail + Talk,终于知道他们是如何实现event机制的了(也有人称之为Comet模式)。event包括好友发信息给你、好友上线/下线,甚至连是否显示某某人"is typing"的状态变换也算,反正就是指模仿桌面应用event机制需要服务器端主动触发客户端的东西。
例如有一个event.ashx是专门负责发送event消息的,那么工作的时候就保证一个客户端至少有一个活动的http连接在请求event.ashx。首先客户端要connect上去并发一个空的request请求event.ashx,然后服务器端则等待事件,如果在等待期间有事件发生则服务器端马上将事件信息写入response返回并disconnect掉,如果一段时间后没有事件发生则给出空的response并disconnect掉。客户端一旦收完response并被disconnect掉,马上进行下一次的connect和发送下一个空request以等待新的事件,如此重复下去。另外事件传输时可能也可以应用batch机制,也就是第一个事件触发后等几毫秒看看是否有紧随的事件,有的话也把其数据增加到response中一起发给客户端。
这样做的好处是,不会好像每秒一次请求检查事件那样非常消耗服务器端资源,但是占用着服务器的端口其实也是一种资源浪费。一台机65535个端口,幸运的话我想最多能够同时使用几百个,超过了网卡的缓冲区应该就负载不了了。
例如有一个event.ashx是专门负责发送event消息的,那么工作的时候就保证一个客户端至少有一个活动的http连接在请求event.ashx。首先客户端要connect上去并发一个空的request请求event.ashx,然后服务器端则等待事件,如果在等待期间有事件发生则服务器端马上将事件信息写入response返回并disconnect掉,如果一段时间后没有事件发生则给出空的response并disconnect掉。客户端一旦收完response并被disconnect掉,马上进行下一次的connect和发送下一个空request以等待新的事件,如此重复下去。另外事件传输时可能也可以应用batch机制,也就是第一个事件触发后等几毫秒看看是否有紧随的事件,有的话也把其数据增加到response中一起发给客户端。
这样做的好处是,不会好像每秒一次请求检查事件那样非常消耗服务器端资源,但是占用着服务器的端口其实也是一种资源浪费。一台机65535个端口,幸运的话我想最多能够同时使用几百个,超过了网卡的缓冲区应该就负载不了了。
相关文章推荐
- 无刷新上传文件以及类Gmail附件添加方式的实现
- GAC的一种非官方实现方式
- 用枚举的方式实现单例模式
- js实现下拉框支持添加和删除的方式
- ListView上拉加载和下拉刷新多种实现方式
- Huffman编码的8种实现方式
- 日志纪录到文本和xml实现方式
- 线性表--双链表实现方式 (JAVA)
- GO语言启动web服务的实现方式
- android开发游记:RecycleView 实现复杂首页布局三种方式
- 最近在一个外网的网站,困扰了我多天的循环和大家分享下,也做为我以后工作之用.第一种(信息作用循环.实现方式后台时钟在前台循环滚动(左右)显示).
- java中实现定时任务的方式详解
- 将文本框内容变大写的几种实现方式
- 利用ssl证书+nginx屏蔽运营商垃圾广告的实现方式
- 2.2、Hibernate用注解方式实现一对多、多对多关系
- Android实现推送方式解决方案
- Struts2+jquery 以ajax方式 实现jsp跟后台交互
- OpenJweb平台中自定义组合查询条件窗口的实现方式(经典之作)
- 第三十六天 一乐在其中—Android的按钮单击事件及监听器的实现方式
- android更新sdk开发包(经本人实践过的,至少现在这种方式还可以实现android sdk更新)