每次请求刷新
个时间服务器检查这个时间如果发现时间超过预定则可以判断该客户端浏览器已关闭
然后对进行相应得操作如果你想知道是那个客户端浏览器关闭可以把会话绑定到轮询对象中长连接不是所有服务器都支持得这种方式比你
现实多了我
个人看法我首先同意这几种做法
它们也能实现这个需求他们都通过客户端轮询更新服务器最后访问时间让服务器检测超时我来谈谈我对这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,FlashActiveX等使用
进行了不过机制和长连接没有区别两点小建议
1
做到0.1反应可以但做到0.1秒“精确”反应不行TCP协议虽然是长连接但没规定CS中端掉线时另端迅速可知(否则也不会有后来TCP不太标准“心跳”协议)这关乎中间网络硬件支持现实中也是如此 当然我不知道版主这篇文章可能还有上文所以不知这系统准备运行在什么网上 2
文章既然提到“前面页面”看来这个系统就不应该是QQ或游戏服务器了后台很可能就是运行个普通WEB服务器IIS或APACHE它们设计目标明确所以都会有最大连接数限制表面上数千人同时在线没关系由于采用短连接同时间并发数通常够用但如果就算客户不活动连接也要保持那这个数目就很快有个死限了 就算游戏或IM工具
典型如QQ也不敢用TCP来长连接服务器 所以我
整理总结是如果准备做个最多就12百人左右同时上线(而不是同时活动)那可以采用楼主思路方法如果人数涨则包括flash, activeX, ...统统不可能用长连接宁可用UDP去碰
最新评论