The Scalable Comet Framework.
Cometd = Comet + Daemon = dojo （js） + Bayeux（协议） + Jetty（事件驱动的WEB服务器）
Specification vs Instantiation vs Transport
- 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:
java.util.Map<String,Object> instance that contained
java.lang.String keys and values of type
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:
- All messages MUST have a channel field with a string value that identifies the handler for the message.
- 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.
- 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.
- The message payload. An arbitrary object
- Transport specific parameters.
- Extension space
- Indicates the success of a protocol operation. Used in a response message
- Error code and message
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.