HTTP長鏈接(Comet)實現方式示例

昨天看了comet的介紹後，雖然大概知道了comet的原理，不過沒實際用過仍是不太清楚，因而今天又在網上翻了一下別的網友共享的comet實現http長鏈接的例子，在 Comet Server Push 技術介紹 一文中分別提到了 」基於長輪詢(long polling)「、」基於iframe「、」基於流(stream)「三種實現comet的方式，下面我將網上找到的對應的例子連接作個彙總，就當目錄吧，留做之後看 

 基於長輪詢(long polling)的特色 
1. 服務器端會阻塞請求直到有數據傳遞或超時才返回。 
2. 客戶端響應處理函數會在處理完服務器返回的信息後，再次發出請求，從新創建鏈接。 
3. 當客戶端處理接收的數據、從新創建鏈接時，服務器端可能有新的數據到達；這些信息會被服務器端保存直到客戶端從新創建鏈接，客戶端會一次把當前服務器端全部的信息取回。 

基於長輪詢的實現方式的例子能夠參見這篇文章 Ajax輪詢以及Comet模式—寫在Servlet 3.0發佈以前 
 不過我的感受做者在寫服務器端的示例代碼時沒有體現出 "服務器端會阻塞請求直到有數據傳遞或超時才返回",正確的作法應該是一個servlet接收聊天信息，一個servlet響應輪詢請求，採用觀察者模 式，被觀察者的狀態變化是查看聊天信息是否有更改，觀察者會保存每一個瀏覽器的輪詢請求的response對象，當被觀察者接收到新的聊天信息時，會通知觀 察者，觀察者則會將當前最新的聊天內容返回給瀏覽器。也就是說只有當接收聊天信息的servlet接收到新的聊天內容時，被觀察者纔會通知全部的觀察者， 不然觀察者將會一直保持response對象，沒有返回，這樣對瀏覽器來講就是一種阻塞。有時間本身再寫一個例子驗證一下... 

基於iframe 
經過在 HTML 頁面裏嵌入一個隱蔵幀，而後將這個隱蔵幀的 SRC 屬性設爲對一個長鏈接的請求，服務器端就能源源不斷地往客戶端輸入數據。這種方式的難點在於如何判斷鏈接中斷並從新嘗試鏈接。

基於iframe實現的例子能夠參見這篇文章  利用Response.Flush和iframe實現」服務器推」技術

基於流(stream) 
後臺服務器須要支持comet的web服務器，JAVA的話能夠採用Jetty+tomcat 6.0以上的組合； 瀏覽器端依賴於Streaming AJAX 技術，目前Mozilla Firefox 提供了對這種技術的支持， 即當xmlhttprequest的返回值readystate 爲 3 時（數據仍在傳輸中），客戶端能夠讀取數據，從而無須關閉鏈接，就能讀取處理服務器端返回的信息。IE 在 readystate 爲 3 時，不能讀取服務器返回的數據，目前 IE 不支持基於 Streaming AJAX。

基於流(stream)實現的例子能夠參見這篇文章  淺析Comet技術在Java Web實時系統開發中的應用