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

The Bayeux Protocol Specification v1.0

Alex Russell

Greg Wilkins

David Davis

Mark Nesbitt

Status of this Document

This document specifies a protocol for the Internet community, and requests discussion and suggestions for improvement. This document is written in the style and spirit of an IETF RFC but is not, as of yet, an official IETF RFC. Distribution of this document is unlimited.

Abstract

Bayeux is a protocol for transporting asynchronous messages (primarily over web protocols such as HTTP and WebSocket), with low latency between a web server and web clients.

C.1. Introduction

Purpose

The primary purpose of Bayeux is to support responsive bidirectional interactions between web clients, for example using using AJAX, and the web server.

Bayeux is a protocol for transporting asynchronous messages (primarily over HTTP), with low latency between a web server and a web client. The messages are routed via named channels and can be delivered:

  • server to client

  • client to server

  • client to client (via the server)

By default, publish/subscribe routing semantics are applied to the channels.

Delivery of asynchronous messages from the server to a web client is often described as server push. The combination of server push techniques with an AJAX web application has been called Comet. CometD is a project by the Dojo Foundation to provide multiple implementation of the Bayeux protocol in several programming languages.

Bayeux seeks to reduce the complexity of developing Comet web applications by allowing implementers to more easily interoperate, to solve common message distribution and routing problems, and to provide mechanisms for incremental improvements and extensions.

Requirements

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. An implementation is not compliant if it fails to satisfy one or more of the MUST or REQUIRED level requirements for the protocols it implements. An implementation that satisfies all the MUST or REQUIRED level and all the SHOULD level requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the MUST level requirements but not all the SHOULD level requirements for its protocols is said to be "conditionally compliant."

Terminology

This specification uses a number of terms to refer to the roles played by participants in, and objects of, Bayeux communication:

client

A program that initiates the communication.

A web client (for example, a HTTP client, but also a WebSocket client) is a program that initiates TCP/IP connections for the purpose of sending web requests. A Bayeux client initiates the Bayeux message exchange and will typically execute within a web client, but it is likely to have also Bayeux clients that execute within web servers.

Implementations may distinguish between Bayeux clients running within a web client and Bayeux clients running within the web server. Specifically server-side Bayeux clients MAY be privileged clients with access to private information about other clients (see the section called “clientId) and subscriptions.

server

An application program that accepts communications from clients. A web server accepts TCP/IP connections in order to service web requests (HTTP requests or WebSocket requests) by sending back web responses. A Bayeux server accepts and responds to the message exchanges initiated by a Bayeux client.

request

For the HTTP protocol, an HTTP request message as defined by section 5 of RFC 2616.

response

For the HTTP protocol, an HTTP response message as defined by section 6 of RFC 2616.

message

A message is a JSON encoded object exchanged between client and server for the purpose of implementing the Bayeux protocol as defined by Section C.4, “Common Message Field Definitions”, Section C.5, “Meta Message Field Definitions” and Section C.6, “Event Message Field Definitions”,

event

Application specific data that is sent over the Bayeux protocol.

envelope

The transport specific message format that wraps a standard Bayeux message.

channel

A named destination and/or source of events. Events are published to channels and subscribers to channels receive published events.

connection

A communication link that is established either permanently or transiently, for the purposes of messages exchange. A client is connected if a link is established with the server, over which asynchronous events can be received.

JSON

JavaScript Object Notation (JSON) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate. It is based on a subset of the JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999. JSON is described at http://www.json.org/.