关于cometd的一些经验总结-js端

一：js端使用方式 

=================================================== 
第一步 ：初始化cometd配置， 
            $.cometd.configure({ 
                url: cometdURL, 
                logLevel: 'debug' 
            }); 
有两种方式： 
=================================================== 
一：经过 URL string 
cometd.configure('http://localhost:8080/cometd'); 
二：经过配置对象的方式： 
cometd.configure({ 
url: 'http://localhost:8080/cometd' 
}); 
经过第二种方式配置cometd时，对象属性以下： 
url：链接URL 
logLevel：日志级别，默认为info，可支持warn、info、debug 
maxConnections：客户端链接到cometd服务端最大链接数量，默认为2，根据浏览器的不一样，能够更改浏览器默认支持最大链接的相应值 
backoffIncrement：与服务器链接失败后，等待重连的增量时间，默认为1000，单位为毫秒。如：第一次重连为1s，则第二次重连为2s之后，第三次3s，以此类推 
maxBackoff：最大重连增量时间，默认为60000ms 
reverseIncomingExtensions： 
maxNetworkDelay：一个request请求链接服务器失败的最大等待时间，默认为10000ms 
requestHeaders：request请求头，默认为｛｝ 
appendMessageTypeToURL：是否支持Bayeux消息类型能够被附加到URL上并发送至服务器，默认为true 
autoBatch:当没有手动指定批次处理一批publish通信消息时，是否支持默认的批处理，默认为false 


=================================================== 
第二步：调用 $.cometd.handshake()方法，与服务器通信握手 
=================================================== 

调用configure后，并无启动Bayeux Communication，须要手动调用comted.handshake()进行通信握手，通信握手作了两件事情： 
1.客户端与服务器协定通信协议类型 
2.通信协议类型达成一致后，服务端通知客户端详细的请求时间 

该方法是一个异步方法，在通信握手完成后会当即返回，可是handshake返回后并不表明链接已经创建，通信握手失败缘由可能有以下几个： 
1.输错了访问的URL 
2.客户端与服务器没有交换成功通信协议 
3.服务器拒绝通信握手，例如：证书认证失败等 
4.服务器down掉 
5.网络传输失败 
另外：cometd提供init()方法，集成了configure和handshake方法 

因为handshake是异步的方法，你没法获知链接是否创建成功，即便创建成功，客户端也有可能被中断，例如服务器down机等缘由。cometd提供了监听机制，用来监听链接等特殊通道的状态 

=================================================== 
第三步：订阅消息通道Channels，创建监听 
subscribe 订阅普统统道消息、service通道消息 
addListener 监听meta channels消息 
=================================================== 
Bayeux 对Channels定义为：Channels相似于一个消息主题，有兴趣的人能够订阅该消息通道，并接收消息通道发布过来的消息。 
Channels有三种： 
1.meta channels(元数据channel，全部此种channel都以/meta开头) 
2.service channels(服务channel，全部此种channel都以/service开头) 
3.normal channels(普通channel) 
每一个channel相似于一个目录的路径，例如/meta/connect 
&& meta channels 

meta channels是由Bayeux 协议自身创建的，开发时不能subscribe一个meta channel，不然服务器回响应错误的信息，可是你能够在meta channel上创建一个监听 
向一个meta channels发送消息是毫无心义的，只有Bayeux协议建立并在meta channel上面传输信息 
meta channels一般用在客户端监听错误信息上，例如：通信握手错误，网络链接错误等。 


&& service channels 
service channels 一般用在服务端与客户端request/response通信模式下，它与消息通知/订阅通信模式与普通channel大相径庭。 
当订阅服务通道而且没有获得错误的响应时，此时服务端未处理任何操做，而且忽略了订阅请求。 
你可使用一个服务器与客户端之间特定的语义，将消息发布到service channels。 
service channels一般用来实现私聊。 

&& normal channels 
普通channels一般创建一个消息主题，并使用在publish/subscribe通信模式下。你能够在普通channel上进行订阅及消息发布。 
普通channel一般用来向全部订阅的客户端发送主题消息，例如当股票价格发生波动的时候。 

addListener()方法： 
1.必须用在监听meta channels消息 
2.可能会用在监听service channels消息，(也可使用subscribe（）方法，可是不被推荐使用) 
3.不能用来监听normal channels消息，(通常使用subscribe（）方法来替代) 
4.不能涉及任何与服务器的通信，这样能够在调用handshake（）以前调用。 
5.是一个同步方法， 当它返回值时，必须保证listener已经添加。 

