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

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.

6.1. Definitions

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.

6.1.1. Channel Definitions

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.

6.1.1.1. Meta Channels

The CometD implementation creates meta channels; applications cannot create new meta channels. Meta channels provide to applications information about the Bayeux protocol (see Section 6.3.7, “Bayeux Protocol”), for example, whether handshakes have been successful or not, or whether the connection with the server is broken or has been re-established.

6.1.1.2. Service Channels

Applications create service channels, which are used in the case of request/response style of communication between client and server (as opposed to the publish/subscribe style of communication of broadcast channels, see below).

6.1.1.3. Broadcast Channels

Applications also create broadcast channels, which have the semantic of a messaging topic and are used in the case of the publish/subscribe style of communication, where one sender wants to broadcast information to multiple recipients.

6.1.1.4. Use of Wildcards in Channels

You can use wildcards to match multiple channels: channel /foo/* matches /foo/bar but not /foo/bar/baz. The latter is matched by /foo/**. You can use wildcards for any type of channel: /meta/* matches all meta channels, and /service/** matches /service/bar as well as /service/bar/baz. Channel /** matches all channels. You can specify the wildcards only as the last segment of the channel, so these are invalid channels: /**/foo or /foo/*/bar.