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

2019独角兽企业重金招聘Python工程师标准>>>

一：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访问不同域中的脚本是有限制的。 

转载于:https://my.oschina.net/bosscheng/blog/186632