Cometd开发指南.pdf-资料库

8d335f52-5267-409f-ad9d-42532be11bf3.pdf-第1页.png

第1页 / 共37页

8d335f52-5267-409f-ad9d-42532be11bf3.pdf-第2页.png

第2页 / 共37页

8d335f52-5267-409f-ad9d-42532be11bf3.pdf-第3页.png

第3页 / 共37页

8d335f52-5267-409f-ad9d-42532be11bf3.pdf-第4页.png

第4页 / 共37页

8d335f52-5267-409f-ad9d-42532be11bf3.pdf-第5页.png

第5页 / 共37页

8d335f52-5267-409f-ad9d-42532be11bf3.pdf-第6页.png

第6页 / 共37页

8d335f52-5267-409f-ad9d-42532be11bf3.pdf-第7页.png

第7页 / 共37页

8d335f52-5267-409f-ad9d-42532be11bf3.pdf-第8页.png

第8页 / 共37页

Cometd Cometd Cometd Cometd 开发指南 2011- 最后更新:::: 2011- 2011-11111111----24242424 2011- 日期作者变更概要其它

CometD 1111、CometD CometD 2222 概念 CometD CometD 项目实现各种 comet 的技术，提供可伸缩的 Web 消息系统，可以运行在 HTTP 或其他新兴协议，如 WebSocket 的网页协议。定义: 让我们定义客户端为发起连接的实体，服务器接受连接的实体。建立连接是持久的 - 也就是说，它仍然打开，直至任何一方决定关闭它。典型的客户端浏览器（毕竟，我们在 Web 环境），但也可能是其他应用程序，如 Java 应用程序，浏览器插件应用程序（如 Silverlight），或在任何脚本语言的脚本。根据 comet 的技术，客户端可能会打开多个物理连接，连接服务器，但我们可以假设客户端和服务器之间只存在一个逻辑频道。 CometD 项目使用 Bayeux 协议在客户端和服务器之间进行信息交流。交换信息的单位是 Bayeux message，它是 JSON 格式。message 包含几个字段，其中有些是 Bayeux 协议授权，而其他的可能由应用程序添加。一个字段是一个键/值对，比方说 message 有一个 foo 的字段，意味着该 message 有一个字段，其键是字符串 “foo”。所有客户端和服务器之间交换的消息，都有一个频道领域。有3种频道： � （meta channel）元数据频道 � （service channel）服务频道 � （broadcast channel）广播频道元数据频道由 Bayeux 创建实现，应用程序不能创建新的元数据频道。服务频道和广播频道是由应用程序创建的，他们可以在任何时间创建，并且很有必要。频道是由一个字符串代表，并且类似 URL 路径。例如：/meta/handshake， /service/game ， /foo/bar。一个频道以/meta/开头则它是元数据频道，一个频道以/service/开头则它是服

务频道，而所有其他的频道则是广播频道。一个消息频道领域是元数频道则里面的消息是元数据消息，同样的，有服务频道消息和广播频道消息。高层次视图 CometD 实现 Web 消息传递系统，特别是 Web 消息传递系统是基于（publish）发布/（subscribe）订阅范式的。在（publish）发布/（subscribe）订阅消息传递系统中，publish 发出消息，这些消息被赋予类的特点。Subscribe 表示的是订阅他们感兴趣的一个或多个类的消息，并接收他们订阅的兴趣相匹配的唯一消息。发送消息的人，在一般情况下，不知道收件人或多个收件人将收到他们发布的消息。在 CometD 中，频道领域提供已经类化的消息。频道是 CometD 的中心概念：发布者把消息发送到频道里，订阅者订阅这个频道来接收消息。这些将会在 CometD API 中有详细反映，我们可以去查看。消息系统的功能之一是他们的拓扑结构， CometD 实现的是枢纽发言的拓扑结构。在默认配置下，表示有一个中央服务器（中心），并且所有客户端通过管道链接（辐条）连接到该服务器。如图：

在 CometD 中，服务器接受来自发布者发送的消息，如果消息的频道是一个广播频道，则服务器会转发该消息给所有订阅这个频道的订阅者。CometD 服务器的元数据消息和服务消息会被特殊处理，不重新路由到任何用户（实际上，默认情况下，元数据频道是被禁止订阅的，它是一个无操作订阅服务频道）。例如，让我们想象，clientAB 订阅频道/ A 和/ B，clientB 订阅通道/ B，如果发布者发布一个消息到频道/ A，只有 clientAB 将接收它。另一方面，如果发布者发布一个消息到频道/ B，则 clientAB 和 clientB 都将收到消息。此外，如果发布者发布一个消息到频道/ C，则 clientAB 和 clientB 都不会收到的消息，而它将会结束其在服务器上的刚刚开始的征程。重新路由广播消息是服务器的默认行为，而且它不需要任何应用程序代码进行重新路由。从高层次来看，那么，你会看到消息通过客户端和服务器之间的管道来回流动。一个单一的广播消息到达服务器，就重新路由到所有客户端，你可以想像成：当它在服务器上时，该消息是复制一个副本发送到每个客户端（尽管，初一效率的原因，这不完全会发生）。如果发件人也是订阅的这个频道的人，它也会收到发布消息的副本。有悬而未决的问题，但：如果元数据消息和服务消息的旅程在服务器上结束，应用程序可以利用他们来做些什么，？一个客户端怎么与其他的，特殊的客户端进行连接？服务器可以是发布消息的发布者吗？为了回答这些问题和其他问题，我们需要采取细看 CometD 是如何工作的。继续往下阅读一个较低的水平视图在下面的章节中，我们将采取深入探讨 CometD 是如何实施工作的。现在应该明确，CometD，它的中心，是一个客户端/服务器系统，是通过了一项协议，Bayeux 协议进行通信的。在 CometD 实现中，客户端/服务器通信的捕获是用半对象加协议模式：当在客户端上的对象建立与服务器的通信管道时，其通信对象也在服务器上创建，形成两条通道- 逻辑 –连接。在 CometD 中，这种格局的变化是因为有抽象传输消息，出入服务器的需要。传输可以基于 HTTP 协议，也可以基于最近 CometD 版本的 WebSocket 协议（及更

