CometD JavaScript 传输

原文地址：

                  http:///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 服务器的跨域通信，推荐使用长轮询传输，避免回调轮询传输的弊端。