cometd: Bayeux Protocol

http://svn.xantus.org/shortbus/trunk/bayeux/bayeux.html

 

要了解DOJO的COMETD的实现，最好先了解一下这个协议

 

http://cometd.com/

 

http://dojotoolkit.org/

 

http://jetty.mortbay.org/jetty-6/

 

http://cometdproject.dojotoolkit.org/

 

 

Cometd

The Scalable Comet Framework.

Cometd is a scalable HTTP-based event routing bus that uses a push technology pattern known as Comet. The term 'Comet' was coined by Alex Russell in his post 'Comet: Low Latency Data for the Browser'. The letter d is for 'Daemon', as described by Answers.com, Daemon is a program or process that sits idly in the background until it is invoked to perform its task. Cometd consists of a protocol spec called Bayeux, JavaScript libraries (dojo toolkit), and an event server.

 

Cometd = Comet + Daemon = dojo （js） + Bayeux（协议） + Jetty（事件驱动的WEB服务器）

 

Messages

Submitted by gregwilkins on Thu, 06/05/2008 - 02:53.

Specification vs Instantiation vs Transport

Bayeux messages:

• are specified in JSON.
• should be instantiated in the natural object representation of the language used for the client/server
• may be transported via any appropriate serialization that the specific transport supports. This may be a JSON String, an XML document or some other serialization.

A simple bayuex message could be specified as:

{channel:"/some/channel",data:[1,2,3]}

 

This message has a natural instantiation in javascript. The message could be transported as a wire format that uses the JSON as described above, or the instantiated javascript objects could be serialized to XML if some transported wished. If delivered to a java bayeux implementation, then the message would be instantiated as a java.util.Map<String,Object> instance that contained java.lang.String keys and values of type java.lang.String and java.util.Array<Object>.

Reserved Fields

All fields in the top level of a json message are reserved for the use of the protocol. The following fields are the most important defined fields:

channel

All messages MUST have a channel field with a string value that identifies the handler for the message.

clientId

A message MAY have a clientId field with a string value that with identity of the client. ClientIDs are only unique within a single non-cluster Bayeux server and are only valid for the duration of the Bayeux connected state. They should be considered roughly equivalent to a HTTP session ID and treated the same with regards to security and longevity.

id

Any message may contain an id field with a string value that identifies the message. The id is generated by the creator of the message and it's uniqueness or otherwise is application specific.

data

The message payload. An arbitrary object

advice

Transport specific parameters.

ext

Extension space

successful

Indicates the success of a protocol operation. Used in a response message

error

Error code and message

 

Channel

Submitted by gregwilkins on Thu, 06/05/2008 - 02:52.

Channels look like URIs: /foo/bar

Channels starting with /meta/ are reserved for the use of the protocol (eg /meta/handshake)

Channels are by default broadcast publish subscribe, so that all subscribers will see all messages published to the channel on the server.

Messages may be privately delivered to a specific client + channel combination and bypass any default routing.

Channels starting with /service are server only publish/subscribe. Messages published to /service channels will only be delivered to server side clients.
Messages may still be explicitly delivered to a client on a /service channel

1.4.6. Two connection operation

In order to achieve bi-directional communications, a Bayeux client will use two HTTP connections to a Bayeux server so that both server to client and client to server messaging may occur asynchronously:

BC ---------- U ---------- P ------------ O ---------- BS
 | ---M0--->  |            |              |            |
 |            | ------ req0(M0) --------> |            |
 |            |            |              | ----M0---> |
 ~            ~            ~              ~            ~ wait
 | --M1(E1)-> |            |              |            |
 |            | ----- req1(M1(E1))------> |            |
 |            |            |              | --M1(E1)-> |
 |            |            |              | <---M2---- |
 |            | <---- resp1(M2)---------- |            |
 | <---M2---  |            |              |            |
 ~            ~            ~              ~            ~ wait
 |            |            |              | <-M3(E2)-- |
 |            | <-----resp2(M3(E2))------ |            |
 | <-M3(E2)-- |            |              |            |
 | ---M4--->  |            |              |            |
 |            | ------req3(M4)----------> |            |
 |            |            |              | ----M4---> |
 ~            ~            ~              ~            ~ wait

HTTP requests req0 and req1 are sent on different TCP/IP connections, so that the response to req1 may be sent before the response to req0. Implementations MUST control HTTP pipelining so that req1 does not get queued behind req0 and thus enforce an ordering of responses. 

 

 

...to be continued.