狠狠色丁香婷婷综合尤物/久久精品综合一区二区三区/中国有色金属学报/国产日韩欧美在线观看 - 国产一区二区三区四区五区tv

LOGO OA教程 ERP教程 模切知識(shí)交流 PMS教程 CRM教程 開(kāi)發(fā)文檔 其他文檔  
 
網(wǎng)站管理員

Comet:基于 HTTP 長(zhǎng)連接的“服務(wù)器推”技術(shù)

admin
2010年4月30日 23:35 本文熱度 6992

很多應(yīng)用譬如監(jiān)控、即時(shí)通信、即時(shí)報(bào)價(jià)系統(tǒng)都需要將后臺(tái)發(fā)生的變化實(shí)時(shí)傳送到客戶端而無(wú)須客戶端不停地刷新、發(fā)送請(qǐng)求。本文首先介紹、比較了常用的“服務(wù)器推”方案,著重介紹了 comet - 使用 http 長(zhǎng)連接、無(wú)須瀏覽器安裝插件的兩種“服務(wù)器推”方案:基于 ajax 的長(zhǎng)輪詢方式;基于 iframe 及 htmlfile 的流方式。最后分析了開(kāi)發(fā) comet 應(yīng)用需要注意的一些問(wèn)題,以及如何借助開(kāi)源的 comet 框架-pushlet 構(gòu)建自己的“服務(wù)器推”應(yīng)用。

“服務(wù)器推”技術(shù)的應(yīng)用

傳統(tǒng)模式的 web 系統(tǒng)以客戶端發(fā)出請(qǐng)求、服務(wù)器端響應(yīng)的方式工作。這種方式并不能滿足很多現(xiàn)實(shí)應(yīng)用的需求,譬如:

監(jiān)控系統(tǒng):后臺(tái)硬件熱插拔、led、溫度、電壓發(fā)生變化;
即時(shí)通信系統(tǒng):其它用戶登錄、發(fā)送信息;
即時(shí)報(bào)價(jià)系統(tǒng):后臺(tái)數(shù)據(jù)庫(kù)內(nèi)容發(fā)生變化;
這些應(yīng)用都需要服務(wù)器能實(shí)時(shí)地將更新的信息傳送到客戶端,而無(wú)須客戶端發(fā)出請(qǐng)求?!胺?wù)器推”技術(shù)在現(xiàn)實(shí)應(yīng)用中有一些解決方案,本文將這些解決方案分為兩類:一類需要在瀏覽器端安裝插件,基于套接口傳送信息,或是使用 rmi、corba 進(jìn)行遠(yuǎn)程調(diào)用;而另一類則無(wú)須瀏覽器安裝任何插件、基于 http 長(zhǎng)連接。

將“服務(wù)器推”應(yīng)用在 web 程序中,首先考慮的是如何在功能有限的瀏覽器端接收、處理信息:

客戶端如何接收、處理信息,是否需要使用套接口或是使用遠(yuǎn)程調(diào)用??蛻舳顺尸F(xiàn)給用戶的是 html 頁(yè)面還是 java applet 或 flash 窗口。如果使用套接口和遠(yuǎn)程調(diào)用,怎么和 javascript 結(jié)合修改 html 的顯示。
客戶與服務(wù)器端通信的信息格式,采取怎樣的出錯(cuò)處理機(jī)制。
客戶端是否需要支持不同類型的瀏覽器如 ie、firefox,是否需要同時(shí)支持 windows 和 linux 平臺(tái)。
基于客戶端套接口的“服務(wù)器推”技術(shù)

flash xmlsocket

如果 web 應(yīng)用的用戶接受應(yīng)用只有在安裝了 flash 播放器才能正常運(yùn)行, 那么使用 flash 的 xmlsocket 也是一個(gè)可行的方案。

這種方案實(shí)現(xiàn)的基礎(chǔ)是:

flash 提供了 xmlsocket 類。
javascript 和 flash 的緊密結(jié)合:在 javascript 可以直接調(diào)用 flash 程序提供的接口。
具體實(shí)現(xiàn)方法:在 html 頁(yè)面中內(nèi)嵌入一個(gè)使用了 xmlsocket 類的 flash 程序。javascript 通過(guò)調(diào)用此 flash 程序提供的套接口接口與服務(wù)器端的套接口進(jìn)行通信。javascript 在收到服務(wù)器端以 xml 格式傳送的信息后可以很容易地控制 html 頁(yè)面的內(nèi)容顯示。

