Applications of Comet can be roughly categorized into event- and REST-based messaging. The characteristics of a Comet application define which Comet model is used, and different technological approaches can be used to maximize performance and scalability based upon the form of Comet.
In event-based Comet, messages are sent between agents with no assumptions about the meaning of the messages. One of the most common forms of event messaging is the publish/subscribe mechanism based on channels, in which agents can subscribe to channels and publish events to channels. In this form of Comet, messages are explicitly formed by agents, and the only commonly understood meaning attached to the message is the name of the channel. Beyond that, agents must understand what the messages mean and the impact of the messages. The underlying mechanism can not make assumptions about the requirements of the delivery of the messages or about acceptable message reordering. The Bayeux protocol is well designed for this form of Comet.
User-centric Event Messaging
User-centric event messaging is a particular form of event messaging that is used for chatting. While the publish/subscribe mechanism usually uses string-keyed channels, in user-centric messaging channels equate to users. Each user represents a channel, and the user is implicitly subscribed to their own channel. In terms of pub/sub channels, when other users wish to send a message to a user, they essentially publish an event to the other user’s channel.
Comet can also be used as a data synchronization technique. In these types of Comet usages, applications present users with information that is volatile and subject to frequent and meaningful change, and Comet is used to keep the information up to date. In Joe Walker’s case for Comet, he argued that the reason for the growing importance of Comet is that we spend more time on a page, while the information behind it is changing faster. This type of scenario that he described is data-centric Comet. In this form of Comet, messages are pushed to clients to alert them to changes in the data, so that clients can have the latest available data.
Comet used in this manner can take advantage of meaningful semantics that provide information about the purpose of messages and how that purpose impacts delivery constraints. Comet can actually be advised by the concepts of Representational State Transfer (REST) that have provided the scalable architecture for pull-based HTTP. The concepts of REST and perhaps even the semantics of HTTP can be applied to push-based communication. There are several properties of this form of messaging that can be used advantageously for architecture and abstraction of data/messaging interoperability.
Borrowing from REST, we can define messages in terms of what resource they operate on. Each resource has a unique identifier (URI for example) that identifies the resource. Messages are then composed of updates representing the data resource they reference. Semantics can indicate whether the message contains the entirety of the resource (as GET and PUT do in HTTP). An important consequence of this form of messaging is that architectures can understand when messages supersede previous messages. It can also understand the idempotence of messages. Frameworks can also utilize the REST semantics to understand how synchronized data needs to be updated.
For example, a stock ticker is a type of data-centric Comet application. How can we apply REST to a stock ticker? Let’s assign a URI/id to one of our stocks, which we will call: http://mystocks.com/ACME . Now let us assume we can get the value of the stock by simply doing a GET request at that address and getting the value:
Now suppose that we have a Comet connection and that we receive a message:
If a client understands HTTP semantics here, it can evaluate this message as an update to the data resource provided by http://mystocks.com/ACME .
Another message could be sent to the client with a body of 13.01 to provide an even newer value for the resource. Some significant advantages can be derived from a convention with commonly understood REST semantics:
- Generic code can be written to handle messages as data modification requests and properly update data corresponding to the identified resource. This can be handled without specific code for each message.
- Architecture can make optimizations based on messages. When a PUT method is pushed to a client, the idempotent nature of the message can inform optimization. The message can be sent multiple times instead of once without harm.
Also, if another message referencing the same resource is queued to be sent to a client, the previous message can be safely discarded, as it is not necessary for the client to be made aware of the in-between state. For example, when a third update to the ACME stock is available to send to the client, it is no longer necessary to send the second one. If it is still in the queue it does not need to be sent, or if it failed to be sent, it does not need to be retried. This allows architectures to realize flexibility in distributing messages at a different rate than receiving them. For example, a stock server may be receiving updates on the ACME stock every second, but if resources such as bandwidth are slim, it can safely adjust and scale back the number of updates it sends to client (perhaps one every three seconds).
Some applications of Comet blur the line between event and data centric usage. For example, a progress bar may receive messages pushed from a server about the update of an operation. The messages may indicate the percentage of completion. Such messages can utilize the idempotent characteristics of REST Comet, with the latest percentage update superseding all previous messages. However, at the same time progress bars do not usually reference persistent resources, but rather transient actions.
By understanding the application of Comet, architecture and messaging semantics can be adjusted to facilitate optimum scalability and meaningful communication. In data-centric applications, the concepts of REST and the HTTP definitions can be utilized for broadly understood semantics for resource update based messaging. The format of how to communicate these meanings is open question to explore.