CometD JavaScript 傳輸

phoneone 2011-11-16

展開全文

原文地址：

http:///documentation/cometd-javascript/transports

CometD JavaScript 傳輸

由 sbordet 提交于星期三，2009/7/29-13:09。

JavaScript CometD 傳輸

Bayeux 規(guī)范定義了兩個強制性傳輸過程：

long-polling（長輪詢）

callback-polling（回調(diào)輪詢）

JavaScript CometD 實現(xiàn)完全支持這兩個傳輸過程。

最新的瀏覽器（例如，火狐 3.5）使用長輪詢傳輸也可以跨域Bayeux通信，請參閱下面的跨域模式。

長輪詢傳輸

長輪詢傳輸是默認傳輸。

該傳輸被用于在同一個域，和跨域模式下與 Bayeux 服務(wù)器發(fā)生通信（見下文）。

通過簡單的XMLHttpRequest（內(nèi)容類型的text/json的POST請求）調(diào)用將數(shù)據(jù)發(fā)送到服務(wù)器。

回調(diào)輪詢傳輸

回調(diào)輪詢傳輸是與 Bayeux 服務(wù)器在不同域發(fā)生通信時使用的傳輸（當不支持跨域模式時，見下文的跨域模式章節(jié)）。

當?shù)揭粋€不同域去下載腳本時，眾所周知XMLHttpRequest的調(diào)用是被限制的。（請參閱下面替代的跨域模式解決方案）。

為了克服起始地址的限制，此傳輸使用 JSONP 腳本注入：而不是使用注入src 屬性指向 Bayeux 服務(wù)器的<script>元素的XMLHttpRequest。

瀏覽器會注意到腳本元素注入并執(zhí)行 GET 請求到指定源的 URL。

Bayeux 服務(wù)器是意識到這是一個 JSONP 請求并答復(fù)由瀏覽器執(zhí)行的JavaScript 函數(shù)（并在 JavaScript Cometd 現(xiàn)實中回調(diào)）。

在使用此傳輸中有三個主要缺點：

這個傳輸是啰嗦的。

這是因為，瀏覽器按順序執(zhí)行注入的腳本，直到腳本已完全"下載"或它無法執(zhí)行。

例如，假設(shè)一個腳步注入是涉及長輪詢的通信，或是為了發(fā)布一條消息。瀏覽器注入長輪詢腳本，要求 Bayeux 服務(wù)器上，但 Bayeux 服務(wù)器保存請求等待服務(wù)器端事件（這樣的"腳本"未有"下載）"。瀏覽器注入長輪詢腳本，Bayeux 服務(wù)器有了一個請求，但是Bayeux 服務(wù)器要留著這個請求以等待服務(wù)器事件（所以“腳本”沒有“下載”）。然后，瀏覽器注入發(fā)布腳本，那個被服務(wù)器留著的請求被回復(fù) （所以“腳本”完成“下載”）。不管怎么樣，瀏覽器沒有執(zhí)行第二個腳本，因為沒有執(zhí)行第一個腳本（從它沒有完成“下載”）。在這些條件下：在長輪詢返回后，發(fā)布僅僅執(zhí)行一次。為了避免Bayeux 服務(wù)器有情況，在使用回調(diào)輪詢傳輸?shù)那闆r下，為每條從客戶端來的消息使用客戶端長輪詢，這就是為什么傳輸是啰嗦的：長輪詢通常頻繁返回。