關(guān)于如何去構(gòu)建充當(dāng)了 javascript 與 flash xmlsocket 橋梁的 flash 程序,以及如何在 javascript 里調(diào)用 flash 提供的接口,我們可以參考 aflax(asynchronous flash and xml)項(xiàng)目提供的 socket demo 以及 socketjs(請(qǐng)參見(jiàn) 參考資源)。

javascript 與 flash 的緊密結(jié)合,極大增強(qiáng)了客戶端的處理能力。從 flash 播放器 v7.0.19 開(kāi)始,已經(jīng)取消了 xmlsocket 的端口必須大于 1023 的限制。linux 平臺(tái)也支持 flash xmlsocket 方案。但此方案的缺點(diǎn)在于:

客戶端必須安裝 flash 播放器;
因?yàn)?xmlsocket 沒(méi)有 http 隧道功能,xmlsocket 類不能自動(dòng)穿過(guò)防火墻;
因?yàn)槭鞘褂锰捉涌?,需要設(shè)置一個(gè)通信端口,防火墻、代理服務(wù)器也可能對(duì)非 http 通道端口進(jìn)行限制;
不過(guò)這種方案在一些網(wǎng)絡(luò)聊天室,網(wǎng)絡(luò)互動(dòng)游戲中已得到廣泛使用。

java applet 套接口

在客戶端使用 java applet,通過(guò) java.net.socket 或 java.net.datagramsocket 或 java.net.multicastsocket 建立與服務(wù)器端的套接口連接,從而實(shí)現(xiàn)“服務(wù)器推”。

這種方案最大的不足在于 java applet 在收到服務(wù)器端返回的信息后,無(wú)法通過(guò) javascript 去更新 html 頁(yè)面的內(nèi)容。

基于 http 長(zhǎng)連接的“服務(wù)器推”技術(shù)

comet 簡(jiǎn)介

瀏覽器作為 web 應(yīng)用的前臺(tái),自身的處理功能比較有限。瀏覽器的發(fā)展需要客戶端升級(jí)軟件,同時(shí)由于客戶端瀏覽器軟件的多樣性,在某種意義上,也影響了瀏覽器新技術(shù)的推廣。在 web 應(yīng)用中,瀏覽器的主要工作是發(fā)送請(qǐng)求、解析服務(wù)器返回的信息以不同的風(fēng)格顯示。ajax 是瀏覽器技術(shù)發(fā)展的成果,通過(guò)在瀏覽器端發(fā)送異步請(qǐng)求,提高了單用戶操作的響應(yīng)性。但 web 本質(zhì)上是一個(gè)多用戶的系統(tǒng),對(duì)任何用戶來(lái)說(shuō),可以認(rèn)為服務(wù)器是另外一個(gè)用戶?,F(xiàn)有 ajax 技術(shù)的發(fā)展并不能解決在一個(gè)多用戶的 web 應(yīng)用中,將更新的信息實(shí)時(shí)傳送給客戶端,從而用戶可能在“過(guò)時(shí)”的信息下進(jìn)行操作。而 ajax 的應(yīng)用又使后臺(tái)數(shù)據(jù)更新更加頻繁成為可能。


圖 1. 傳統(tǒng)的 web 應(yīng)用模型與基于 ajax 的模型之比較


“服務(wù)器推”是一種很早就存在的技術(shù),以前在實(shí)現(xiàn)上主要是通過(guò)客戶端的套接口,或是服務(wù)器端的遠(yuǎn)程調(diào)用。因?yàn)闉g覽器技術(shù)的發(fā)展比較緩慢,沒(méi)有為“服務(wù)器推”的實(shí)現(xiàn)提供很好的支持,在純?yōu)g覽器的應(yīng)用中很難有一個(gè)完善的方案去實(shí)現(xiàn)“服務(wù)器推”并用于商業(yè)程序。最近幾年,因?yàn)?ajax 技術(shù)的普及,以及把 iframe 嵌在“htmlfile“的 activex 組件中可以解決 ie 的加載顯示問(wèn)題,一些受歡迎的應(yīng)用如 meebo,gmail+gtalk 在實(shí)現(xiàn)中使用了這些新技術(shù);同時(shí)“服務(wù)器推”在現(xiàn)實(shí)應(yīng)用中確實(shí)存在很多需求。因?yàn)檫@些原因,基于純?yōu)g覽器的“服務(wù)器推”技術(shù)開(kāi)始受到較多關(guān)注,alex russell(dojo toolkit 的項(xiàng)目 lead)稱這種基于 http 長(zhǎng)連接、無(wú)須在瀏覽器端安裝插件的“服務(wù)器推”技術(shù)為“comet”。目前已經(jīng)出現(xiàn)了一些成熟的 comet 應(yīng)用以及各種開(kāi)源框架;一些 web 服務(wù)器如 jetty 也在為支持大量并發(fā)的長(zhǎng)連接進(jìn)行了很多改進(jìn)。關(guān)于 comet 技術(shù)最新的發(fā)展?fàn)顩r請(qǐng)參考關(guān)于 comet 的 wiki。

