|
|
我的個(gè)人看法。
我首先同意這幾種做法，它們也能實(shí)現(xiàn)這個(gè)需求，他們都通過客戶端的輪詢，更新服務(wù)器的最后訪問時(shí)間，讓服務(wù)器檢測(cè)超時(shí)。我來談?wù)勎覍?duì)這2種做法的理解
1 服務(wù)器端如何進(jìn)行超時(shí)判斷，啟動(dòng)一個(gè)后臺(tái)線程進(jìn)行定時(shí)輪詢？循環(huán)檢查每個(gè)session是否超過了間隔？
2 如果用線程，那么服務(wù)器端判斷的間隔或者周期是多少，1秒，10秒，20秒..
3 如果大家都用10秒間隔，客戶也能承受這個(gè)間隔，我們來看結(jié)果
1) 我還不知道哪個(gè)服務(wù)器不支持長(zhǎng)連接，如果你下載100G的文件，難道不行嗎？中間非得斷開n次？
2) 你的每個(gè)客戶端需要在10秒之內(nèi)，發(fā)出新的請(qǐng)求，讓服務(wù)器進(jìn)行響應(yīng)，我的則不需要
3) 輪詢操作要注意并發(fā)問題，也就是同步訪問問題，你的數(shù)據(jù)得保存在application或者其它自定義全局?jǐn)?shù)據(jù)結(jié)構(gòu)里面，而多線程不存在這個(gè)問題
4) 輪詢屬于單線程，統(tǒng)一處理，而長(zhǎng)連接為多線程
5) 客戶端每次請(qǐng)求刷新后斷開連接，可以減少占用服務(wù)器的連接數(shù)，提高并發(fā)數(shù)，但相對(duì)增加了每次請(qǐng)求的負(fù)擔(dān)。
4 關(guān)鍵區(qū)別：如果要求在0.1秒內(nèi)必須做出精確反應(yīng)，發(fā)現(xiàn)連接斷開要馬上進(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è)人離開聊天室，不會(huì)立即更新在線列表，但I(xiàn)M程序(QQ/MSN)等則會(huì)相對(duì)非常精確的更新。
如果需要精確判斷，我想長(zhǎng)連接是我能想到的解決方案之一；另一個(gè)就是客戶端插件，比如applet,Flash，ActiveX等使用socket進(jìn)行了，不過機(jī)制和長(zhǎng)連接沒有區(qū)別。
兩點(diǎn)小建議
1。 做到0.1反應(yīng)可以，但做到0.1秒“精確”反應(yīng)不行。TCP協(xié)議雖然是長(zhǎng)連接，但沒規(guī)定CS中一端掉線時(shí)，另一端迅速可知（否則也不會(huì)有后來TCP不太標(biāo)準(zhǔn)的“心跳”協(xié)議），這關(guān)乎中間網(wǎng)絡(luò)硬件的支持。現(xiàn)實(shí)中也是如此。 當(dāng)然，我不知道版主這篇文章的可能還有上文，所以不知這系統(tǒng)準(zhǔn)備運(yùn)行在什么網(wǎng)上。
2。 文章既然提到“前面頁(yè)面”。看來這個(gè)系統(tǒng)就不應(yīng)該是QQ或游戲服務(wù)器了，后臺(tái)很可能就是運(yùn)行一個(gè)普通的WEB服務(wù)器，IIS或APACHE。。它們的設(shè)計(jì)目標(biāo)明確，所以都會(huì)有最大連接數(shù)限制。表面上，數(shù)千人同時(shí)在線，沒關(guān)系，由于采用短連接，同一時(shí)間的并發(fā)數(shù)通常夠用。但如果就算客戶不活動(dòng)，連接也要保持，那這個(gè)數(shù)目就很快有個(gè)死限了。
就算游戲或IM工具，典型如QQ，也不敢用TCP來長(zhǎng)連接服務(wù)器。
所以我的總結(jié)是，如果準(zhǔn)備做一個(gè)最多就1，2百人左右同時(shí)上線（而不是同時(shí)活動(dòng)），那可以采用樓主的方法。如果人數(shù)一漲，則包括flash, activeX, socket ...統(tǒng)統(tǒng)不可能用長(zhǎng)連接，寧可用UDP去碰。
JavaScript技術(shù)：關(guān)于B/S判斷瀏覽器斷開的問題討論，轉(zhuǎn)載需保留來源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。
