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
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.
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.
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).
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.
You can use wildcards to match multiple channels: channel
/foo/bar but not
The latter is matched by
You can use wildcards for any type of channel:
/meta/* matches all meta channels,
/service/bar as well as
/** matches all channels.
You can specify the wildcards only as the last segment of the channel, so these are invalid channels: