CometD JavaScript 传输

原文地址：

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

 

CometD JavaScript 传输

 

 

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

 

 

JavaScript CometD 传输

 

 

Bayeux 规范定义了两个强制性传输过程：

long-polling（长轮询）

callback-polling（回调轮询）

 

 

JavaScript CometD 实现完全支持这两个传输过程。

 

 

最新的浏览器（例如，火狐 3.5）使用长轮询传输也可以跨域Bayeux通信，请参阅下面的跨域模式。

 

 

长轮询传输

 

 

长轮询传输是默认传输。

该传输被用于在同一个域，和跨域模式下与 Bayeux 服务器发生通信（见下文）。

通过简单的XMLHttpRequest（内容类型的text/json的POST请求）调用将数据发送到服务器。

 

 

回调轮询传输

 

 

回调轮询传输是与 Bayeux 服务器在不同域发生通信时使用的传输（当不支持跨域模式时，见下文的跨域模式章节）。

 

 

当到一个不同域去下载脚本时，众所周知XMLHttpRequest的调用是被限制的。（请参阅下面替代的跨域模式解决方案）。

为了克服起始地址的限制，此传输使用 JSONP 脚本注入：而不是使用注入src 属性指向 Bayeux 服务器的<script>元素的XMLHttpRequest。

浏览器会注意到脚本元素注入并执行 GET 请求到指定源的 URL。

Bayeux 服务器是意识到这是一个 JSONP 请求并答复由浏览器执行的JavaScript函数（并在 JavaScript Cometd 现实中回调）。

 

 

在使用此传输中有三个主要缺点：

这个传输是啰嗦的。

这是因为，浏览器按顺序执行注入的脚本，直到脚本已完全"下载"或它无法执行。

例如，假设一个脚步注入是涉及长轮询的通信，或是为了发布一条消息。浏览器注入长轮询脚本，要求 Bayeux 服务器上，但 Bayeux 服务器保存请求等待服务器端事件（这样的"脚本"未有"下载）"。浏览器注入长轮询脚本，Bayeux 服务器有了一个请求，但是Bayeux 服务器要留着这个请求以等待服务器事件（所以“脚本”没有“下载”）。然后，浏览器注入发布脚本，那个被服务器留着的请求被回复（所以“脚本”完成“下载”）。不管怎么样，浏览器没有执行第二个脚本，因为没有执行第一个脚本（从它没有完成“下载”）。在这些条件下：在长轮询返回后，发布仅仅执行一次。为了避免Bayeux 服务器有情况，在使用回调轮询传输的情况下，为每条从客户端来的消息使用客户端长轮询，这就是为什么传输是啰嗦的：长轮询通常频繁返回。

消息大小是有限的。

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

对故障的反应较慢。

这是因为，如果脚本注入的 URL返回的是错误（例如 Bayeux 服务器已关闭），会被浏览器忽略。

 

 

跨域模式

 

 

火狐 3.5 介绍了XMLHttpRequest可以在不同域调用的能力（请看火狐 3.5文档）。

 

 

在版本 1.0.0.rc0中， JavaScript CometD 实现也支持它，不需要在客户端上进行配置（如果浏览器支持客户端跨域调用，它们将会被使用）但需要在服务器上做一点配置。请参阅本文档的服务器配置。

 

 

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

一跨域兼容浏览器（例如 Firefox 3.5）

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

 

 

使用这个程序，与 Bayeux 服务器的跨域通信，推荐使用长轮询传输，避免回调轮询传输的弊端。