subscribe()方法： 
1.不能用在监听meta channels消息，不然服务器回返回错误。 
2.可能会用在监听service channels消息，(也可使用addListener（）方法，推荐使用) 
3.用来监听normal channels消息 
4.包含于服务器的通信，在handshake被调用以前不能调用它 
5.是一个异步的方法，在服务器收到并处理订阅请求以前当即返回。 

注意：调用subscribe方法并不意味着当该方法返回值的时候你已经完成了服务器的订阅。 
addListener和subscribe方法分别返回两个订阅对象能够传递给removeListener()和unsubscribe()方法。 

// Some initialization code 
var subscription1 = cometd.addListener('/meta/connect', function() { ... }); 
var subscription2 = cometd.subscribe('/foo/bar/', function() { ... }); 

// Some de-initialization code 
cometd.unsubscribe(subscription2); 
cometd.removeListener(subscription1); 

///////////////////////////////////// 
var _subscription; 

// The idempotent method 
function _refresh() 
{ 
    _appUnsubscribe(); 
    _appSubscribe(); 
} 

function _appUnsubscribe() 
{ 
    if (_subscription) 
        cometd.unsubscribe(_subscription); 
    _subscription = null; 
} 

function _appSubscribe() 
{ 
    _subscription = cometd.subscribe('/foo/bar', function() { ... }); 
} 
//////////////////////////////////////// 
值得注意的是，你要当心处理你的应用。为了不泄露函数调用或者避免函数屡次调用（一旦你屡次错误的绑定了相同的回调函数） 
当服务器端未返回信息时（网络中断或者服务器crash时），subscribe和unsubscribe方法会有什么样的行为？ 
subscribe：本地监听者首先加入到channel中的订阅者列表中，而后与服务器通信。若是通信失败，服务器并不知道须要向客户端发送数据所以客户端本地的监听者并不会被反调。 
unsubscribe：本地监听者首先从channel中断订阅者列表中移除。而后尝试与服务器通信。若是通信失败，服务器仍然发送信息到客户端，可是本地并无响应监听可指达。 

关于监听者异常处理问题： 
若是监听者/订阅者函数抛出异常，错误信息会以debug级别打印日志。然而，你能够定义一个全局异常监听处理函数来截获异常信息。 
当监听者或者订阅者每次抛出异常时该全局方法都会被反调。 
cometd.onListenerException = function(exception, subscriptionHandle, isListener, message) 
{ 
    // Uh-oh, something went wrong, disable this listener/subscriber 
    // Object "this" points to the CometD object 
    if (isListener) 
        this.removeListener(subscriptionHandle); 
    else 
        this.unsubscribe(subscriptionHandle); 
} 
全局异常监听机制可能会向服务端发送消息。若是异常监听处理函数抛出了异常，异常会以info级别的日志形式 
打印出来，Cometd框架不会break掉。 