下面將介紹兩種 comet 應(yīng)用的實(shí)現(xiàn)模型。

基于 ajax 的長(zhǎng)輪詢(long-polling)方式

如 圖 1 所示,ajax 的出現(xiàn)使得 javascript 可以調(diào)用 xmlhttprequest 對(duì)象發(fā)出 http 請(qǐng)求,javascript 響應(yīng)處理函數(shù)根據(jù)服務(wù)器返回的信息對(duì) html 頁(yè)面的顯示進(jìn)行更新。使用 ajax 實(shí)現(xiàn)“服務(wù)器推”與傳統(tǒng)的 ajax 應(yīng)用不同之處在于:

服務(wù)器端會(huì)阻塞請(qǐng)求直到有數(shù)據(jù)傳遞或超時(shí)才返回。
客戶端 javascript 響應(yīng)處理函數(shù)會(huì)在處理完服務(wù)器返回的信息后,再次發(fā)出請(qǐng)求,重新建立連接。
當(dāng)客戶端處理接收的數(shù)據(jù)、重新建立連接時(shí),服務(wù)器端可能有新的數(shù)據(jù)到達(dá);這些信息會(huì)被服務(wù)器端保存直到客戶端重新建立連接,客戶端會(huì)一次把當(dāng)前服務(wù)器端所有的信息取回。

圖 2. 基于長(zhǎng)輪詢的服務(wù)器推模型


一些應(yīng)用及示例如 “meebo”, “pushlet chat” 都采用了這種長(zhǎng)輪詢的方式。相對(duì)于“輪詢”(poll),這種長(zhǎng)輪詢方式也可以稱為“拉”(pull)。因?yàn)檫@種方案基于 ajax,具有以下一些優(yōu)點(diǎn):請(qǐng)求異步發(fā)出;無(wú)須安裝插件;ie、mozilla firefox 都支持 ajax。

在這種長(zhǎng)輪詢方式下,客戶端是在 xmlhttprequest 的 readystate 為 4(即數(shù)據(jù)傳輸結(jié)束)時(shí)調(diào)用回調(diào)函數(shù),進(jìn)行信息處理。當(dāng) readystate 為 4 時(shí),數(shù)據(jù)傳輸結(jié)束,連接已經(jīng)關(guān)閉。mozilla firefox 提供了對(duì) streaming ajax 的支持, 即 readystate 為 3 時(shí)(數(shù)據(jù)仍在傳輸中),客戶端可以讀取數(shù)據(jù),從而無(wú)須關(guān)閉連接,就能讀取處理服務(wù)器端返回的信息。ie 在 readystate 為 3 時(shí),不能讀取服務(wù)器返回的數(shù)據(jù),目前 ie 不支持基于 streaming ajax。

基于 iframe 及 htmlfile 的流(streaming)方式

iframe 是很早就存在的一種 html 標(biāo)記, 通過(guò)在 html 頁(yè)面里嵌入一個(gè)隱蔵幀,然后將這個(gè)隱蔵幀的 src 屬性設(shè)為對(duì)一個(gè)長(zhǎng)連接的請(qǐng)求,服務(wù)器端就能源源不斷地往客戶端輸入數(shù)據(jù)。


圖 3. 基于流方式的服務(wù)器推模型


