运行一个CometD Demo非常简单，只要创建一个Maven项目即可（CometD Howtos）：
$ mvn archetype:generate -DarchetypeCatalog=http://cometd.org
maven会提示用户选择archetype，包括cometd的版本1、版本2，jetty6、jetty7的实现，以及客户端dojo或jquery的实现。这里可以选择最新的：
http://cometd.org -> cometd-archetype-dojo-jetty7 (2.0.0 – CometD archetype for creating a server-side event-driven web application)
项目创建完成后执行mvn jetty:run即可，打开http://127.0.0.1:8080/{artifactId}即可。
CometD的协议包容了各种主要的浏览器，比如在Chromium 5上，dojo采用WebSocket实现；而在不支持WebSocket的Firefox 3上，通过long-polling实现。Bayuex是一个应用协议，CometD是Bayuex的实现，类似鸡与蛋的关系。
有了昨天在Chromium上看WebSocket协议的经验，先看一下CometD的WebSocket实现：
握手。客户端请求/{artifactId}/cometd/handshake
包含Header
GET /cometd-jetty/cometd/handshake HTTP/1.1
Upgrade: WebSocket
Connection: Upgrade
Host: 127.0.0.1:8080
Origin: http://127.0.0.1:8080
Cookie: JSESSIONID=12jqq6hbsfkfic8vzqpevxtrw
这是标准的WebSocket握手协议，服务端返回：
HTTP/1.1 101 Web Socket Protocol Handshake
Upgrade: WebSocket
Connection: Upgrade
WebSocket-Origin: http://127.0.0.1:8080
WebSocket-Location: ws://127.0.0.1:8080/cometd-jetty/cometd/handshake
双方完成WebSocket连接的建立。客户端通过websocket发送JSON，进行bayuex的握手：
[{"version":"1.0","minimumVersion":"0.9","channel":"/meta/handshake","supportedConnectionTypes":["websocket","long-polling","callback-polling"],”advice”:{“timeout”:60000,”interval”:0},”id”:”1″}]
服务端返回JSON，下发clientId完成握手：
[{"channel":"/meta/handshake","clientId":"8g6dbnlqr2k6jfo1tdpaeb7iw","version":"1.0","successful":true,"minimumVersion":"1.0","id":"1","supportedConnectionTypes":["websocket","long-polling","callback-polling"]}]
握手完成，bayuex连接建立。
在Demo中，客户端添加了一个handshake的listerner
function _metaHandshake(handshake)
{
if (handshake.successful === true)
{
cometd.batch(function()
{
cometd.subscribe('/hello', function(message)
{
dojo.byId('body').innerHTML += '<div>Server Says: ' + message.data.greeting + '</div>';
});
// Publish on a service channel since the message is for the server only
cometd.publish('/service/hello', { name: 'World' });
});
}
}
所以在完成握手后，客户端发送一个批量请求，subscribe /hello频道，并且向/service/hello发送json格式的消息。向/service channel发送的信息表示客户端与服务端的单独通信，不会被转发给其他客户端。
id用于区分每个请求，bayuex spec规定向/meta和/service发送的请求必须包含id字段，用于标示请求响应。
请求的内容最终聚合为一个Json
[{"channel":"/meta/subscribe","subscription":"/hello","id":"2","clientId":"8g6dbnlqr2k6jfo1tdpaeb7iw"},{"channel":"/service/hello","data":{"name":"World"},"id":"3","clientId":"8g6dbnlqr2k6jfo1tdpaeb7iw"}]
服务端发回响应，id=2的请求成功，订阅/hello频道成功
[{"channel":"/meta/subscribe","successful":true,"id":"2","subscription":"/hello"}]
之后，服务端发回/hello channel的消息
[{"channel":"/hello","data":{"greeting":"Hello, World"}},{"channel":"/service/hello","successful":true,"id":"3"}]
客户端还要定期发送连接请求保持连接
[{"channel":"/meta/connect","connectionType":"websocket","advice":{"timeout":0},"id":"4","clientId":"8g6dbnlqr2k6jfo1tdpaeb7iw"}]
服务端返回，连接成功
[{"channel":"/meta/connect","advice":{"reconnect":"retry","interval":2500,"timeout":15000},"successful":true,"id":"4"}]
connect请求是用于在客户端和服务端维持连接， Bayeux标准中提到(1, 2)：
A transport MUST maintain one and only one outstanding connect message. When a HTTP response that contains a /meta/connect response terminates, the client MUST wait at least the interval specified in the last received advice before following the advice to reestablish the connection
The client MUST maintain only a single outstanding connect message. If the server does not have a current outstanding connect and a connect is not received within a configured timeout, then the server SHOULD act as if a disconnect message has been received.
至此，cometd客户端就可以在/hello频道上订阅、发布消息了。
在Chromium上，所有的操作都在一个WebSocket连接上完成。
而当断开连接时，客户端向服务端发送
[{"channel":"/meta/disconnect","id":"188","clientId":"a8iutjvfp7dtwhzrfujeonk5q"}]
服务端响应
[{"channel":"/meta/disconnect","successful":true,"id":"188"}]
Bayuex基本上就可以理解为一个websocket上的应用协议了。
再看看Firefox 3.6上的实现。Firefox 3.6不支持WebSocket，所有的通信只能通过XHR来实现。
握手，通过一个xhr post请求实现：
POST /{artifactId}/cometd/handshake HTTP/1.1
Host: 127.0.0.1:8080
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.6) Gecko/20100628 Ubuntu/10.04 (lucid) Firefox/3.6.6
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: UTF-8,*
Keep-Alive: 115
Connection: keep-alive
Content-Type: application/json;charset=UTF-8
X-Requested-With: XMLHttpRequest
Referer: http://127.0.0.1:8080/{artifactId}/
Content-Length: 182
Cookie: JSESSIONID=fjnyxb28raih1cnaljrijl1ic
Pragma: no-cache
Cache-Control: no-cache
服务器端响应：
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Set-Cookie: BAYEUX_BROWSER=df92-h8q89f416mutgbpxrwb8185u;Path=/
Content-Length: 213
Server: Jetty(7.1.5.v20100705)
[{"channel":"/meta/handshake","clientId":"9185k23lo482oq1po3ivxup2cj","version":"1.0","successful":true,"minimumVersion":"1.0","id":"1","supportedConnectionTypes":["websocket","long-polling","callback-polling"]}]
握手完成，执行客户端定义的回调。发送bayeux请求，通过一个新的XHR上
[{"channel":"/meta/subscribe","subscription":"/hello","id":"2","clientId":"9185k23lo482oq1po3ivxup2cj"},{"channel":"/service/hello","data":{"name":"World"},"id":"3","clientId":"9185k23lo482oq1po3ivxup2cj"}]
服务端同时返回三个bayuex的请求响应
[{"channel":"/meta/subscribe","successful":true,"id":"2","subscription":"/hello"},{"channel":"/hello","data":{"greeting":"Hello, World"}},{"channel":"/service/hello","successful":true,"id":"3"}]
客户端开始发送连接请求
[{"channel":"/meta/connect","connectionType":"long-polling","advice":{"timeout":0},"id":"4","clientId":"9185k23lo482oq1po3ivxup2cj"}]
注意这里使用的是long-polling方式，这是由dojo针对浏览器特性决定的。
Long-polling server implementations attempt to hold open each request until there are events to deliver; the goal is to always have a pending request available to use for delivering events as they occur, thereby minimizing the latency in message delivery.
如果没有新消息，服务端阻塞十秒后返回
[{"channel":"/meta/connect","successful":true,"id":"7"}]
客户端接收到返回立刻发起新的connect请求
当有新消息时，阻塞在服务器端的connect请求会立即返回，同时带回新的消息，如
[{"channel":"/hello","data":{"name":"555"},"id":"6"},{"channel":"/meta/connect","successful":true,"id":"619"}]
而如果是本客户端publish的新消息，会在请求成功的响应中返回，不会影响connect连接，如：
[{"channel":"/hello","data":{"name":"nihao"},"id":"715"},{"channel":"/hello","successful":true,"id":"715"}]
断开时，仍然是通过xhr post一条bayuex命令到服务端
[{"channel":"/meta/disconnect","id":"750","clientId":"9185k23lo482oq1po3ivxup2cj"}]
服务端响应：
[{"channel":"/meta/disconnect","successful":true,"id":"750"}]
至此，通过long polling方式实现bayuex的cometd客户端也描述清楚了。long-polling仍然是通过connect请求来实现pull的方式准实时，与websocket真正push的方式还是存在区别的。
The post is brought to you by lekhonee v0.7
