原文地址：

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

CometD JavaScript 傳輸

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

JavaScript CometD 傳輸

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

long-polling（長輪詢）

callback-polling（回調輪詢）

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

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

長輪詢傳輸

長輪詢傳輸是默認傳輸。

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

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

回調輪詢傳輸

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

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

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

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

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

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

這個傳輸是啰嗦的。

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

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

消息大小是有限的。

支持 IE7是必須，IE7的 GET 請求具有2083字符限制。

對故障的反應較慢。

這是因為，如果腳本注入的 URL返回的是錯誤 （例如 Bayeux 服務器已關閉），會被瀏覽器忽略。

跨域模式

火狐 3.5 介紹了XMLHttpRequest可以在不同域調用的能力（請看火狐 3.5文檔）。

在版本 1.0.0.rc0中， JavaScript CometD 實現(xiàn)也支持它，不需要在客戶端上進行配置 （如果瀏覽器支持客戶端跨域調用，它們將會被使用） 但需要在服務器上做一點配置。請參閱本文檔的服務器配置。

要使用跨域模式，您需要：

一跨域兼容瀏覽器 （例如 Firefox 3.5）

一兼容服務器 （例如：配置了CrossOriginFilter的jetty）

使用這個程序，與 Bayeux 服務器的跨域通信，推薦使用長輪詢傳輸，避免回調輪詢傳輸?shù)谋锥恕?/span>