上節(jié)提到的 ajax 方案是在 javascript 里處理 xmlhttprequest 從服務(wù)器取回的數(shù)據(jù),然后 javascript 可以很方便的去控制 html 頁(yè)面的顯示。同樣的思路用在 iframe 方案的客戶端,iframe 服務(wù)器端并不返回直接顯示在頁(yè)面的數(shù)據(jù),而是返回對(duì)客戶端 javascript 函數(shù)的調(diào)用,如“<script type="text/javascript">js_func(“data from server ”)

從 圖 3 可以看到,每次數(shù)據(jù)傳送不會(huì)關(guān)閉連接,連接只會(huì)在通信出現(xiàn)錯(cuò)誤時(shí),或是連接重建時(shí)關(guān)閉(一些防火墻常被設(shè)置為丟棄過(guò)長(zhǎng)的連接, 服務(wù)器端可以設(shè)置一個(gè)超時(shí)時(shí)間, 超時(shí)后通知客戶端重新建立連接,并關(guān)閉原來(lái)的連接)。

使用 iframe 請(qǐng)求一個(gè)長(zhǎng)連接有一個(gè)很明顯的不足之處:ie、morzilla firefox 下端的進(jìn)度欄都會(huì)顯示加載沒(méi)有完成,而且 ie 上方的圖標(biāo)會(huì)不停的轉(zhuǎn)動(dòng),表示加載正在進(jìn)行。google 的天才們使用一個(gè)稱為“htmlfile”的 activex 解決了在 ie 中的加載顯示問(wèn)題,并將這種方法用到了 gmail+gtalk 產(chǎn)品中。alex russell 在 “what else is burried down in the depth's of google's amazing javascript?”文章中介紹了這種方法。zeitoun 網(wǎng)站提供的 comet-iframe.tar.gz,封裝了一個(gè)基于 iframe 和 htmlfile 的 javascript comet 對(duì)象,支持 ie、mozilla firefox 瀏覽器,可以作為參考。(請(qǐng)參見(jiàn) 參考資源)

使用 comet 模型開(kāi)發(fā)自己的應(yīng)用

上面介紹了兩種基于 http 長(zhǎng)連接的“服務(wù)器推”架構(gòu),更多描述了客戶端處理長(zhǎng)連接的技術(shù)。對(duì)于一個(gè)實(shí)際的應(yīng)用而言,系統(tǒng)的穩(wěn)定性和性能是非常重要的。將 http 長(zhǎng)連接用于實(shí)際應(yīng)用,很多細(xì)節(jié)需要考慮。

不要在同一客戶端同時(shí)使用超過(guò)兩個(gè)的 http 長(zhǎng)連接

我們使用 ie 下載文件時(shí)會(huì)有這樣的體驗(yàn),從同一個(gè) web 服務(wù)器下載文件,最多只能有兩個(gè)文件同時(shí)被下載。第三個(gè)文件的下載會(huì)被阻塞,直到前面下載的文件下載完畢。這是因?yàn)?http 1.1 規(guī)范中規(guī)定,客戶端不應(yīng)該與服務(wù)器端建立超過(guò)兩個(gè)的 http 連接, 新的連接會(huì)被阻塞。而 ie 在實(shí)現(xiàn)中嚴(yán)格遵守了這種規(guī)定。

http 1.1 對(duì)兩個(gè)長(zhǎng)連接的限制,會(huì)對(duì)使用了長(zhǎng)連接的 web 應(yīng)用帶來(lái)如下現(xiàn)象:在客戶端如果打開(kāi)超過(guò)兩個(gè)的 ie 窗口去訪問(wèn)同一個(gè)使用了長(zhǎng)連接的 web 服務(wù)器,第三個(gè) ie 窗口的 http 請(qǐng)求被前兩個(gè)窗口的長(zhǎng)連接阻塞。

所以在開(kāi)發(fā)長(zhǎng)連接的應(yīng)用時(shí), 必須注意在使用了多個(gè) frame 的頁(yè)面中,不要為每個(gè) frame 的頁(yè)面都建立一個(gè) http 長(zhǎng)連接,這樣會(huì)阻塞其它的 http 請(qǐng)求,在設(shè)計(jì)上考慮讓多個(gè) frame 的更新共用一個(gè)長(zhǎng)連接。

服務(wù)器端的性能和可擴(kuò)展性