//////////////////////////////////// 
使用通配符能够同时订阅多个渠道，例如： 
cometd.subscribe("/chatrooms/*", function(message) { ... }); 
单个星号统配单一渠道段，如：/chatrooms/12 /chatrooms/15 不支持/chatrooms/12/upload 
为了统配多渠道段，可使用双星号，如： 
cometd.subscribe("/events/**", function(message) { ... }); 
使用多渠道可支持相似/events/12/upload events/12 events/12/upload/abc等通道 
通配符原理一样应用在监听者中，例如： 
cometd.addListener("/meta/*", function(message) { ... }); 
默认的，订阅总体通配符/*和/**会发生错误，通配符只能放在分段的最后面。 

目前为止最有趣的meta channels 是 /meta/connect，由于服务器能够返回当前链接的状态。 
值得一提的是,meta/connect也被用于长轮询服务器。所以，若是在一个有效的轮询中发布一个断开消息， 
服务器会返回该poll并触发/meta/connect linstener。 


============================================================= 
第四步 调用publish方法向通道中发布消息 
============================================================= 
publish方法容许你向某一特定的channel中发布消息 
cometd.publish('/mychannel', { mydata: { foo: 'bar' } }); 
不能发布消息到meta channel，可是能够发布消息到一个未订阅的channel，前提是你已经handshake了 
publish是一个异步的通信方法，在服务器收到消息以前它会当即返回。 

============================================================= 
关于disconnecting 
============================================================= 
cometd js api提供了自动重连功能当网络或服务器链接失败时。重连参数在configuration中配置 

1.短暂网络链接失败 
一旦发生网络暂时链接失败，客户端会经过/meta/connect通道发布消息，并将successful标志位置为false。 
此时服务器会保持客户端的状态，一旦网络回复链接，服务器会恢复链接就像未发生中断同样。 
客户端在这种状况下，仅仅须要从新创建长轮询，可是在网络中断期间发布给服务器的消息不会被重发。 
2.长时间网络异常或服务器异常 
若是网络链接长时间异常，服务器将会超时并失去客户端链接，并删除与之相关的状态。 
在这种状况下，客户端的重连机制将会执行如下步骤： 
。。长轮询试图从新创建，可是服务器拒绝访问并返回402：：Unknown client错误信息 
。。通信握手试图从新创建，服务器一般会接收，并从新创建一个链接 
。。在通信握手创建成功的基础上，长链接从新创建。 


若是注册了meta channels，了解这些步骤，由于从新链接可能会涉及多个服务器的消息交换。 


调用disconnect函数致使消息被发送给Bayeux服务端，以便服务端清理关于该客户端的状态维护。 
正如全部涉及到与服务器通信的方法同样，它是一个异步的方法。若是服务器并未返回，js端将会中止全部的试图的链接，而且清理本地状态。 
无论disconnect方法返回成功或者失败，该方法都是安全的。客户端不管如何都会disconnect，它的本地状态会被清理掉。 
若是服务器没有返回值，最终该客户端将会被超时处理，而且清理服务端的状态。 


============================================================= 
关于message bantching 
============================================================= 
咱们常常须要向服务器不一样的渠道同时发送数据。因为publish方法是异步的，同时向服务器端发布屡次时，并不能一块儿发布并依次返回。 
咱们曾天真的这样处理： 
cometd.handshake(); 

// Warning: non-optimal code 
cometd.publish('/channel1', { product: 'foo' }); 
cometd.publish('/channel2', { notificationType: 'all' }); 
cometd.publish('/channel3', { update: false }); 
你可能认为，三个publish方法会相继的从客户端发出，可是实际并不是如此。publish方法是异步的，它会当即返回值。所以3个publish方法可能在未返回任何数据以前到达网络。 
以上发生的是，第一个publish方法会当即执行，另外两个放入队列中，等待第一个publish执行完成。 
当服务端接收到publish发送过来的消息时，第一个publish执行完成，服务器返回meta信息给客户端。客户端接收该信息并完成publish方法。 
当第一个publish完成后，第二个被执行并等待完成，以后第三个被执行。 

若是configuration参数autoBatch设置为true，应用程序会自动执行批次里面已排队的消息。 
所以，在上面的例子中，若是autoBatch设置了true，第一个publish方法会当即被执行，当它执行完成后， 
应用程序会将第二个和第三个publish打包成一个请求发送到服务器。 
这种排队机制是为了不在长轮询后面发起publish队列，若是没有这个机制，浏览器会受到3个发布请求，可是只能有2个连接，
一个是已经被占用的长轮询请求。所以浏览器可能会决定循环发送request，因此第一个publish发生在第二个链接中（第一个已经 
忙于长轮询请求），调度第二个publish使用第一个链接，第三个publish使用第二个链接，当第一个publish返回后。 
结果是，若是你有一个超时时间为5分钟的长链接，第二个publish请求可能比第一个和第三个publish晚5分钟到达服务器。 
你可使用batching优化这三个publish请求，经过将消息绑定成组造成一个单一的Bayeux消息。 

cometd.handshake(); 

cometd.batch(function() 
{ 
    cometd.publish('/channel1', { product: 'foo' }); 
    cometd.publish('/channel2', { notificationType: 'all' }); 
    cometd.publish('/channel3', { update: false }); 
}); 

// Alternatively, but not recommended 
cometd.startBatch() 
cometd.publish('/channel1', { product: 'foo' }); 
cometd.publish('/channel2', { notificationType: 'all' }); 
cometd.publish('/channel3', { update: false }); 
cometd.endBatch() 

当一个batch启动后，随后的API调用将再也不发送到服务器，而是会排队等候，直到batch结束。 
batch将全部的排队等候的message包装成单一的一个Bayeux消息并发送至Bayeux服务器。 
消息绑定有效的利用了网络，将三个request/response生命周期缩短成一个。 

============================================================= 
关于transports 
============================================================= 
Bayeux规范定义了两个强制性的传输协议： 
long-polling和callbak-polling 
cometd实现了这两个协议，并支持websocket协议。 
最新的浏览器（如火狐3.5+），也有可能使用长轮询通讯及跨站点通信。 

1.long-polling transport 
long-polling transport是浏览器和服务器之间默认的通信协议，若是不支持websocket的话。 
该协议应用在跨域名及相同域名的客户端、服务器通信。数据类型被组织成text/json格式并经过一个普通的XMLHttpRequest推送至服务器。 
2.callback-polling transport 
callback-polling transport应用在跨域名通信。众所周知，XMLHttpRequest访问不一样域中的脚本是有限制的。