For CometD support, custom code development, clustering advices, scalability and performance tuning, contact the core CometD developers at

Chapter 6. Concepts & Architecture

6.1. Definitions
6.1.1. Channel Definitions
6.2. The High Level View
6.3. The Lower Level View
6.3.1. Sessions
6.3.2. The Server
6.3.3. Listeners
6.3.4. Message Processing
6.3.5. Threading
6.3.6. Application Interaction
6.3.7. Bayeux Protocol

The CometD project implements various Comet techniques to provide a scalable web messaging system, one that can run over HTTP or over other emerging web protocols such as WebSocket.

The client is the entity that initiates a connection, and the server is the entity that accepts the connection. The connection established is persistent – that is, it remains open until either side decides to close it.

Typical clients are browsers (after all, this is a web environment), but might also be other applications such as Java applications, browser plugin applications (such as Silverlight), or scripts in any scripting language.

Depending on the Comet technique employed, a client might open more than one physical connection to the server, but you can assume there exists only one logical conduit between one client and the server.

The CometD project uses the Bayeux protocol (see Appendix C, The Bayeux Protocol Specification v1.0) to exchange information between the client and the server. The unit of information exchanged is a Bayeux message formatted in JSON. A message contains several fields, some of which the Bayeux protocol mandates, and others that applications might add. A field is a key/value pair; saying that a message has a foo field means that the message has a field whose key is the string foo.

All messages the client and server exchange have a channel field. The channel field provides the characterization of messages in classes. The channel is a central concept in CometD: publishers publish messages to channels, and subscribers subscribe to channels to receive messages. This is strongly reflected in the CometD APIs.

A channel is a string that looks like a URL path such as /foo/bar, /meta/connect or /service/chat.

The Bayeux specification defines three types of channels: meta channels, service channels and broadcast channels (see Appendix C, The Bayeux Protocol Specification v1.0).

A channel that starts with /meta/ is a meta channel, a channel that starts with /service/ is a service channel, and all other channels are broadcast channels.

A message whose channel field is a meta channel is referred to as a meta message, and similarly there are service messages and broadcast messages.

The application creates service channels and broadcast channels; an application can create as many as it needs, and can do so at any time.