多的传输可插入）。从广义上讲，“客户”是由客户端的对象（用 JavaScript 类化的 org.cometd.Cometd 对象，和用 Java 类化 org.cometd.bayeux.client.ClientSession 的对象）和客户端的传输（用 JavaScript 类化的 org.cometd.Transport 对象和用 Java 类化的 org.cometd.client.transport.ClientTransport 对象）组成的。 “服务器”是一个更复杂的实体，由一个 org.cometd.bayeux.server.BayeuxServer 实例，服务器传输（org.cometd.bayeux.server.ServerTransport 类）的消息处理组件，一个服务器端的对象（ org.cometd.bayeux.server.ServerSession 类）库和频道（org.cometd.bayeux.server.ServerChannel）库组成。如下图：

消息流客户端的半对象把消息传递委托给一个客户端传输，客户端传输负责建立与服务器的频道，并发送该频道的消息。在服务器上，它是服务器传输，接收消息。服务器传输委托一个消息进程给消息处理组件，以处理传入消息，它生成一个消息的回复，并又委托该服务器传输把回复交付给客户端。在上图中，可以看到导管连接的客户端传输和服务器传输，此外 ServerSession 可能参与（只发送，而不是直接接收）发送消息到客户端（通过服务器传输）。 TODO：解释广播消息流是如何工作的，但是这需要引入服务器会话队列的概念 Bayeux 协议客户端与服务器交换的 Bayeux 消息。 Bayeux 协议的要求，一个新的客户端发送的第一条消息是一个握手消息（/meta/handshake 频道上发送的消息）。在服务器上，如果传入的握手消息的处理是成功的，然后 BayeuxServer 创造了一个半服务器端对象的实例（一个 ServerSession），在服务器上，客户端发起握手。当握手处理完成后，服务器发送回给客户端一个答复。客户端进程的握手消息的答复，如果它是成功，开始 - 在幕后 - 与服务器的心跳机制，来交换连接的消息。这个心跳机制的细节取决于客户端上使用的传输工具，可以作为客户端发送连接消息，并期待回复，一段时间后，看到（使用 HTTP 传输时，心跳机制也被称为“长轮询”）。心跳机制，允许客户端检测服务器是否关闭了（客户端将无法接收来自服务器的

连接的消息答复），并允许服务器检测客户端是否关闭了（服务器将不会收到客户端的连接消息请求）。客户端和服务器之间的连接的消息一直都有，直至任何一方决定中断并发送一个 disconnect 的消息（发送/meta/disconnect 断开通道消息）。 JavaScript CometD 2222、CometD CometD JavaScript CometD JavaScript JavaScript 的配置 CometD JavaScript 的配置 JavaScript 的 CometD API：配置和初始化在您用这个思想设置您项目的骨架后，你可能想充分了解如何自定义和配置实现 Cometd 特性的参数。整个 API 可以通过一个单一的原型名为 org.cometd.Cometd 的对象来调用。 Dojo 工具包中有一个名称为 dojox.cometd 的对象实例来调用，而 jQuery 则是用$.cometd。默认的 cometd 对象已经被实例化并配置了默认值，但是还没有开始任何 Bayeux 通信。在它可以启动任何 Bayeux 通信之前，它需要一个强制性参数：Bayeux 服务器的 URL。有2个方式配置此参数： //第一个方式：URL 字符串 cometd.configure（“http://localhost:8080/cometd”）; //第二个方式：配置对象 cometd.configure（{ url：“http://localhost:8080/cometd” }）;

第一种方式是第二种方式的简写。不过，第二种方式允许配置其他配置参数，目前有的参数如表：参数名称要求默认值参数说明 URL Yes 客户端将连的 Bayeux 服务器的 URL LOGLEVEL No info 日志级别。可能的值有：“warn”，“info”， “debug”。用 window.console 输出 maxConnections No 2 用于连接到 Bayeux 服务器的连接的最大数量。只有改变这个值，你才知道究竟什么是客户端的连接限制，排队长轮询要求些什么 backoffIncreme No 1000 这是一个毫秒数，是 nt 每次与 Bayeux 服务器连接失败的递增数。这个时间结束后，将尝试重新连接 maxBackoff No 60000 最大连接失败时间，在达到最大毫秒数后，将不再增加 reverseIncomin No True 控制是否将在登记顺 gExtensions 序相反的顺序调用传

资料库

Cometd开发指南.pdf

相关推荐

后端

热门标签

最新资料