關(guān)于B/S判斷瀏覽器斷開(kāi)的問(wèn)題討論
更新時(shí)間:2008年10月29日 22:14:04 作者:
前臺(tái)頁(yè)面五分鐘,自己刷新一次,所以最多只有五分鐘的差錯(cuò)。
客戶端通過(guò)腳本和服務(wù)器保持請(qǐng)求,每次請(qǐng)求刷新一個(gè)時(shí)間,服務(wù)器檢查這個(gè)時(shí)間,如果發(fā)現(xiàn)時(shí)間超過(guò)預(yù)定,則可以判斷該客戶端瀏覽器已關(guān)閉。然后對(duì)進(jìn)行相應(yīng)得操作。如果你想知道是那個(gè)客戶端瀏覽器關(guān)閉,可以把會(huì)話綁定到輪詢對(duì)象中。長(zhǎng)連接不是所有服務(wù)器都支持得,這種方式,比你的現(xiàn)實(shí)多了。
我的個(gè)人看法。
我首先同意這幾種做法,它們也能實(shí)現(xiàn)這個(gè)需求,他們都通過(guò)客戶端的輪詢,更新服務(wù)器的最后訪問(wèn)時(shí)間,讓服務(wù)器檢測(cè)超時(shí)。我來(lái)談?wù)勎覍?duì)這2種做法的理解
1 服務(wù)器端如何進(jìn)行超時(shí)判斷,啟動(dòng)一個(gè)后臺(tái)線程進(jìn)行定時(shí)輪詢?循環(huán)檢查每個(gè)session是否超過(guò)了間隔?
2 如果用線程,那么服務(wù)器端判斷的間隔或者周期是多少,1秒,10秒,20秒..
3 如果大家都用10秒間隔,客戶也能承受這個(gè)間隔,我們來(lái)看結(jié)果
1) 我還不知道哪個(gè)服務(wù)器不支持長(zhǎng)連接,如果你下載100G的文件,難道不行嗎?中間非得斷開(kāi)n次?
2) 你的每個(gè)客戶端需要在10秒之內(nèi),發(fā)出新的請(qǐng)求,讓服務(wù)器進(jìn)行響應(yīng),我的則不需要
3) 輪詢操作要注意并發(fā)問(wèn)題,也就是同步訪問(wèn)問(wèn)題,你的數(shù)據(jù)得保存在application或者其它自定義全局?jǐn)?shù)據(jù)結(jié)構(gòu)里面,而多線程不存在這個(gè)問(wèn)題
4) 輪詢屬于單線程,統(tǒng)一處理,而長(zhǎng)連接為多線程
5) 客戶端每次請(qǐng)求刷新后斷開(kāi)連接,可以減少占用服務(wù)器的連接數(shù),提高并發(fā)數(shù),但相對(duì)增加了每次請(qǐng)求的負(fù)擔(dān)。
4 關(guān)鍵區(qū)別:如果要求在0.1秒內(nèi)必須做出精確反應(yīng),發(fā)現(xiàn)連接斷開(kāi)要馬上進(jìn)行處理,我想我的多線程方案會(huì)更有效,因?yàn)闉g覽器很難在那么短的時(shí)間內(nèi)發(fā)出10次請(qǐng)求的。而長(zhǎng)連接則只需要減少發(fā)送數(shù)據(jù)的間隔就可以。
總結(jié):
需求決定應(yīng)用。
系統(tǒng)要求的判斷超時(shí)的時(shí)間越短,長(zhǎng)連接的方案優(yōu)勢(shì)越大,時(shí)間越長(zhǎng),輪詢的可用性越強(qiáng)。具體需要根據(jù)應(yīng)用做抉擇。
對(duì)于一般的B/S判斷,大部分聊天室和在線人數(shù)統(tǒng)計(jì)都是臨行輪詢操作的。一個(gè)人離開(kāi)聊天室,不會(huì)立即更新在線列表,但I(xiàn)M程序(QQ/MSN)等則會(huì)相對(duì)非常精確的更新。
如果需要精確判斷,我想長(zhǎng)連接是我能想到的解決方案之一;另一個(gè)就是客戶端插件,比如applet,Flash,ActiveX等使用socket進(jìn)行了,不過(guò)機(jī)制和長(zhǎng)連接沒(méi)有區(qū)別。
兩點(diǎn)小建議
1。 做到0.1反應(yīng)可以,但做到0.1秒“精確”反應(yīng)不行。TCP協(xié)議雖然是長(zhǎng)連接,但沒(méi)規(guī)定CS中一端掉線時(shí),另一端迅速可知(否則也不會(huì)有后來(lái)TCP不太標(biāo)準(zhǔn)的“心跳”協(xié)議),這關(guān)乎中間網(wǎng)絡(luò)硬件的支持?,F(xiàn)實(shí)中也是如此。 當(dāng)然,我不知道版主這篇文章的可能還有上文,所以不知這系統(tǒng)準(zhǔn)備運(yùn)行在什么網(wǎng)上。
2。 文章既然提到“前面頁(yè)面”??磥?lái)這個(gè)系統(tǒng)就不應(yīng)該是QQ或游戲服務(wù)器了,后臺(tái)很可能就是運(yùn)行一個(gè)普通的WEB服務(wù)器,IIS或APACHE。。它們的設(shè)計(jì)目標(biāo)明確,所以都會(huì)有最大連接數(shù)限制。表面上,數(shù)千人同時(shí)在線,沒(méi)關(guān)系,由于采用短連接,同一時(shí)間的并發(fā)數(shù)通常夠用。但如果就算客戶不活動(dòng),連接也要保持,那這個(gè)數(shù)目就很快有個(gè)死限了。
就算游戲或IM工具,典型如QQ,也不敢用TCP來(lái)長(zhǎng)連接服務(wù)器。
所以我的總結(jié)是,如果準(zhǔn)備做一個(gè)最多就1,2百人左右同時(shí)上線(而不是同時(shí)活動(dòng)),那可以采用樓主的方法。如果人數(shù)一漲,則包括flash, activeX, socket ...統(tǒng)統(tǒng)不可能用長(zhǎng)連接,寧可用UDP去碰。
我的個(gè)人看法。
我首先同意這幾種做法,它們也能實(shí)現(xiàn)這個(gè)需求,他們都通過(guò)客戶端的輪詢,更新服務(wù)器的最后訪問(wèn)時(shí)間,讓服務(wù)器檢測(cè)超時(shí)。我來(lái)談?wù)勎覍?duì)這2種做法的理解
1 服務(wù)器端如何進(jìn)行超時(shí)判斷,啟動(dòng)一個(gè)后臺(tái)線程進(jìn)行定時(shí)輪詢?循環(huán)檢查每個(gè)session是否超過(guò)了間隔?
2 如果用線程,那么服務(wù)器端判斷的間隔或者周期是多少,1秒,10秒,20秒..
3 如果大家都用10秒間隔,客戶也能承受這個(gè)間隔,我們來(lái)看結(jié)果
1) 我還不知道哪個(gè)服務(wù)器不支持長(zhǎng)連接,如果你下載100G的文件,難道不行嗎?中間非得斷開(kāi)n次?
2) 你的每個(gè)客戶端需要在10秒之內(nèi),發(fā)出新的請(qǐng)求,讓服務(wù)器進(jìn)行響應(yīng),我的則不需要
3) 輪詢操作要注意并發(fā)問(wèn)題,也就是同步訪問(wèn)問(wèn)題,你的數(shù)據(jù)得保存在application或者其它自定義全局?jǐn)?shù)據(jù)結(jié)構(gòu)里面,而多線程不存在這個(gè)問(wèn)題
4) 輪詢屬于單線程,統(tǒng)一處理,而長(zhǎng)連接為多線程
5) 客戶端每次請(qǐng)求刷新后斷開(kāi)連接,可以減少占用服務(wù)器的連接數(shù),提高并發(fā)數(shù),但相對(duì)增加了每次請(qǐng)求的負(fù)擔(dān)。
4 關(guān)鍵區(qū)別:如果要求在0.1秒內(nèi)必須做出精確反應(yīng),發(fā)現(xiàn)連接斷開(kāi)要馬上進(jìn)行處理,我想我的多線程方案會(huì)更有效,因?yàn)闉g覽器很難在那么短的時(shí)間內(nèi)發(fā)出10次請(qǐng)求的。而長(zhǎng)連接則只需要減少發(fā)送數(shù)據(jù)的間隔就可以。
總結(jié):
需求決定應(yīng)用。
系統(tǒng)要求的判斷超時(shí)的時(shí)間越短,長(zhǎng)連接的方案優(yōu)勢(shì)越大,時(shí)間越長(zhǎng),輪詢的可用性越強(qiáng)。具體需要根據(jù)應(yīng)用做抉擇。
對(duì)于一般的B/S判斷,大部分聊天室和在線人數(shù)統(tǒng)計(jì)都是臨行輪詢操作的。一個(gè)人離開(kāi)聊天室,不會(huì)立即更新在線列表,但I(xiàn)M程序(QQ/MSN)等則會(huì)相對(duì)非常精確的更新。
如果需要精確判斷,我想長(zhǎng)連接是我能想到的解決方案之一;另一個(gè)就是客戶端插件,比如applet,Flash,ActiveX等使用socket進(jìn)行了,不過(guò)機(jī)制和長(zhǎng)連接沒(méi)有區(qū)別。
兩點(diǎn)小建議
1。 做到0.1反應(yīng)可以,但做到0.1秒“精確”反應(yīng)不行。TCP協(xié)議雖然是長(zhǎng)連接,但沒(méi)規(guī)定CS中一端掉線時(shí),另一端迅速可知(否則也不會(huì)有后來(lái)TCP不太標(biāo)準(zhǔn)的“心跳”協(xié)議),這關(guān)乎中間網(wǎng)絡(luò)硬件的支持?,F(xiàn)實(shí)中也是如此。 當(dāng)然,我不知道版主這篇文章的可能還有上文,所以不知這系統(tǒng)準(zhǔn)備運(yùn)行在什么網(wǎng)上。
2。 文章既然提到“前面頁(yè)面”??磥?lái)這個(gè)系統(tǒng)就不應(yīng)該是QQ或游戲服務(wù)器了,后臺(tái)很可能就是運(yùn)行一個(gè)普通的WEB服務(wù)器,IIS或APACHE。。它們的設(shè)計(jì)目標(biāo)明確,所以都會(huì)有最大連接數(shù)限制。表面上,數(shù)千人同時(shí)在線,沒(méi)關(guān)系,由于采用短連接,同一時(shí)間的并發(fā)數(shù)通常夠用。但如果就算客戶不活動(dòng),連接也要保持,那這個(gè)數(shù)目就很快有個(gè)死限了。
就算游戲或IM工具,典型如QQ,也不敢用TCP來(lái)長(zhǎng)連接服務(wù)器。
所以我的總結(jié)是,如果準(zhǔn)備做一個(gè)最多就1,2百人左右同時(shí)上線(而不是同時(shí)活動(dòng)),那可以采用樓主的方法。如果人數(shù)一漲,則包括flash, activeX, socket ...統(tǒng)統(tǒng)不可能用長(zhǎng)連接,寧可用UDP去碰。
相關(guān)文章
js實(shí)現(xiàn)二級(jí)導(dǎo)航功能
本文主要介紹了js實(shí)現(xiàn)二級(jí)導(dǎo)航功能的實(shí)例,具有很好的參考價(jià)值。下面跟著小編一起來(lái)看下吧2017-03-03javascript 跨瀏覽器開(kāi)發(fā)經(jīng)驗(yàn)總結(jié)(五) js 事件
javascript 跨瀏覽器開(kāi)發(fā)之js 事件的兼容性問(wèn)題,需要的朋友可以參考下。2010-05-05在 JavaScript 中保留小數(shù)點(diǎn)后兩位的方法
在 JavaScript 中,有多種方法可以保留小數(shù)點(diǎn)后兩位,本文給大家分享比較常用的方法,文末給大家介紹了實(shí)現(xiàn)數(shù)據(jù)格式化保留兩位小數(shù)的多種方法,感興趣的朋友一起看看吧2023-10-10TypeScript判斷對(duì)象類(lèi)型的4種方式代碼
這篇文章主要給大家介紹了關(guān)于TypeScript判斷對(duì)象類(lèi)型的4種方式代碼,TypeScript能根據(jù)一些簡(jiǎn)單的規(guī)則推斷(檢查)變量的類(lèi)型,你可以通過(guò)實(shí)踐很快的了解它們,需要的朋友可以參考下2023-07-07javascript:文字不間斷向左移動(dòng)的實(shí)例代碼
這篇文章介紹了javascript:文字不間斷向左移動(dòng)的實(shí)例代碼,有需要的朋友可以參考一下2013-08-08關(guān)于TypeScript應(yīng)該盡量避免的語(yǔ)法總結(jié)
TypeScript是JavaScript的超集,具有類(lèi)型系統(tǒng),支持ES6語(yǔ)法,支持面向?qū)ο缶幊痰母拍?下面這篇文章主要給大家介紹了關(guān)于TypeScript應(yīng)該盡量避免的語(yǔ)法,需要的朋友可以參考下2022-04-04firefox和IE系列的相關(guān)區(qū)別整理 以備后用
firefox和IE系列的相關(guān)區(qū)別整理,整理相對(duì)來(lái)說(shuō)還可以,但對(duì)于個(gè)別細(xì)節(jié)的處理不夠完善。具體的可以參考腳本*之家以前發(fā)布的文章。2009-12-12