Comet簡介
Comet概述... 2
定義... 2
典型應(yīng)用場景... 3
瀏覽器端兼容性... 3
可靠性... 4
可擴展性... 4
注意事項... 4
其他解決方案... 5
Comet與Ajax的區(qū)別... 5
NIO.. 7
對比... 7
支持... 9
性能對比... 9
A項目中Comet的使用... 10
Dojo和Bayeux簡介... 11
備注... 11
Multipart/x-mixed-replace示例... 11
Pushlet簡介... 12
參考資料... 13
Comet討論... 13
進階資料... 15
要講Comet，先從Server Push開始。
Server Push是一種很早就存在的技術(shù)，以前在實現(xiàn)上主要是通過客戶端的套接字，或是服務(wù)器端的遠程調(diào)用。因為瀏覽器技術(shù)的發(fā)展比較緩慢，沒有為Server Push的實現(xiàn)提供很好的支持，在純?yōu)g覽器的應(yīng)用中很難有一個完善的方案去實現(xiàn)Server Push并用于商業(yè)程序。最近幾年，因為 AJAX 技術(shù)的普及，以及把 IFrame 嵌在“htmlfile“的 ActiveX 組件中可以解決 IE 的加載顯示問題，一些受歡迎的應(yīng)用如 meebo，gmail+gtalk 在實現(xiàn)中使用了這些新技術(shù)；同時“服務(wù)器推”在現(xiàn)實應(yīng)用中確實存在很多需求。因為這些原因，基于純?yōu)g覽器的“服務(wù)器推”技術(shù)開始受到較多關(guān)注，Alex Russell（Dojo Toolkit 的項目 Lead）稱這種基于 HTTP 長連接、無須在瀏覽器端安裝插件的Server Push技術(shù)為“Comet”。目前已經(jīng)出現(xiàn)了一些成熟的 Comet 應(yīng)用以及各種開源框架；一些 Web 服務(wù)器如 Jetty 也在為支持大量并發(fā)的長連接進行了很多改進。關(guān)于 Comet 技術(shù)最新的發(fā)展狀況請參考關(guān)于 Comet 的 wiki.
Wikipedia上對Comet的定義如下：
Comet is a World Wide Web application architecture in which a web server sends data to a client program (normally a web browser) asynchronously without any need for the client to explicitly request it. It allows creation of event-driven web applications, enabling real-time interaction otherwise impossible in a browser. Though the term Comet was coined in 2006,the idea is several years older, and has been called various names, including server push, HTTP push, HTTP streaming, Pushlets, Reverse Ajax, and others.
Comet applications use long-lived HTTP connections between the client and server, which the server can respond to lazily, pushing new data to the client as it becomes available. This differs from the original model of the web, in which a browser receives a complete web page in response to each request, and also from the Ajax model, in which browsers request chunks of data, used to update the current page. The effect is similar to applications using traditional Ajax with polling to detect new information on the server, but throughput is improved and latency and server load are decreased.
Comet does not refer to any specific technique for achieving this user-interaction model, but encompasses all of them—though it implies the use of browser-native technologies such as JavaScript as opposed to proprietary plugins. Several such techniques exist, with various trade-offs in terms of browser support and side effects, latency, and throughput.
傳統(tǒng)的web應(yīng)用都是基于請求-響應(yīng)的模式，ajax的改進只是非全頁面更新，無法解決實時性和事件驅(qū)動。ajax with polling通過定時請求可以實現(xiàn)偽實時，但頻繁的建立和銷毀連接又會耗費服務(wù)器大量資源，增加帶寬使用。Comet使用Http1.1 長連接，實現(xiàn)實時的服務(wù)器-客戶端數(shù)據(jù)推送。Comet的實現(xiàn)可以有兩種方式，Streaming和Long-Polling。Streaming方式建立連接后，兩端均不斷開，使用此連接實時傳輸消息。Long-Polling方式一旦完成數(shù)據(jù)接收，即斷開當前連接并重新建立新連接。二者相比Streaming性能最優(yōu)，但即使是Long-Polling，不管是服務(wù)端負載還是對網(wǎng)絡(luò)帶寬的使用，也大大優(yōu)于傳統(tǒng)的Polling。
典型應(yīng)用場景
Comet特別適用于需要和服務(wù)器端實時交互的應(yīng)用，如聊天，遠程協(xié)作等類型的Web應(yīng)用。
瀏覽器端兼容性
在Comet之前，可通過下述途徑來實現(xiàn)類似的效果，其中部分方式現(xiàn)在仍有較多使用。各方式對瀏覽器端的兼容性如下：
1. IFrame
最早的實現(xiàn)方式，通過隱藏的IFrame元素實現(xiàn)對服務(wù)器的持續(xù)請求，在返回內(nèi)容中輸出并執(zhí)行JavaScript以實現(xiàn)。優(yōu)點是基本所有瀏覽器都支持，缺點是會導(dǎo)致部分瀏覽器的狀態(tài)條一直為讀取狀態(tài)且鼠標狀態(tài)為忙碌，影響用戶體驗。
2. Htmlfile ActiveX object
通過將HTML IFrame元素置于一個ActiveX中，規(guī)避了1中所提到的兩個缺點。其缺點很顯然，僅IE支持，如Google Gtalk。另外Zeitoun的comet-iframe將提供Javascript對象支持內(nèi)嵌IFrame，支持IE,FF。
3. Multipart XHR(XMLHttpRequest)
1995年，Netscape中增加了一個特性叫Server Push，這個特性允許服務(wù)器端在同一個Http Response中發(fā)送圖片或HTML頁的新版本到瀏覽器端，通過在HTML頭聲明ContentType為multipart/x-mixed-replace實現(xiàn)，瀏覽器會使用新版本的HTML替換已有頁面。不過這個特性僅在使用Gecko內(nèi)核的瀏覽器中支持。
4. XHR streaming
通過自定義返回數(shù)據(jù)格式，在瀏覽器端捕獲onreadystatechange 事件并在readyState=3時回調(diào)對應(yīng)JavaScript方法來處理數(shù)據(jù)并實現(xiàn)。此方式IE不可行。
5. XHR long polling
上述若干方法兼容性都不是很好，而XHR long polling在所有支持XHR的瀏覽器中都可以使用。其實現(xiàn)方式為：瀏覽器建立一個異步連接，當服務(wù)器響應(yīng)后回調(diào)JS方法，然后重新建立新的連接并等待服務(wù)器端下一次響應(yīng)。
6. Dynamic script tag long polling
該方式更好解決跨域調(diào)用問題，雖然跨域頁面的互操作也可以通過代理來解決。
7. Server-sent events
HTML5草案中的新元素event source。
可靠性
代理服務(wù)器和防火墻可能對Comet應(yīng)用有不利影響。一般防火墻都會斷開已建立時間過長的連接。大多數(shù)Comet框架的解決辦法是重建連接。
另外，代理服務(wù)器可能緩存被推送的數(shù)據(jù)，使應(yīng)用喪失實時性。
可擴展性
因為Comet應(yīng)用實時發(fā)送服務(wù)器端事件，一般會比其他的傳統(tǒng)web應(yīng)用消耗更多資源，使得其擴展性相對較差。
首先，Comet應(yīng)用需要在服務(wù)器和瀏覽器間維持至少一個長連接，而傳統(tǒng)的web服務(wù)器按照頁面-頁面請求進行的設(shè)計和優(yōu)化使其在無法在同一時間維持如此多的連接。這導(dǎo)致Comet應(yīng)用無法在一個web server上處理大量請求，垂直擴展性差。
垂直擴展性差的原因在于傳統(tǒng)的web server如Apache等的處理線程使用同步IO。每個請求被分配一個線程去處理，并盡可能盡快處理完畢并關(guān)閉連接以處理下一個請求。但Comet應(yīng)用建立的連接是持久的，處理請求的每個線程不能用于處理其他請求，如果有大量長連接建立，web server就可能無法處理新發(fā)起的請求。
Jetty和Tomcat等Web應(yīng)用服務(wù)器已為Comet應(yīng)用進行優(yōu)化(ContinuationServlet, 但是因為不是標準的servlet實現(xiàn)，不具備服務(wù)器兼容性)，使用異步IO(JDK5之后)來處理長連接，一定數(shù)目的線程去輪詢各個連接并在到達每個連接時將所需數(shù)據(jù)推送到瀏覽器端。此類服務(wù)器不僅可以處理比線程服務(wù)器多的多的長連接，而且隨著連接數(shù)增加，處理延遲被均攤到每個連接，對用戶影響小。值得注意的是，sun新提交的JSR315 servlet3.0也包括了comet，今后將成為J2EE服務(wù)器的標準實現(xiàn)。
另外，一般Comet應(yīng)用都是交互性的，允許多用戶間通訊，因此將處理任務(wù)分派到多個server去處理有困難。即水平擴展性差。
對水平擴展性的一種解決方式是按照事件對服務(wù)器進行分組，將訂閱某組事件的請求轉(zhuǎn)發(fā)到指定的服務(wù)器上。
注意事項
1. HTTP1.1標準中有如下規(guī)定：“A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy”，并且此規(guī)則被包括IE和FF在內(nèi)的絕大多數(shù)瀏覽器遵守。因此，當comet占用一個http長連接，將可能導(dǎo)致瀏覽器不能為ajax請求創(chuàng)建新的連接，比如瀏覽器正在讀取大量圖片時。
2. 如果有新的公共數(shù)據(jù)需要push，所有servlet要同時將數(shù)據(jù)push出去，在push之前還會有查詢，這樣對cpu內(nèi)存和網(wǎng)絡(luò)都會有較大消耗，而且是同時的，會造成共振效應(yīng)。
可以考慮使用一個公共的查詢線程來負責(zé)，request被放入一個隊列，查詢線程負責(zé)輪詢所有request，來將各自需要的數(shù)據(jù)push到client，這樣可以響應(yīng)的并發(fā)連接數(shù)可能會多很多，且避免了共振。
其他解決方案
鑒于瀏覽器對Comet的直接支持較差，有部分開發(fā)者使用了flash和java applet等瀏覽器插件來實現(xiàn)實時響應(yīng)。只要安裝了相應(yīng)插件，該方式不用考慮瀏覽器的差異，通用性較好，且不用占用HTTP連接。
Comet與Ajax的區(qū)別
請見下圖。
NIO
對比
以Jetty的ContinousServlet(使用NIO)和標準Servlet性能對比來說明：
代碼段I:BlockingServlet(未使用NIO)：
public class BlockingServlet extends HttpServlet {
public void service(HttpServletRequest req, HttpServletResponse res)
throws java.io.IOException {
String reqId = req.getParameter("id");
res.setContentType("text/plain");
res.getWriter().println("Request: "+reqId+"\tstart:\t" + new Date());
res.getWriter().flush();
try {
Thread.sleep(2000);
} catch (Exception e) {}
res.getWriter().println("Request: "+reqId+"\tend:\t" + new Date());
}
}
現(xiàn)在可以觀察到 servlet 響應(yīng)一些同步請求的行為。展示了控制臺輸出，五個使用 lynx 的并行請求。命令行啟動五個 lynx 進程，將標識序號附加在請求 URL 的后面。
輸出I:對 BlockingServlet 并發(fā)請求的輸出:
$ for i in 'seq 1 5' ; do lynx -dump localhost:8080/blocking?id=$i & done
Request: 1 start: Sun Jul 01 12:32:29 BST 2007
Request: 1 end: Sun Jul 01 12:32:31 BST 2007
Request: 2 start: Sun Jul 01 12:32:31 BST 2007
Request: 2 end: Sun Jul 01 12:32:33 BST 2007
Request: 3 start: Sun Jul 01 12:32:33 BST 2007
Request: 3 end: Sun Jul 01 12:32:35 BST 2007
Request: 4 start: Sun Jul 01 12:32:35 BST 2007
Request: 4 end: Sun Jul 01 12:32:37 BST 2007
Request: 5 start: Sun Jul 01 12:32:37 BST 2007
Request: 5 end: Sun Jul 01 12:32:39 BST 2007
輸出I和預(yù)期一樣。因為 Jetty 只可以使用一個線程執(zhí)行 servlet 的 service() 方法。Jetty 對請求進行排列，并按順序提供服務(wù)。當針對某請求發(fā)出響應(yīng)后將立即顯示時間戳（一個 end 消息），servlet 接著處理下一個請求（后續(xù)的 start 消息）。因此即使同時發(fā)出五個請求，其中一個請求必須等待 8 秒鐘的時間才能接受 servlet 處理。
請注意，當 servlet 被阻塞時，執(zhí)行任何操作都無濟于事。這段代碼模擬了請求等待來自應(yīng)用程序不同部分的異步事件。這里使用的服務(wù)器既不是 CPU 密集型也不是 I/O 密集型：只有線程池耗盡之后才會對請求進行排隊。
現(xiàn)在，查看 Jetty 6 的 Continuations 特性如何為這類情形提供幫助。代碼段II展示了代碼段I中使用 Continuations API 重寫后的 BlockingServlet。
代碼段II:. ContinuationServlet
public class ContinuationServlet extends HttpServlet {
public void service(HttpServletRequest req, HttpServletResponse res)
throws java.io.IOException {
String reqId = req.getParameter("id");
Continuation cc = ContinuationSupport.getContinuation(req,null);
res.setContentType("text/plain");
res.getWriter().println("Request: "+reqId+"\tstart:\t"+new Date());
res.getWriter().flush();
cc.suspend(2000);
res.getWriter().println("Request: "+reqId+"\tend:\t"+new Date());
}
}
輸出II: 對 ContinuationServlet 的五個并發(fā)請求的輸出
$ for i in 'seq 1 5' ; do lynx -dump localhost:8080/continuation?id=$i & done
Request: 1 start: Sun Jul 01 13:37:37 BST 2007
Request: 1 start: Sun Jul 01 13:37:39 BST 2007
Request: 1 end: Sun Jul 01 13:37:39 BST 2007
Request: 3 start: Sun Jul 01 13:37:37 BST 2007
Request: 3 start: Sun Jul 01 13:37:39 BST 2007
Request: 3 end: Sun Jul 01 13:37:39 BST 2007
Request: 2 start: Sun Jul 01 13:37:37 BST 2007
Request: 2 start: Sun Jul 01 13:37:39 BST 2007
Request: 2 end: Sun Jul 01 13:37:39 BST 2007
Request: 5 start: Sun Jul 01 13:37:37 BST 2007
Request: 5 start: Sun Jul 01 13:37:39 BST 2007
Request: 5 end: Sun Jul 01 13:37:39 BST 2007
Request: 4 start: Sun Jul 01 13:37:37 BST 2007
Request: 4 start: Sun Jul 01 13:37:39 BST 2007
Request: 4 end: Sun Jul 01 13:37:39 BST 2007
輸出II中有兩處需要重點注意。首先，每個 start 消息出現(xiàn)兩次；先不要著急。其次，更重要的一點，請求現(xiàn)在不需排隊就能夠并發(fā)處理，注意所有 start 和 end 消息的時間戳是相同的。因此，每個請求的處理時間不會超過兩秒，即使只運行一個 servlet 線程。
支持
現(xiàn)有Jetty6.1.6和Tomcat6以上版本提供非標準的NIO Servlet實現(xiàn)。未來Servlet 3.0標準中將包含對標準實現(xiàn)的規(guī)范。
性能對比
性能對比使用參考資料中的部分內(nèi)容，原文摘抄如下：
The following table shows that a Web 1.0 server can handle 10000 users with 500 threads and 36MB of thread stacks, which is easily achievable with current JVMs and servers. For a Web 2.0 application these requirements explode an order of magnitude to 10600 threads and 694MB of stack memory, which is pushing the limits of current servers without even considering the resource requirements of the application.Web 2.0 Comet applications can be implemented with continuations with only a modest increase in the server requirements:
Formula
Web 1.0
Web 2.0 + Comet
Web 2.0 + Comet + Continuations
Users
u
10000
10000
10000
Requests/Burst
b
5
2
2
Burst period (s)
p
20
5
5
Request Duration (s)
d
0.200
0.150
0.175
Poll Duration (s)
D
0
10
10
Request rate (req/s)
rr=u*b/20
2500
4000
4000
Poll rate (req/s)
pr=u/d
0
1000
1000
Total (req/s)
r=rr+pr
2500
5000
5000
Concurrent requests
c=rr*d+pr*D
500
10600
10700
Min Threads
T=c
T=r*d
500
-
10600
-
-
875
Stack memory
S=64*1024*T
32MB
694MB
57MB
A項目中Comet的使用
在A項目中根據(jù)Bayeux協(xié)議實現(xiàn)進行封裝和修改，完成A功能需求。
在后臺代碼中，通過增加消息體內(nèi)容的類型定義，覆寫B(tài)ayeux協(xié)議中定義的事件回調(diào)函數(shù)，實現(xiàn)A的數(shù)據(jù)發(fā)送：
l 覆寫subscribe回調(diào)函數(shù)，實現(xiàn)對訂閱者的緩存，并對新用戶進行歷史留言發(fā)送
l 覆寫publish回調(diào)函數(shù)，實現(xiàn)IP屏蔽、屏蔽詞過濾、已發(fā)布消息緩存、更新訪談最高在線人數(shù)和消息發(fā)布的操作；
l 覆寫協(xié)議實現(xiàn)的默認初始化函數(shù)，實現(xiàn)頻道創(chuàng)建、訂閱和發(fā)布的安全驗證；
l 增加消息體中IP地址、發(fā)布時間、發(fā)言類型、用戶數(shù)量等的定義，并在消息接收Servlet和后臺發(fā)布中對原始消息體進行封裝和補充。
為了保證效率，后臺程序盡量使用緩存和線程輪詢，通過JDK語法和Concurrent包的工具類對競爭資源進行同步。
前臺系統(tǒng)，使用Dojo對JSON消息體進行封裝發(fā)送和解析，優(yōu)化歷史消息顯示策略，實時進行新消息發(fā)送和接收。
l 創(chuàng)建JavaScript類，實現(xiàn)對頁面操作的封裝。
l 對不同的訪談定義不同的頻道編號，并分別生成各自靜態(tài)頁，便于今后的服務(wù)拆分和管理。
l 為不影響前臺瀏覽器效率，對接收到的消息進行緩存，批量進行頁面操作，避免頻繁操作(700次/S)導(dǎo)致瀏覽器CPU占用率過高。
Dojo和Bayeux簡介
Dojo是一套重量級的，強大的面向?qū)ο蟮腏avaScript庫，包括dojo和dojox兩大部分。為開發(fā)富客戶端應(yīng)用提供了一套現(xiàn)成的工具庫。
DWR也已加入Dojo，Struts2也整合了dojo，且很多IDE也提供過了對DOJO的支持和良好的調(diào)試環(huán)境，包括Eclipse WTP+ATF,Netbeans5以上。
Bayeux是Dojo基金會定義的一個協(xié)議，應(yīng)Comet應(yīng)用的需要而產(chǎn)生，其目標是消除不同WebServer的Comet實現(xiàn)間的差異，以及不同瀏覽器腳本使用Comet的差異并提高已有代碼的重用率。Bayeux是第一個比較全面的實現(xiàn)Comet的協(xié)議。特別是對long-polling，callback-polling，iframe這幾種comet的實現(xiàn)手段都能支持.
Bayeux使用JSON作為數(shù)據(jù)封裝格式，使用long polling方式獲取服務(wù)端數(shù)據(jù)，以publish/subscribe方式發(fā)布和訂閱消息。
備注
Multipart/x-mixed-replace示例
<%
response.setContentType("multipart/mixed;boundary=BOUNDARY");
int i = 1;
while(i>0) {
out.println("--BOUNDARY\r\n");
%>
<html>
<head><title>百度一下，你就知道 </title>
</head>
<body>
<%
out.println("push "+i+"<br/>");
out.flush();
try {
Thread.currentThread().sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
%>
</body>
</html>
<%
i++;
}
%>
Pushlet簡介
Pushlet 是一個開源的 Comet 框架，在設(shè)計上有很多值得借鑒的地方，對于開發(fā)輕量級的 Comet 應(yīng)用很有參考價值。
Pushlet 使用了觀察者模型：客戶端發(fā)送請求，訂閱感興趣的事件；服務(wù)器端為每個客戶端分配一個會話 ID 作為標記，事件源會把新產(chǎn)生的事件以多播的方式發(fā)送到訂閱者的事件隊列里。
pushlet 提供了基于 AJAX 的 JavaScript 庫文件用于實現(xiàn)長輪詢方式的“服務(wù)器推”；還提供了基于 iframe 的 JavaScript 庫文件用于實現(xiàn)流方式的“服務(wù)器推”。
JavaScript 庫做了很多封裝工作：
定義客戶端的通信狀態(tài)：STATE_ERROR、STATE_ABORT、STATE_NULL、STATE_READY、STATE_JOINED、STATE_LISTENING；
保存服務(wù)器分配的會話 ID，在建立連接之后的每次請求中會附上會話 ID 表明身份；
提供了 join()、leave()、subscribe()、 unsubsribe()、listen() 等 API 供頁面調(diào)用；
提供了處理響應(yīng)的 JavaScript 函數(shù)接口 onData()、onEvent()…
網(wǎng)頁可以很方便地使用這兩個 JavaScript 庫文件封裝的 API 與服務(wù)器進行通信。
客戶端與服務(wù)器端通信信息格式:
pushlet 定義了一套客戶與服務(wù)器通信的信息格式，使用 XML 格式。定義了客戶端發(fā)送請求的類型：join、leave、subscribe、unsubscribe、listen、refresh；以及響應(yīng)的事件類型：data、join_ack、listen_ack、refresh、heartbeat、error、abort、subscribe_ack、unsubscribe_ack。
服務(wù)器端事件隊列管理:
pushlet 在服務(wù)器端使用 Java Servlet 實現(xiàn)，其數(shù)據(jù)結(jié)構(gòu)的設(shè)計框架仍可適用于 PHP、C 編寫的后臺客戶端。
Pushlet 支持客戶端自己選擇使用流、拉（長輪詢）、輪詢方式。服務(wù)器端根據(jù)客戶選擇的方式在讀取事件隊列（fetchEvents）時進行不同的處理。“輪詢”模式下 fetchEvents() 會馬上返回。”流“和”拉“模式使用阻塞的方式讀事件，如果超時，會發(fā)給客戶端發(fā)送一個沒有新信息收到的“heartbeat“事件，如果是“拉”模式，會把“heartbeat”與“refresh”事件一起傳給客戶端，通知客戶端重新發(fā)出請求、建立連接。
客戶服務(wù)器之間的會話管理:
服務(wù)端在客戶端發(fā)送 join 請求時，會為客戶端分配一個會話 ID， 并傳給客戶端，然后客戶端就通過此會話 ID 標明身份發(fā)出 subscribe 和 listen 請求。服務(wù)器端會為每個會話維護一個訂閱的主題集合、事件隊列。
服務(wù)器端的事件源會把新產(chǎn)生的事件以多播的方式發(fā)送到每個會話（即訂閱者）的事件隊列里。
Comet討論
Joe Walker (23 October 2007). “Why Comet is of Growing Importance”. Comet Daily. Retrieved 4 Dec 2007.
Rodney Gedda (14 October 2005). “Desktop apps coming to the Web: Google”. Computerworld. Retrieved 29 Nov 2007.
Paul Graham (November 2005). “Web 2.0”. paulgraham.com. Retrieved 29 Nov 2007.
Alex Russell (3 March 2006). “Comet: Low Latency Data for the Browser”. Continuing Intermittent Incoherency. Retrieved 29 Nov 2007.
Greg Wilkins (6 November 2007). “Comet is Always Better Than Polling”. Comet Daily. Retrieved 29 Nov 2007.
Jacob Rus (11 December 2007). “The Future of Comet: Part 1, Comet Today”. Comet Daily. Retrieved 14 Dec 2007.
Andrew Betts (2007). “Browser Techniques”. Meteor website. Retrieved 29 Nov 2007.
Maciej Stachowiak (26 June 2007). “Re: XMLHttpRequest and readyState==3”. Webkit-dev mailing list. Retrieved 29 Nov 2007.
Alex Russell (12 February 2006). “What else is buried down in the depths of Google’s amazing JavaScript?”. Continuing Intermittent Incoherency. Retrieved 29 Nov 2007.
For advice about avoiding garbage collection bugs when implementing Comet with htmlfiles, see:
Michael Carter (25 October 2007). “HTTP Streaming and Internet Explorer”. Comet Daily. Retrieved 29 Nov 2007.
Michael Carter (18 November 2007). “IE ActiveX("htmlfile") Transport, Part II”. Comet Daily. Retrieved 29 Nov 2007.
Johnny Stenback, et al. (March–April 2004). “Bug 237319 – Add support for server push using multipart/x-mixed-replace with XMLHttpRequest”. Mozilla Bugzilla bug tracker. Retrieved 29 November 2007. Also see:
Alex Russell (6 August 2005). “Toward server-sent data w/o iframes”. Continuing Intermittent Incoherency. Retrieved 29 Nov 2007.
Rob Butler, et al. (June 2006). “Bug 14392: Add support for multipart/x-mixed-replace to XMLHttpRequest”. Webkit Bugzilla bug tracker. Retrieved 29 Nov 2007.
Alex Russell (21 December 2006). “Adventures In Comet and Multipart Mime”. Continuing Intermittent Incoherency. Retrieved 29 Nov 2007.
Andrew Betts (4 December 2007). “Cross Site Scripting Joy”. Comet Daily. Retrieved 14 Dec 2007.
Bob Ippolito (5 December 2005). “Remote JSON – JSONP”. from __future__ import *. Retrieved 30 Nov 2007.
Alex Russell (22 July 2006). “Cross Domain Comet”. Continuing Intermittent Incoherency. Retrieved 30 Nov 2007.
HTTP 1.1 specification, section 8.14. W3C. Retrieved 30 Nov 2007.
Alessandro Alinone (December 2005). “Changing the Web Paradigm”. Lightstreamer white paper. Retrieved 14 Dec 2007.
Michael Carter (24 October 2007). “Comet for Highly Scalable Applications”. Presentation at The Ajax Experience Boston. (Link goes to PDF slides). Retrieved 30 Nov 2007.
Alessandro Alinone (19 October 2007). “Comet and Push Technology”. Comet Daily. Retrieved 14 Dec 2007.
Just Van Den Broecke (3 January 2007). “Pushlets: Send events from servlets to DHTML client browsers”. JavaWorld. Retrieved 14 Dec 2007.
Dion Almaer (29 September 2005). “Jotspot Live: Live, group note-taking” (interview with Abe Fettig). Ajaxian. Retrieved 15 Dec 2007.
Matt Marshall (15 December 2006). “Renkoo launches event service — in time to schedule holiday cocktails”. Venture Beat. Retrieved 15 Dec 2007.
Alex Russell, et al. (2007). Bayeux Protocol specification, 1.0 draft 1. Dojo Foundation. Retrieved 14 Dec 2007.
Jesse James Garrett (18 February 2005). “Ajax: A New Approach to Web Applications”. Adaptive Path. Retrieved 29 Nov 2007.
進階資料
Ian Hickson, et al. (2005–2007). HTML 5 specification, Section 6.2: Server-sent DOM events. WHATWG. Retrieved 14 Dec 2007
Rohit Khare (August 2005). “Beyond AJAX: Accelerating Web Applications with Real-Time Event Notification”. KnowNow white paper (link from the Wayback Machine). Retrieved 14 Dec 2007
