1 背景
「服務器推送技術」（Server Pushing）是最近Web技術中最熱門的一個流行術語。它是繼「Ajax」以後又一個倍受追捧的Web技術。「服務器推送技術」最近的流行跟「Ajax」有着密切的關係。javascript
隨着Ajax技術的興起，讓廣大開發人員又一次看到了使用瀏覽器來替代桌面應用的機會，而且此次機會很是大。Ajax將整個頁面的刷新變成頁面局部的刷新，而且數據的傳送是以異步方式進行，這使得網絡延遲帶來的視覺差別將會消失。php
可是，在瀏覽器中的Ajax應用中存在一個致命的缺陷沒法知足傳統桌面系統的需求。那就是「服務器發起的消息傳遞」（Server-Initiated Message Delivery）。在不少的應用當中，服務器軟件須要向客戶端主動發送消息或信息。由於服務器掌握着系統的主要資源，可以最早得到系統的狀態變化和事件的發生。當這些變化發生的時候，服務器須要主動的向客戶端實時的發送消息。例如股票的變化。在傳統的桌面系統這種需求沒有任何問題，由於客戶端和服務器之間一般存在着持久的鏈接，這個鏈接能夠雙向傳遞各類數據。而基於HTTP協議的Web應用卻不行。html
2 客戶端獲得通知的方式
圖1 傳統web訪問機制java
咱們知道，Web的訪問機制天生是設計用來pull數據的，如圖1，也就是隻容許Browser端主動發起請求，server是被動的響應，不容許Server向Browser發出一個connection請求，也就是說沒有爲server向Browser push數據提供設計實現.雖然沒有直接的實現方法,卻可使用一些變通的方式完成相似的功能。web
2.1 傳統輪詢
在Web早期，這一點常使用meta刷新實現。這將自動指示瀏覽器在指定秒數以後從新裝載頁面，從而支持簡陋的輪詢（polling）。例如在HTML文件中加入<META HTTP-RQUIV="Refresh" CONTENT=12>，實際上就是HTTP頭標告知瀏覽器每12秒更新一次文檔。ajax
優勢：不須要服務器端的配置。算法
缺點：數據庫
a) 糟糕的用戶體驗編程
b) 對服務器的壓力很大，而且形成帶寬的極大浪費。瀏覽器
2.2 Ajax輪詢
Ajax隔一段時間（一般使用JavaScript的setTimeout函數）就去服務器查詢是否有改變，從而進行增量式的更新。可是間隔多長時間去查詢成了問題，由於性能和即時性形成了嚴重的反比關係。間隔過短，接二連三的請求會沖垮服務器，間隔太長，務器上的新數據就須要越多的時間才能到達客戶機。
優勢：
a) 不須要太多服務器端的配置。
b) 下降帶寬的負荷（由於服務器返回的不是完整頁面）。
缺點：
a) 對服務器的壓力並不會有明顯的減小。
b) 實時性差，有必定的延遲。
應用：這是一項很是常見的技術，例如，大多數webmail應用程序就是經過這種技術在電子郵件到達時顯示電子郵件的。
2.3 Comet
Comet方式通俗的說就是一種長鏈接機制(long lived http)。一樣是由Browser端主動發起請求，可是Server端以一種彷佛很是慢的響應方式給出回答。這樣在這個期間內，服務器端可使用同一個connection把要更新的數據主動發送給Browser。所以請求可能等待較長的時間，期間沒有任何數據返回，可是一旦有了新的數據，它將當即被髮送到客戶機。Comet又有不少種實現方式，可是總的來講對Server端的負載都會有增長.雖然對於單位操做來講，每次只須要建議一次connection,可是因爲connection是保持較長時間的,對於server端的資源的佔用要有所增長。
優勢：實時性好（消息延時小）；性能好（能支持大量用戶）
缺點：長期佔用鏈接，喪失了無狀態高併發的特色。
應用：股票系統、實時通信。
2.4 Flash XML Socket
這種方案實現的基礎是：1、Flash提供了XMLSocket類。2、JavaScript 和Flash的緊密結合：在JavaScript能夠直接調用Flash程序提供的接口。
缺點：
a) 由於XMLSocket沒有HTTP隧道功能，XMLSocket類不能自動穿過防火牆；
b) 由於是使用套接口，須要設置一個通訊端口，防火牆、代理服務器也可能對非 HTTP 通道端口進行限制；
應用：網絡聊天室，網絡互動遊戲。
2.5 Java Applet 套接口
在客戶端使用Java Applet，經過java.net.Socket或java.net.DatagramSocket或java.net.MulticastSocket 創建與服務器端的套接口鏈接，從而實現「服務器推送」。
缺點：須要客戶端安裝JAVA虛擬機。
3 Comet介紹
Comet 有時也稱反向Ajax或服務器端推技術（server-side push）。其思想很簡單：將數據直接從服務器推到瀏覽器，而沒必要等到瀏覽器請求數據。聽起來簡單，可是若是熟悉 Web 應用程序，尤爲是HTTP協議，那麼您就會知道，這毫不簡單。實現Comet風格的Web應用程序，同時保證在瀏覽器和服務器上的可伸縮性，這只是在最近幾年才成爲可能。目前一些主流網站都有相似的原理，例如：webQQ、開心網、校內等等，它們中消息動態都是採用相似的技術，只是具體實現方式不同。
COMET的精髓就在於用服務器與javascript來維持瀏覽器的長鏈接，同時完成服務器端事件的瀏覽器端響應。這樣的事件廣播機制是跨網絡的，同時也是實時的。
採用了Comet技術的服務器在客戶機作出一個請求後，和客戶機創建一個永久的鏈接，而後服務器會根據客戶機的請求不斷把數據包推向客戶，這個推的過程是不間斷的。由服務器推向客戶機的數據在客戶機的瀏覽器上會不斷產生新的內容，並且不會產生Client pull那樣的HTML文檔頭，從而大大減小了延遲的時間，向（服務器響應--客戶機請求）同步邁進了一步。
服務器推送一般效率要比客戶端拖曳效率高，由於它沒必要爲後續數據創建新的鏈接。因爲始終保持鏈接，即便沒有數據傳輸時也是這樣，所以服務器必須願意分配這些TCP/IP端口，對於TCP/IP端口數有限的服務器這將是一個嚴重的問題。
客戶端拖曳效率低，由於這必須每次爲傳送數據創建新的鏈接。可是它沒必要始終保持鏈接。在實際狀況中，創建HTTP鏈接一般須要花費至關多的時間，多達一秒甚至更多。所以從性能上考慮，服務器推送對於最終用戶更有吸引力，特別是對於須要常常更新信息的狀況下。
服務器推送相對客戶端拖曳的另外一點優點是，服務器推送相對比較容易控制。例如，服務器每一次推送時都保持一個鏈接，但它又隨時能夠關閉其中的任何鏈接，而不須要在服務器上設置特殊的算法。而客戶端拖曳在一樣的狀況下要麻煩許多，它每次要與服務器創建鏈接，服務器爲了處理將客戶端拖曳請求與特定的最終用戶匹配等狀況，須要使用至關麻煩的算法。
如上所述，在服務器推送中，多個響應中鏈接始終保持，使服務器可在任什麼時候間發送更多的數據。一個明顯的好處是服務器徹底可以控制更新數據的時間和頻率。另外，這種方法效率高，由於始終保持鏈接。缺點是保持鏈接狀態會浪費服務器端的資源。服務器推送還比較容易中斷。
4 Comet實現（Java語言）
4.1 死循環法
最簡單的天然是死循環法，若是使用觀察者模式則能夠進一步提升性能。
可是這種作法的缺點在於客戶端請求了這個servlet後，web服務器會開啓一個線程執行servlet的代碼，而servlet由遲遲不願結束，形成該線程也沒法被釋放。因而乎，一個客戶端一個線程，當客戶端數量增長時，服務器依然會承受很大的負擔。
4.2 改寫web服務器
目前的趨勢是從web服務器內部入手，用nio（JDK 1.4提出的java.nio包）改寫request/response的實現，再利用線程池加強服務器的資源利用率，從而解決這個問題，目前支持這一非J2EE官方技術的服務器有Glassfish和Jetty。
JDK 1.4版本(包括以後的版本)最顯著的新特性就是增長了NIO(New IO)，可以以非阻塞的方式處理網絡的請求，這就使得在Java中只須要少許的線程就能處理大量的併發請求了。
Jetty 6設計來處理大量併發鏈接，它使用Java語言的不堵塞I/O(java.nio)庫而且使用優化的輸出緩衝架構。Jetty也有一個處理長鏈接的殺手鐗:一個稱爲Continuations的特性。
Grizzly做爲GlassFish中很是重要的一個項目，就是用NIO的技術來實現應用服務器中的高性能純Java的HTTP引擎。Grizzly仍是一個獨立於GlassFish的框架結構，能夠單獨用來擴展和構建本身的服務器軟件。
特色：使用NIO不是一件簡單的技術，它的一些特色使得編程的模型比原來阻塞的方式更爲複雜。
4.3 使用框架
基於Java的成熟的服務器推送框架有DWR。
DWR是一個開放源碼的使用Apache許可協議的解決方案，它包含服務器端Java庫、一個DWR servlet以及JavaScript庫。雖然DWR不是Java平臺上惟一可用的 Ajax-RPC 工具包，可是它是最成熟的，並且提供了許多有用的功能。從最簡單的角度來講，DWR是一個引擎，能夠把服務器端Java對象的方法公開給 JavaScript 代碼。使用 DWR 能夠有效地從應用程序代碼中把Ajax的所有請求-響應循環消除掉。這意味着客戶端代碼不再須要直接處理XMLHttpRequest對象或者服務器的響應。再也不須要編寫對象的序列化代碼或者使用第三方工具才能把對象變成XML。甚至再也不須要編寫servlet代碼把Ajax請求調整成對Java域對象的調用。
DWR從2.0開始增長了push功能,也就是在異步傳輸的狀況下能夠從Web-Server端發送數據到Browser。
特色：技術成熟，配置簡單，DWR與Spring、Struts二、Ext JS都能整合。
5 參考資料
1. DWR中的push機制.pdf（見附件）
2. DWR+EXT ＪＳ實現的聊天室（見附件）
3. 其餘資料請參考：服務器推送技術博客
服務器推送技術
1.背景
不少應用譬如監控、即時通訊、即時報價系統都須要將後臺發生的變化實時傳送到客戶端而無須客戶端不停地刷新、發送請求。本文首先介紹、比較了經常使用的「服務器推」方案，着重介紹了 Comet － 使用 HTTP 長鏈接、無須瀏覽器安裝插件的兩種「服務器推」方案：基於 AJAX 的長輪詢方式；基於 iframe 及 htmlfile 的流方式。最後分析了開發 Comet 應用須要注意的一些問題，以及如何藉助開源的 Comet 框架－pushlet 構建本身的「服務器推」應用。
傳統模式的 Web 系統以客戶端發出請求、服務器端響應的方式工做。這種方式並不能知足不少現實應用的需求，譬如：
· 監控系統：後臺硬件熱插拔、LED、溫度、電壓發生變化；
· 即時通訊系統：其它用戶登陸、發送信息；
· 即時報價系統：後臺數據庫內容發生變化；
2.兩類服務器推技術
這些應用都須要服務器能實時地將更新的信息傳送到客戶端，而無須客戶端發出請求。「服務器推」技術在現實應用中有一些解決方案，本文將這些解決方案分爲兩類：一類須要在瀏覽器端安裝插件，基於套接口傳送信息，或是使用 RMI、CORBA 進行遠程調用；而另外一類則無須瀏覽器安裝任何插件、基於 HTTP 長鏈接。
將「服務器推」應用在 Web 程序中，首先考慮的是如何在功能有限的瀏覽器端接收、處理信息：
1. 客戶端如何接收、處理信息，是否須要使用套接口或是使用遠程調用。客戶端呈現給用戶的是 HTML 頁面仍是 Java applet 或 Flash 窗口。若是使用套接口和遠程調用，怎麼和 JavaScript 結合修改 HTML 的顯示。
2. 客戶與服務器端通訊的信息格式，採起怎樣的出錯處理機制。
3. 客戶端是否須要支持不一樣類型的瀏覽器如 IE、Firefox，是否須要同時支持 Windows 和 Linux 平臺
基於客戶端套接口的「服務器推」技術
若是 Web 應用的用戶接受應用只有在安裝了 Flash 播放器才能正常運行， 那麼使用 Flash 的 XMLSocket 也是一個可行的方案。
這種方案實現的基礎是：
1. Flash 提供了 XMLSocket 類。
2. JavaScript 和 Flash 的緊密結合：在 JavaScript 能夠直接調用 Flash 程序提供的接口。
具體實現方法：在 HTML 頁面中內嵌入一個使用了 XMLSocket 類的 Flash 程序。JavaScript 經過調用此 Flash 程序提供的套接口接口與服務器端的套接口進行通訊。JavaScript 在收到服務器端以 XML 格式傳送的信息後能夠很容易地控制 HTML 頁面的內容顯示。
關於如何去構建充當了 JavaScript 與 Flash XMLSocket 橋樑的 Flash 程序，以及如何在 JavaScript 裏調用 Flash 提供的接口，咱們能夠參考 AFLAX（Asynchronous Flash and XML）項目提供的 Socket Demo 以及 SocketJS（請參見 參考資源）。
Javascript 與 Flash 的緊密結合，極大加強了客戶端的處理能力。從 Flash 播放器 V7.0.19 開始，已經取消了 XMLSocket 的端口必須大於 1023 的限制。Linux 平臺也支持 Flash XMLSocket 方案。但此方案的缺點在於：
1. 客戶端必須安裝 Flash 播放器；
2. 由於 XMLSocket 沒有 HTTP 隧道功能，XMLSocket 類不能自動穿過防火牆；
3. 由於是使用套接口，須要設置一個通訊端口，防火牆、代理服務器也可能對非 HTTP 通道端口進行限制；
不過這種方案在一些網絡聊天室，網絡互動遊戲中已獲得普遍使用。
在客戶端使用 Java Applet，經過 java.net.Socket 或 java.net.DatagramSocket 或 java.net.MulticastSocket 創建與服務器端的套接口鏈接，從而實現「服務器推」。
這種方案最大的不足在於 Java applet 在收到服務器端返回的信息後，沒法經過 JavaScript 去更新 HTML 頁面的內容。
基於 HTTP 長鏈接的「服務器推」技術（comet）
瀏覽器做爲 Web 應用的前臺，自身的處理功能比較有限。瀏覽器的發展須要客戶端升級軟件，同時因爲客戶端瀏覽器軟件的多樣性，在某種意義上，也影響了瀏覽器新技術的推廣。在 Web 應用中，瀏覽器的主要工做是發送請求、解析服務器返回的信息以不一樣的風格顯示。AJAX 是瀏覽器技術發展的成果，經過在瀏覽器端發送異步請求，提升了單用戶操做的響應性。但 Web 本質上是一個多用戶的系統，對任何用戶來講，能夠認爲服務器是另一個用戶。現有 AJAX 技術的發展並不能解決在一個多用戶的 Web 應用中，將更新的信息實時傳送給客戶端，從而用戶可能在「過期」的信息下進行操做。而 AJAX 的應用又使後臺數據更新更加頻繁成爲可能。
圖 1. 傳統的 Web 應用模型與基於 AJAX 的模型之比較 
「服務器推」是一種很早就存在的技術，之前在實現上主要是經過客戶端的套接口，或是服務器端的遠程調用。由於瀏覽器技術的發展比較緩慢，沒有爲「服務器推」的實現提供很好的支持，在純瀏覽器的應用中很難有一個完善的方案去實現「服務器推」並用於商業程序。最近幾年，由於 AJAX 技術的普及，以及把 IFrame 嵌在「htmlfile「的 ActiveX 組件中能夠解決 IE 的加載顯示問題，一些受歡迎的應用如 meebo，gmail+gtalk 在實現中使用了這些新技術；同時「服務器推」在現實應用中確實存在不少需求。由於這些緣由，基於純瀏覽器的「服務器推」技術開始受到較多關注，Alex Russell（Dojo Toolkit 的項目 Lead）稱這種基於 HTTP 長鏈接、無須在瀏覽器端安裝插件的「服務器推」技術爲「Comet」。目前已經出現了一些成熟的 Comet 應用以及各類開源框架；一些 Web 服務器如 Jetty 也在爲支持大量併發的長鏈接進行了不少改進。關於 Comet 技術最新的發展情況請參考關於 Comet 的 wiki。
下面將介紹兩種 Comet 應用的實現模型。
基於 AJAX 的長輪詢（long-polling）方式
如 圖 1 所示，AJAX 的出現使得 JavaScript 能夠調用 XMLHttpRequest 對象發出 HTTP 請求，JavaScript 響應處理函數根據服務器返回的信息對 HTML 頁面的顯示進行更新。使用 AJAX 實現「服務器推」與傳統的 AJAX 應用不一樣之處在於：
1. 服務器端會阻塞請求直到有數據傳遞或超時才返回。
2. 客戶端 JavaScript 響應處理函數會在處理完服務器返回的信息後，再次發出請求，從新創建鏈接。
3. 當客戶端處理接收的數據、從新創建鏈接時，服務器端可能有新的數據到達；這些信息會被服務器端保存直到客戶端從新創建鏈接，客戶端會一次把當前服務器端全部的信息取回。
一些應用及示例如 「Meebo」, 「Pushlet Chat」 都採用了這種長輪詢的方式。相對於「輪詢」（poll），這種長輪詢方式也能夠稱爲「拉」（pull）。由於這種方案基於 AJAX，具備如下一些優勢：請求異步發出；無須安裝插件；IE、Mozilla FireFox 都支持 AJAX。
在這種長輪詢方式下，客戶端是在 XMLHttpRequest 的 readystate 爲 4（即數據傳輸結束）時調用回調函數，進行信息處理。當 readystate 爲 4 時，數據傳輸結束，鏈接已經關閉。Mozilla Firefox 提供了對 Streaming AJAX 的支持， 即 readystate 爲 3 時（數據仍在傳輸中），客戶端能夠讀取數據，從而無須關閉鏈接，就能讀取處理服務器端返回的信息。IE 在 readystate 爲 3 時，不能讀取服務器返回的數據，目前 IE 不支持基於 Streaming AJAX。
基於 Iframe 及 htmlfile 的流（streaming）方式
iframe 是很早就存在的一種 HTML 標記， 經過在 HTML 頁面裏嵌入一個隱蔵幀，而後將這個隱蔵幀的 SRC 屬性設爲對一個長鏈接的請求，服務器端就能源源不斷地往客戶端輸入數據。
上節提到的 AJAX 方案是在 JavaScript 裏處理 XMLHttpRequest 從服務器取回的數據，而後 Javascript 能夠很方便的去控制 HTML 頁面的顯示。一樣的思路用在 iframe 方案的客戶端，iframe 服務器端並不返回直接顯示在頁面的數據，而是返回對客戶端 Javascript 函數的調用，如「<script type="text/javascript">js_func(「data from server 」)</script>」。服務器端將返回的數據做爲客戶端 JavaScript 函數的參數傳遞；客戶端瀏覽器的 Javascript 引擎在收到服務器返回的 JavaScript 調用時就會去執行代碼。
從 圖 3 能夠看到，每次數據傳送不會關閉鏈接，鏈接只會在通訊出現錯誤時，或是鏈接重建時關閉（一些防火牆常被設置爲丟棄過長的鏈接， 服務器端能夠設置一個超時時間， 超時後通知客戶端從新創建鏈接，並關閉原來的鏈接）。
使用 iframe 請求一個長鏈接有一個很明顯的不足之處：IE、Morzilla Firefox 下端的進度欄都會顯示加載沒有完成，並且 IE 上方的圖標會不停的轉動，表示加載正在進行。Google 的天才們使用一個稱爲「htmlfile」的 ActiveX 解決了在 IE 中的加載顯示問題，並將這種方法用到了 gmail+gtalk 產品中。Alex Russell 在 「What else is burried down in the depth's of Google's amazing JavaScript?」文章中介紹了這種方法。Zeitoun 網站提供的 comet-iframe.tar.gz，封裝了一個基於 iframe 和 htmlfile 的 JavaScript comet 對象，支持 IE、Mozilla Firefox 瀏覽器，能夠做爲參考。（請參見 參考資源）
3.使用 Comet 模型開發本身的應用
上面介紹了兩種基於 HTTP 長鏈接的「服務器推」架構，更多描述了客戶端處理長鏈接的技術。對於一個實際的應用而言，系統的穩定性和性能是很是重要的。將 HTTP 長鏈接用於實際應用，不少細節須要考慮。
咱們使用 IE 下載文件時會有這樣的體驗，從同一個 Web 服務器下載文件，最多隻能有兩個文件同時被下載。第三個文件的下載會被阻塞，直到前面下載的文件下載完畢。這是由於 HTTP 1.1 規範中規定，客戶端不該該與服務器端創建超過兩個的 HTTP 鏈接， 新的鏈接會被阻塞。而 IE 在實現中嚴格遵照了這種規定。
HTTP 1.1 對兩個長鏈接的限制，會對使用了長鏈接的 Web 應用帶來以下現象：在客戶端若是打開超過兩個的 IE 窗口去訪問同一個使用了長鏈接的 Web 服務器，第三個 IE 窗口的 HTTP 請求被前兩個窗口的長鏈接阻塞。
因此在開發長鏈接的應用時， 必須注意在使用了多個 frame 的頁面中，不要爲每一個 frame 的頁面都創建一個 HTTP 長鏈接，這樣會阻塞其它的 HTTP 請求，在設計上考慮讓多個 frame 的更新共用一個長鏈接。
通常 Web 服務器會爲每一個鏈接建立一個線程，若是在大型的商業應用中使用 Comet，服務器端須要維護大量併發的長鏈接。在這種應用背景下，服務器端須要考慮負載均衡和集羣技術；或是在服務器端爲長鏈接做一些改進。
應用和技術的發展老是帶來新的需求，從而推進新技術的發展。HTTP 1.1 與 1.0 規範有一個很大的不一樣：1.0 規範下服務器在處理完每一個 Get/Post 請求後會關閉套接口鏈接； 而 1.1 規範下服務器會保持這個鏈接，在處理兩個請求的間隔時間裏，這個鏈接處於空閒狀態。 Java 1.4 引入了支持異步 IO 的 java.nio 包。當鏈接處於空閒時，爲這個鏈接分配的線程資源會返還到線程池，能夠供新的鏈接使用；當原來處於空閒的鏈接的客戶發出新的請求，會從線程池裏分配一個線程資源處理這個請求。 這種技術在鏈接處於空閒的機率較高、併發鏈接數目不少的場景下對於下降服務器的資源負載很是有效。
可是 AJAX 的應用使請求的出現變得頻繁，而 Comet 則會長時間佔用一個鏈接，上述的服務器模型在新的應用背景下會變得很是低效，線程池裏有限的線程數甚至可能會阻塞新的鏈接。Jetty 6 Web 服務器針對 AJAX、Comet 應用的特色進行了不少創新的改進，請參考文章「AJAX，Comet and Jetty」（請參見 參考資源）。
使用長鏈接時，存在一個很常見的場景：客戶端網頁須要關閉，而服務器端還處在讀取數據的堵塞狀態，客戶端須要及時通知服務器端關閉數據鏈接。服務器在收到關閉請求後首先要從讀取數據的阻塞狀態喚醒，而後釋放爲這個客戶端分配的資源，再關閉鏈接。
因此在設計上，咱們須要使客戶端的控制請求和數據請求使用不一樣的 HTTP 鏈接，才能使控制請求不會被阻塞。
在實現上，若是是基於 iframe 流方式的長鏈接，客戶端頁面須要使用兩個 iframe，一個是控制幀，用於往服務器端發送控制請求，控制請求能很快收到響應，不會被堵塞；一個是顯示幀，用於往服務器端發送長鏈接請求。若是是基於 AJAX 的長輪詢方式，客戶端能夠異步地發出一個 XMLHttpRequest 請求，通知服務器端關閉數據鏈接。
在瀏覽器與服務器之間維持一個長鏈接會爲通訊帶來一些不肯定性：由於數據傳輸是隨機的，客戶端不知道什麼時候服務器纔有數據傳送。服務器端須要確保當客戶端再也不工做時，釋放爲這個客戶端分配的資源，防止內存泄漏。所以須要一種機制使雙方知道你們都在正常運行。在實現上：
1. 服務器端在阻塞讀時會設置一個時限，超時後阻塞讀調用會返回，同時發給客戶端沒有新數據到達的心跳信息。此時若是客戶端已經關閉，服務器往通道寫數據會出現異常，服務器端就會及時釋放爲這個客戶端分配的資源。
2. 若是客戶端使用的是基於 AJAX 的長輪詢方式；服務器端返回數據、關閉鏈接後，通過某個時限沒有收到客戶端的再次請求，會認爲客戶端不能正常工做，會釋放爲這個客戶端分配、維護的資源。
3. 當服務器處理信息出現異常狀況，須要發送錯誤信息通知客戶端，同時釋放資源、關閉鏈接。
4.參考資料
學習
· developerWorks 文章「 面向 Java 開發人員的 Ajax: 使用 Jetty 和 Direct Web Remoting 編寫可擴展的 Comet 應用程序」：受異步服務器端事件驅動的 Ajax 應用程序實現較爲困難，本文介紹了一種結合使用 Comet 模式和 Jetty 6 Continuations API 的解決方法。
· 「Comet: Low Latency Data for the Browser」：Alex Russell 是 Dojo Toolkit 的項目主管和 Dojo Foundation 的主席，他在這篇博客文章中提出了 Comet 這個術語。
· 「What else is burried down in the depth’s of Google’s amazing JavaScript?」（Alex Russel，2006 年 2 月）：Alex 在這篇文章裏介紹瞭如何使用「htmlfile」ActiveX 控件解決 iframe 請求長鏈接時 IE 的加載顯示問題。
· Comet wiki：提供了不少開源 Comet 框架的連接。
· Jetty：Jetty 是一種開源的基於標準的 Web 服務器，徹底使用 Java 語言實現。
· 「Ajax, Comet and Jetty」（Greg Wilkins，Webtide，2006 年 1 月）：Wilkins 的這份白皮書討論了擴展 Ajax 鏈接的 Jetty 架構方法。
· Continuations：瞭解更多關於 Jetty 的 Continuations 特性的信息。
· 「pushlet」：開源 comet 框架，使用了觀察者模型。瀏覽器端提供了基於 AJAX 和 iframe 的 JavaScript 庫，服務器端使用 Java Servlet。
· 「How to implement COMET with PHP」：提供的 comet-iframe.tar.gz 使用 iframe/htmlfile 封裝了一個 JavaScript comet 對象，支持 IE、Mozilla Firefox 瀏覽器。
· 「AFLAX」：Asynchronous Flash and XML，提供了強大的 Flash、Javascript 庫和不少範例。
· developerWorks Ajax 技術資源中心：能找到更多關於 Ajax 技術的文章和教程。
· developerWorks Web 開發技術專區：提供了關於 Web 開發和架構方面的大量文章。
· developerWorks Java 技術專區：提供了關於 Java 編程各個方面的數百篇文章。
· 瀏覽 技術書店，查閱有關本文所述主題以及其餘技術主題的書籍。
得到產品和技術
· Jetty：下載 Jetty。
討論
· 查看 developerWorks blogs，加入 developerWorks 社區。
周婷，軟件工程師，目前在 IBM 中國軟件開發技術實驗室從事刀片服務器管理固件的開發工做。您能夠經過 zhouting@cn.ibm.com 和她聯繫。
原文連接：http://www.ibm.com/developerworks/cn/web/wa-lo-comet/#resources
Pushlet -開源 Comet 框架
Pushlet 是一個開源的 Comet 框架，在設計上有不少值得借鑑的地方，對於開發輕量級的 Comet 應用頗有參考價值。
觀察者模型
Pushlet 使用了觀察者模型：客戶端發送請求，訂閱感興趣的事件；服務器端爲每一個客戶端分配一個會話 ID 做爲標記，事件源會把新產生的事件以多播的方式發送到訂閱者的事件隊列裏。
客戶端 JavaScript 庫
pushlet 提供了基於 AJAX 的 JavaScript 庫文件用於實現長輪詢方式的「服務器推」；還提供了基於 iframe 的 JavaScript 庫文件用於實現流方式的「服務器推」。
JavaScript 庫作了不少封裝工做：
1. 定義客戶端的通訊狀態：STATE_ERROR、STATE_ABORT、STATE_NULL、STATE_READY、STATE_JOINED、STATE_LISTENING；
2. 保存服務器分配的會話 ID，在創建鏈接以後的每次請求中會附上會話 ID 代表身份；
3. 提供了 join()、leave()、subscribe()、 unsubsribe()、listen() 等 API 供頁面調用；
4. 提供了處理響應的 JavaScript 函數接口 onData()、onEvent()…
網頁能夠很方便地使用這兩個 JavaScript 庫文件封裝的 API 與服務器進行通訊。
客戶端與服務器端通訊信息格式
pushlet 定義了一套客戶與服務器通訊的信息格式，使用 XML 格式。定義了客戶端發送請求的類型：join、leave、subscribe、unsubscribe、listen、refresh；以及響應的事件類型：data、join_ack、listen_ack、refresh、heartbeat、error、abort、subscribe_ack、unsubscribe_ack。
服務器端事件隊列管理
pushlet 在服務器端使用 Java Servlet 實現，其數據結構的設計框架仍可適用於 PHP、C 編寫的後臺客戶端。
Pushlet 支持客戶端本身選擇使用流、拉（長輪詢）、輪詢方式。服務器端根據客戶選擇的方式在讀取事件隊列（fetchEvents）時進行不一樣的處理。「輪詢」模式下 fetchEvents() 會立刻返回。」流「和」拉「模式使用阻塞的方式讀事件，若是超時，會發給客戶端發送一個沒有新信息收到的「heartbeat「事件，若是是「拉」模式，會把「heartbeat」與「refresh」事件一塊兒傳給客戶端，通知客戶端從新發出請求、創建鏈接。
客戶服務器之間的會話管理
服務端在客戶端發送 join 請求時，會爲客戶端分配一個會話 ID， 並傳給客戶端，而後客戶端就經過此會話 ID 標明身份發出 subscribe 和 listen 請求。服務器端會爲每一個會話維護一個訂閱的主題集合、事件隊列。
服務器端的事件源會把新產生的事件以多播的方式發送到每一個會話（即訂閱者）的事件隊列裏。
本文介紹瞭如何在現有的技術基礎上選擇合適的方案開發一個「服務器推」的應用，最優的方案仍是取決於應用需求的自己。相對於傳統的 Web 應用， 目前開發 Comet 應用仍是具備必定的挑戰性。
「服務器推」存在普遍的應用需求，爲了使 Comet 模型適用於大規模的商業應用，以及方便用戶構建 Comet 應用，最近幾年，不管是服務器仍是瀏覽器都出現了不少新技術，同時也出現了不少開源的 Comet 框架、協議。需求推進技術的發展，相信 Comet 的應用會變得和 AJAX 同樣普及。