无为清净楼资源网 Design By www.qnjia.com
客户端通过脚本和服务器保持请求,每次请求刷新一个时间,服务器检查这个时间,如果发现时间超过预定,则可以判断该客户端浏览器已关闭。然后对进行相应得操作。如果你想知道是那个客户端浏览器关闭,可以把会话绑定到轮询对象中。长连接不是所有服务器都支持得,这种方式,比你的现实多了。
我的个人看法。
我首先同意这几种做法,它们也能实现这个需求,他们都通过客户端的轮询,更新服务器的最后访问时间,让服务器检测超时。我来谈谈我对这2种做法的理解
1 服务器端如何进行超时判断,启动一个后台线程进行定时轮询?循环检查每个session是否超过了间隔?
2 如果用线程,那么服务器端判断的间隔或者周期是多少,1秒,10秒,20秒..
3 如果大家都用10秒间隔,客户也能承受这个间隔,我们来看结果
1) 我还不知道哪个服务器不支持长连接,如果你下载100G的文件,难道不行吗?中间非得断开n次?
2) 你的每个客户端需要在10秒之内,发出新的请求,让服务器进行响应,我的则不需要
3) 轮询操作要注意并发问题,也就是同步访问问题,你的数据得保存在application或者其它自定义全局数据结构里面,而多线程不存在这个问题
4) 轮询属于单线程,统一处理,而长连接为多线程
5) 客户端每次请求刷新后断开连接,可以减少占用服务器的连接数,提高并发数,但相对增加了每次请求的负担。
4 关键区别:如果要求在0.1秒内必须做出精确反应,发现连接断开要马上进行处理,我想我的多线程方案会更有效,因为浏览器很难在那么短的时间内发出10次请求的。而长连接则只需要减少发送数据的间隔就可以。
总结:
需求决定应用。
系统要求的判断超时的时间越短,长连接的方案优势越大,时间越长,轮询的可用性越强。具体需要根据应用做抉择。
对于一般的B/S判断,大部分聊天室和在线人数统计都是临行轮询操作的。一个人离开聊天室,不会立即更新在线列表,但IM程序(QQ/MSN)等则会相对非常精确的更新。
如果需要精确判断,我想长连接是我能想到的解决方案之一;另一个就是客户端插件,比如applet,Flash,ActiveX等使用socket进行了,不过机制和长连接没有区别。
两点小建议
1。 做到0.1反应可以,但做到0.1秒“精确”反应不行。TCP协议虽然是长连接,但没规定CS中一端掉线时,另一端迅速可知(否则也不会有后来TCP不太标准的“心跳”协议),这关乎中间网络硬件的支持。现实中也是如此。 当然,我不知道版主这篇文章的可能还有上文,所以不知这系统准备运行在什么网上。
2。 文章既然提到“前面页面”。看来这个系统就不应该是QQ或游戏服务器了,后台很可能就是运行一个普通的WEB服务器,IIS或APACHE。。它们的设计目标明确,所以都会有最大连接数限制。表面上,数千人同时在线,没关系,由于采用短连接,同一时间的并发数通常够用。但如果就算客户不活动,连接也要保持,那这个数目就很快有个死限了。
就算游戏或IM工具,典型如QQ,也不敢用TCP来长连接服务器。
所以我的总结是,如果准备做一个最多就1,2百人左右同时上线(而不是同时活动),那可以采用楼主的方法。如果人数一涨,则包括flash, activeX, socket ...统统不可能用长连接,宁可用UDP去碰。
我的个人看法。
我首先同意这几种做法,它们也能实现这个需求,他们都通过客户端的轮询,更新服务器的最后访问时间,让服务器检测超时。我来谈谈我对这2种做法的理解
1 服务器端如何进行超时判断,启动一个后台线程进行定时轮询?循环检查每个session是否超过了间隔?
2 如果用线程,那么服务器端判断的间隔或者周期是多少,1秒,10秒,20秒..
3 如果大家都用10秒间隔,客户也能承受这个间隔,我们来看结果
1) 我还不知道哪个服务器不支持长连接,如果你下载100G的文件,难道不行吗?中间非得断开n次?
2) 你的每个客户端需要在10秒之内,发出新的请求,让服务器进行响应,我的则不需要
3) 轮询操作要注意并发问题,也就是同步访问问题,你的数据得保存在application或者其它自定义全局数据结构里面,而多线程不存在这个问题
4) 轮询属于单线程,统一处理,而长连接为多线程
5) 客户端每次请求刷新后断开连接,可以减少占用服务器的连接数,提高并发数,但相对增加了每次请求的负担。
4 关键区别:如果要求在0.1秒内必须做出精确反应,发现连接断开要马上进行处理,我想我的多线程方案会更有效,因为浏览器很难在那么短的时间内发出10次请求的。而长连接则只需要减少发送数据的间隔就可以。
总结:
需求决定应用。
系统要求的判断超时的时间越短,长连接的方案优势越大,时间越长,轮询的可用性越强。具体需要根据应用做抉择。
对于一般的B/S判断,大部分聊天室和在线人数统计都是临行轮询操作的。一个人离开聊天室,不会立即更新在线列表,但IM程序(QQ/MSN)等则会相对非常精确的更新。
如果需要精确判断,我想长连接是我能想到的解决方案之一;另一个就是客户端插件,比如applet,Flash,ActiveX等使用socket进行了,不过机制和长连接没有区别。
两点小建议
1。 做到0.1反应可以,但做到0.1秒“精确”反应不行。TCP协议虽然是长连接,但没规定CS中一端掉线时,另一端迅速可知(否则也不会有后来TCP不太标准的“心跳”协议),这关乎中间网络硬件的支持。现实中也是如此。 当然,我不知道版主这篇文章的可能还有上文,所以不知这系统准备运行在什么网上。
2。 文章既然提到“前面页面”。看来这个系统就不应该是QQ或游戏服务器了,后台很可能就是运行一个普通的WEB服务器,IIS或APACHE。。它们的设计目标明确,所以都会有最大连接数限制。表面上,数千人同时在线,没关系,由于采用短连接,同一时间的并发数通常够用。但如果就算客户不活动,连接也要保持,那这个数目就很快有个死限了。
就算游戏或IM工具,典型如QQ,也不敢用TCP来长连接服务器。
所以我的总结是,如果准备做一个最多就1,2百人左右同时上线(而不是同时活动),那可以采用楼主的方法。如果人数一涨,则包括flash, activeX, socket ...统统不可能用长连接,宁可用UDP去碰。
标签:
浏览器,断开
无为清净楼资源网 Design By www.qnjia.com
广告合作:本站广告合作请联系QQ:858582 申请时备注:广告合作(否则不回)
免责声明:本站文章均来自网站采集或用户投稿,网站不提供任何软件下载或自行开发的软件! 如有用户或公司发现本站内容信息存在侵权行为,请邮件告知! 858582#qq.com
免责声明:本站文章均来自网站采集或用户投稿,网站不提供任何软件下载或自行开发的软件! 如有用户或公司发现本站内容信息存在侵权行为,请邮件告知! 858582#qq.com
无为清净楼资源网 Design By www.qnjia.com
暂无评论...
更新日志
2024年10月02日
2024年10月02日
- 纪钧瀚《钢琴阅读时光 雨中书店聆听轻音乐》[FLAC/分轨][399.62MB]
- 证声音乐图书馆《走向自然 疗心爵士乐》[320K/MP3][87.4MB]
- 证声音乐图书馆《走向自然 疗心爵士乐》[FLAC/分轨][184.94MB]
- 陈慧娴.2018-Priscilla-Ism演唱会3CD(2024环球红馆40复刻系列)【环球】【WAV+CUE】
- 郑秀文.1999-我应该得到(国)【华纳】【WAV+CUE】
- 陈家慧.2011-钢琴酒吧2CD【龙吟唱片】【WAV+CUE】
- 证声音乐图书馆《雨季 蓝调吉他 Rainy Blues》[320K/MP3][45.01MB]
- 证声音乐图书馆《雨季 蓝调吉他 Rainy Blues》[FLAC/分轨][109.13MB]
- 赞多《序章》[320K/MP3][45.54MB]
- 许巍.2004-每一刻都是崭新的【步升大风】【WAV+CUE】
- 群星.2024-四方馆影视原声带【韶愔音乐】【FLAC分轨】
- 陈雷.1997-安锁咧【金圆唱片】【WAV+CUE】
- 关淑怡.2013-MY.FAVORITE.SK.3CD【环球】【WAV+CUE】
- Sweety.2006-花言乔语【丰华】【WAV+CUE】
- 李恕权.2003-回·20年全精选2CD【SONY】【WAV+CUE】