一般 web 服務(wù)器會(huì)為每個(gè)連接創(chuàng)建一個(gè)線程,如果在大型的商業(yè)應(yīng)用中使用 comet,服務(wù)器端需要維護(hù)大量并發(fā)的長(zhǎng)連接。在這種應(yīng)用背景下,服務(wù)器端需要考慮負(fù)載均衡和集群技術(shù);或是在服務(wù)器端為長(zhǎng)連接作一些改進(jìn)。

應(yīng)用和技術(shù)的發(fā)展總是帶來(lái)新的需求,從而推動(dòng)新技術(shù)的發(fā)展。http 1.1 與 1.0 規(guī)范有一個(gè)很大的不同:1.0 規(guī)范下服務(wù)器在處理完每個(gè) get/post 請(qǐng)求后會(huì)關(guān)閉套接口連接; 而 1.1 規(guī)范下服務(wù)器會(huì)保持這個(gè)連接,在處理兩個(gè)請(qǐng)求的間隔時(shí)間里,這個(gè)連接處于空閑狀態(tài)。 java 1.4 引入了支持異步 io 的 java.nio 包。當(dāng)連接處于空閑時(shí),為這個(gè)連接分配的線程資源會(huì)返還到線程池,可以供新的連接使用;當(dāng)原來(lái)處于空閑的連接的客戶發(fā)出新的請(qǐng)求,會(huì)從線程池里分配一個(gè)線程資源處理這個(gè)請(qǐng)求。 這種技術(shù)在連接處于空閑的機(jī)率較高、并發(fā)連接數(shù)目很多的場(chǎng)景下對(duì)于降低服務(wù)器的資源負(fù)載非常有效。

但是 ajax 的應(yīng)用使請(qǐng)求的出現(xiàn)變得頻繁,而 comet 則會(huì)長(zhǎng)時(shí)間占用一個(gè)連接,上述的服務(wù)器模型在新的應(yīng)用背景下會(huì)變得非常低效,線程池里有限的線程數(shù)甚至可能會(huì)阻塞新的連接。jetty 6 web 服務(wù)器針對(duì) ajax、comet 應(yīng)用的特點(diǎn)進(jìn)行了很多創(chuàng)新的改進(jìn),請(qǐng)參考文章“ajax,comet and jetty”(請(qǐng)參見(jiàn) 參考資源)。

控制信息與數(shù)據(jù)信息使用不同的 http 連接

使用長(zhǎng)連接時(shí),存在一個(gè)很常見(jiàn)的場(chǎng)景:客戶端網(wǎng)頁(yè)需要關(guān)閉,而服務(wù)器端還處在讀取數(shù)據(jù)的堵塞狀態(tài),客戶端需要及時(shí)通知服務(wù)器端關(guān)閉數(shù)據(jù)連接。服務(wù)器在收到關(guān)閉請(qǐng)求后首先要從讀取數(shù)據(jù)的阻塞狀態(tài)喚醒,然后釋放為這個(gè)客戶端分配的資源,再關(guān)閉連接。

所以在設(shè)計(jì)上,我們需要使客戶端的控制請(qǐng)求和數(shù)據(jù)請(qǐng)求使用不同的 http 連接,才能使控制請(qǐng)求不會(huì)被阻塞。

在實(shí)現(xiàn)上,如果是基于 iframe 流方式的長(zhǎng)連接,客戶端頁(yè)面需要使用兩個(gè) iframe,一個(gè)是控制幀,用于往服務(wù)器端發(fā)送控制請(qǐng)求,控制請(qǐng)求能很快收到響應(yīng),不會(huì)被堵塞;一個(gè)是顯示幀,用于往服務(wù)器端發(fā)送長(zhǎng)連接請(qǐng)求。如果是基于 ajax 的長(zhǎng)輪詢方式,客戶端可以異步地發(fā)出一個(gè) xmlhttprequest 請(qǐng)求,通知服務(wù)器端關(guān)閉數(shù)據(jù)連接。

在客戶和服務(wù)器之間保持“心跳”信息

在瀏覽器與服務(wù)器之間維持一個(gè)長(zhǎng)連接會(huì)為通信帶來(lái)一些不確定性:因?yàn)閿?shù)據(jù)傳輸是隨機(jī)的,客戶端不知道何時(shí)服務(wù)器才有數(shù)據(jù)傳送。服務(wù)器端需要確保當(dāng)客戶端不再工作時(shí),釋放為這個(gè)客戶端分配的資源,防止內(nèi)存泄漏。因此需要一種機(jī)制使雙方知道大家都在正常運(yùn)行。在實(shí)現(xiàn)上:

