介紹一個服務器端自動向客戶端推送信息的框架。在這之前先要了解幾個東西，首先是comet
comet介紹
基 於 HTTP 長連接的“服務器推”技術，是一種新的 Web 應用架構。基於這種架構開發的應用中，服務器端會主動以異步的方式向客戶端程序推送數據，而不需要客戶端顯式的發出請求。Comet 架構非常適合事件驅動的 Web 應用，以及對交互性和實時性要求很強的應用，如股票交易行情分析、聊天室和 Web 版在線遊戲等。
服務器推送技術(Server Push)是最近Web技術中最熱門的一個流行術語，它的別名叫Comet(彗星)。它是繼AJAX之後又一個倍受追捧的Web技術。服務器推送技術最近 的流行與AJAX有着密切的關係。 隨着Web技術的流行，越來越多的應用從原有的C/S模式轉變爲B/S模式，享受着Web技術 所帶來的各種優勢(例如跨平臺、免客戶端維護、跨越防火牆、擴展性好等)。但是基於瀏覽器的應用，也有它不足的地方。主要在於界面的友好性和交互性。由於 瀏覽器中的頁面每次需要全部刷新才能從服務器端獲得最新的數據或向服務器傳送數據，這樣產生的延遲所帶來的視覺感受非常糟糕。因此很多的桌面應用爲了獲得 更友好的界面放棄了Web技術，或者採用瀏覽器的插件技術(ActiveX、Applet、Flash等)。但是瀏覽器插件技術本身又有許多問題，例如跨 平臺問題和插件版本兼容性問題。
興起原因
隨 着AJAX技術的興起，讓廣大開發人員又一次看到了使用瀏覽器來替代桌面應用的機會，並且這次機會非常大。AJAX將整個頁面的刷新變成頁面局部的刷 新，並且數據的傳送是以異步方式進行，這使得網絡延遲帶來的視覺差異將會消失。AJAX還利用DHTML和豐富的JavasSript語言來模擬桌面系統 的各種事件和響應過程，以及平滑滾動和拖拽的效果。還不止這些，更有一些IT巨頭(Google、Sun、Oracle等)提供了非常豐富的AJAX開發 工具，使得開發和調試AJAX應用變得簡單高效，並且開發的AJAX應用還可以跨越各種瀏覽器和操作系統。在這種情況下基於AJAX的Web應用迅速涌 起，吞噬着原有桌面系統的份額。聊天工具、郵件閱讀器、博客編輯器，甚至是Office辦公軟件和文字處理軟件在瀏覽器中都有着美麗的外觀和幾乎可以與桌 面系統媲美的交互界面。Google更是提出“有了瀏覽器和Google，就不需要微軟”的口號和策略。在Ajax的世界中，除了傳統的CAD設計軟件和 大型遊戲軟件等因爲對系統硬件的苛刻需求，還離不開桌面系統以外，似乎其他所有的應用都可以變成Web應用了。
但是，在瀏覽器中的 AJAX應用中存在一個致命的缺陷無法滿足傳統桌面系統的需求。那就是“服 務器發起的消息傳遞(Server-Initiated Message Delivery)”。在很多的應用當中，服務器軟件需要向客戶端主動發送消息或信息。因爲服務器掌握着系統的主要資源，能夠最先獲得系統的狀態變化和事 件的發生。當這些變化發生的時候，服務器需要主動地向客戶端實時地發送消息。例如股票的變化。在傳統的桌面系統中，這種需求沒有任何問題，因爲客戶端和服 務器之間通常存在着持久的連接，這個連接可以雙向傳遞各種數據。而基於HTTP協議的Web應用卻不行。上節中也提到過，在Web世界中，服務器永遠是被 動地發送數據，前提是客戶端必須先發送請求。瀏覽器其實並不知道服務器的信息什麼時候會有改變，爲了模擬實時的交流，或者不想錯過某些信息，只能通過輪詢 (Polling)技術不斷刷新頁面來獲得最新的數據(見圖18-5)。這種方式不但浪費服務器的資源，最重要的是每次建立(或關閉)新的HTTP連接都 有一定的延遲，這種延遲使得頻繁信息傳遞的應用無法忍受。於是就產生了“服務器推送技術”。
技術對比
瀏 覽器作爲 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 應用不同之處在於： 服務器端會阻塞請求直到有數據傳遞或超時才返回。 客戶端 JavaScript 響應處理函數會在處理完服務器返回的信息後，再次發出請求，重新建立連接。 當客戶端處理接收的數據、重新建立連接時，服務器端可能有新的數據到達；這些信息會被服務器端保存直到客戶端重新建立連接，客戶端會一次把當前服務器 端所有的信息取回。
圖 2. 基於長輪詢的服務器推模型 一些應用及示例如 “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 屬性設爲對一個長連接的請求，服務器端就能源源不斷地往客戶端輸入數據。
圖 3. 基於流方式的服務器推模型 上節提到的 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 瀏覽器，可以作爲參考。
然後要了解的是servlet3.0
Servlet 3.0 新特性概述
Servlet 3.0 作爲 Java EE 6 規範體系中一員，隨着 Java EE 6 規範一起發佈。該版本在前一版本（Servlet 2.5）的基礎上提供了若干新特性用於簡化 Web 應用的開發和部署。其中有幾項特性的引入讓開發者感到非常興奮，同時也獲得了 Java 社區的一片讚譽之聲：
- 異步處理支持：有了該特性，Servlet 線程不再需要一直阻塞，直到業務處理完畢才能再輸出響應，最後才結束該 Servlet 線程。在接收到請求之後，Servlet 線程可以將耗時的操作委派給另一個線程來完成，自己在不生成響應的情況下返回至容器。針對業務處理較耗時的情況，這將大大減少服務器資源的佔用，並且提高 併發處理速度。
- 新增的註解支持：該版本新增了若干註解，用於簡化 Servlet、過濾器（Filter）和監聽器（Listener）的聲明，這使得 web.xml 部署描述文件從該版本開始不再是必選的了。
- 可 插性支持：熟悉 Struts2 的開發者一定會對其通過插件的方式與包括 Spring 在內的各種常用框架的整合特性記憶猶新。將相應的插件封裝成 JAR 包並放在類路徑下，Struts2 運行時便能自動加載這些插件。現在 Servlet 3.0 提供了類似的特性，開發者可以通過插件的方式很方便的擴充已有 Web 應用的功能，而不需要修改原有的應用。
接下來是長連接
長連接
所謂長連接，指在一個連接上可以連續發送多個數據包，然後斷開連接，在連接保持期間，如果沒有數據包發送，需要雙方發鏈路檢測包。短連接是指通訊雙方有數據交互時，就建立一個連接，數據發送完成後，則斷開此連接，即每次連接只完成一項業務的發送。
以前對於客戶端向服務端發送信息需要的是使用輪循的解決方案，或者使用ocx做socket連接來實現通信的效果，這對軟件本身帶來的就是性能問題。
auto-comet的方案及設計思想
設計目標
auto-comet是基於javaEE servlet3.0的comet框架。auto-comet亦在幫助你簡單、快速的構建高效、安全的comet服務。
基於異步servlet的auto-comet具有佔用服務器資源少且跨平臺的優點。
特性
- 支持單向推送
- 可以推送文本格式數據
- 可以用XML配置comet服務
- 可以與Spring整合
通訊協議
1.0特性
- 單向推送
僅支持web服務器向客戶端（瀏覽器Ajax）單向推送數據.客戶端不能通過comet通道發送數據給服務器。
- 支持文本格式數據
基於http協議的AutoComet還不支持二進制格式數據.
- 基於服務
與http類似，你可以從url映射到comet服務。一個servelt容器可以提供多個comet服務。服務不與session綁定，同一個瀏覽器可以同時訪問多個相同或不同的服務。
- 通信異常
除去底層的servlet,IO異常，主要有2類超時異常:
- 客戶端超時。比如用戶直接關閉瀏覽器，則大約在1分鐘後，服務端會發生一個異常。
- 服務器端超時，服務器端如果較長時間沒有使用一個socket也會發生一個異常，這個時間相對客戶端超時較長，大約爲1個小時。
auto-comit解決的性能問題
API設計
與servlet類似，從uri映射到服務
一個socket代表一個連接，可以發送消息
使用者使用handler管理socket
後續考慮加入多框架集成和緩存方案
主要接口
SocketDispatcherServlet控制器，負責將請求轉發自對應的handler
UrlHandlerMapping存儲uri到handler的映射
SocketManager管理所有的socket
SocketStore用於存儲socket
推送示例
通過聊天程序演示的服務端推技術
點擊chatRoom
分別用三個用戶張三，李四，王五登錄然後進行聊天
上面是操作的截圖並帶有文字說明
功能非常簡單就是一個非常常見的聊天程序，目的就是爲了說明服務端推技術的處理方案。
如果有對這個項目感興趣朋友可以加入到羣179199183 一起進行探討。