服務(wù)器端在阻塞讀時(shí)會(huì)設(shè)置一個(gè)時(shí)限,超時(shí)后阻塞讀調(diào)用會(huì)返回,同時(shí)發(fā)給客戶端沒(méi)有新數(shù)據(jù)到達(dá)的心跳信息。此時(shí)如果客戶端已經(jīng)關(guān)閉,服務(wù)器往通道寫數(shù)據(jù)會(huì)出現(xiàn)異常,服務(wù)器端就會(huì)及時(shí)釋放為這個(gè)客戶端分配的資源。
如果客戶端使用的是基于 ajax 的長(zhǎng)輪詢方式;服務(wù)器端返回?cái)?shù)據(jù)、關(guān)閉連接后,經(jīng)過(guò)某個(gè)時(shí)限沒(méi)有收到客戶端的再次請(qǐng)求,會(huì)認(rèn)為客戶端不能正常工作,會(huì)釋放為這個(gè)客戶端分配、維護(hù)的資源。
當(dāng)服務(wù)器處理信息出現(xiàn)異常情況,需要發(fā)送錯(cuò)誤信息通知客戶端,同時(shí)釋放資源、關(guān)閉連接。
pushlet - 開(kāi)源 comet 框架

pushlet 是一個(gè)開(kāi)源的 comet 框架,在設(shè)計(jì)上有很多值得借鑒的地方,對(duì)于開(kāi)發(fā)輕量級(jí)的 comet 應(yīng)用很有參考價(jià)值。

觀察者模型

pushlet 使用了觀察者模型:客戶端發(fā)送請(qǐng)求,訂閱感興趣的事件;服務(wù)器端為每個(gè)客戶端分配一個(gè)會(huì)話 id 作為標(biāo)記,事件源會(huì)把新產(chǎn)生的事件以多播的方式發(fā)送到訂閱者的事件隊(duì)列里。

客戶端 javascript 庫(kù)

pushlet 提供了基于 ajax 的 javascript 庫(kù)文件用于實(shí)現(xiàn)長(zhǎng)輪詢方式的“服務(wù)器推”;還提供了基于 iframe 的 javascript 庫(kù)文件用于實(shí)現(xiàn)流方式的“服務(wù)器推”。

javascript 庫(kù)做了很多封裝工作:

定義客戶端的通信狀態(tài):state_error、state_abort、state_null、state_ready、state_joined、state_listening;
保存服務(wù)器分配的會(huì)話 id,在建立連接之后的每次請(qǐng)求中會(huì)附上會(huì)話 id 表明身份;
提供了 join()、leave()、subscribe()、 unsubsribe()、listen() 等 api 供頁(yè)面調(diào)用;
提供了處理響應(yīng)的 javascript 函數(shù)接口 ondata()、onevent()…
網(wǎng)頁(yè)可以很方便地使用這兩個(gè) javascript 庫(kù)文件封裝的 api 與服務(wù)器進(jìn)行通信。

客戶端與服務(wù)器端通信信息格式

pushlet 定義了一套客戶與服務(wù)器通信的信息格式,使用 xml 格式。定義了客戶端發(fā)送請(qǐng)求的類型:join、leave、subscribe、unsubscribe、listen、refresh;以及響應(yīng)的事件類型:data、join_ack、listen_ack、refresh、heartbeat、error、abort、subscribe_ack、unsubscribe_ack。

服務(wù)器端事件隊(duì)列管理

pushlet 在服務(wù)器端使用 java servlet 實(shí)現(xiàn),其數(shù)據(jù)結(jié)構(gòu)的設(shè)計(jì)框架仍可適用于 php、c 編寫的后臺(tái)客戶端。

pushlet 支持客戶端自己選擇使用流、拉(長(zhǎng)輪詢)、輪詢方式。服務(wù)器端根據(jù)客戶選擇的方式在讀取事件隊(duì)列(fetchevents)時(shí)進(jìn)行不同的處理。“輪詢”模式下 fetchevents() 會(huì)馬上返回?!绷鳌昂汀崩澳J绞褂米枞姆绞阶x事件,如果超時(shí),會(huì)發(fā)給客戶端發(fā)送一個(gè)沒(méi)有新信息收到的“heartbeat“事件,如果是“拉”模式,會(huì)把“heartbeat”與“refresh”事件一起傳給客戶端,通知客戶端重新發(fā)出請(qǐng)求、建立連接。

客戶服務(wù)器之間的會(huì)話管理

服務(wù)端在客戶端發(fā)送 join 請(qǐng)求時(shí),會(huì)為客戶端分配一個(gè)會(huì)話 id, 并傳給客戶端,然后客戶端就通過(guò)此會(huì)話 id 標(biāo)明身份發(fā)出 subscribe 和 listen 請(qǐng)求。服務(wù)器端會(huì)為每個(gè)會(huì)話維護(hù)一個(gè)訂閱的主題集合、事件隊(duì)列。

服務(wù)器端的事件源會(huì)把新產(chǎn)生的事件以多播的方式發(fā)送到每個(gè)會(huì)話(即訂閱者)的事件隊(duì)列里。

小結(jié)

本文介紹了如何在現(xiàn)有的技術(shù)基礎(chǔ)上選擇合適的方案開(kāi)發(fā)一個(gè)“服務(wù)器推”的應(yīng)用,最優(yōu)的方案還是取決于應(yīng)用需求的本身。相對(duì)于傳統(tǒng)的 web 應(yīng)用, 目前開(kāi)發(fā) comet 應(yīng)用還是具有一定的挑戰(zhàn)性。

“服務(wù)器推”存在廣泛的應(yīng)用需求,為了使 comet 模型適用于大規(guī)模的商業(yè)應(yīng)用,以及方便用戶構(gòu)建 comet 應(yīng)用,最近幾年,無(wú)論是服務(wù)器還是瀏覽器都出現(xiàn)了很多新技術(shù),同時(shí)也出現(xiàn)了很多開(kāi)源的 comet 框架、協(xié)議。需求推動(dòng)技術(shù)的發(fā)展,相信 comet 的應(yīng)用會(huì)變得和 ajax 一樣普及。

關(guān)于作者

周婷,軟件工程師,目前在 ibm 中國(guó)軟件開(kāi)發(fā)技術(shù)實(shí)驗(yàn)室從事刀片服務(wù)器管理固件的開(kāi)發(fā)工作。您可以通過(guò) zhouting@cn.ibm.com 和她聯(lián)系。

本文來(lái)自csdn博客,轉(zhuǎn)載請(qǐng)標(biāo)明出處:http://blog.csdn.net/ibm_hoojo/archive/2010/04/18/5498731.aspx


該文章在 2023/12/17 23:58:04 編輯過(guò)
關(guān)鍵字查詢
相關(guān)文章
正在查詢...
點(diǎn)晴ERP是一款針對(duì)中小制造業(yè)的專業(yè)生產(chǎn)管理軟件系統(tǒng),系統(tǒng)成熟度和易用性得到了國(guó)內(nèi)大量中小企業(yè)的青睞。
點(diǎn)晴PMS碼頭管理系統(tǒng)主要針對(duì)港口碼頭集裝箱與散貨日常運(yùn)作、調(diào)度、堆場(chǎng)、車隊(duì)、財(cái)務(wù)費(fèi)用、相關(guān)報(bào)表等業(yè)務(wù)管理,結(jié)合碼頭的業(yè)務(wù)特點(diǎn),圍繞調(diào)度、堆場(chǎng)作業(yè)而開(kāi)發(fā)的。集技術(shù)的先進(jìn)性、管理的有效性于一體,是物流碼頭及其他港口類企業(yè)的高效ERP管理信息系統(tǒng)。
點(diǎn)晴WMS倉(cāng)儲(chǔ)管理系統(tǒng)提供了貨物產(chǎn)品管理,銷售管理,采購(gòu)管理,倉(cāng)儲(chǔ)管理,倉(cāng)庫(kù)管理,保質(zhì)期管理,貨位管理,庫(kù)位管理,生產(chǎn)管理,WMS管理系統(tǒng),標(biāo)簽打印,條形碼,二維碼管理,批號(hào)管理軟件。
點(diǎn)晴免費(fèi)OA是一款軟件和通用服務(wù)都免費(fèi),不限功能、不限時(shí)間、不限用戶的免費(fèi)OA協(xié)同辦公管理系統(tǒng)。
Copyright 2010-2025 ClickSun All Rights Reserved