基于 asp.net的 Comet 技術(shù)解析

Comet技術(shù)原理

來自維基百科：Comet是一種用于web的技術(shù)，能使服務(wù)器能實(shí)時(shí)地將更新的信息傳送到客戶端，而無須客戶端發(fā)出請(qǐng)求，目前有兩種實(shí)現(xiàn)方式，長輪詢和iframe流。

簡(jiǎn)單的說是一種基于現(xiàn)有Http協(xié)議基礎(chǔ)上的長輪詢技術(shù)，之所有會(huì)產(chǎn)生這種技術(shù)的主要原因是Http協(xié)議是無狀態(tài)的所以客戶端和服務(wù)端之間沒辦法建立起一套長時(shí)間的連接。比如我們要做一個(gè)聊天室，在Web環(huán)境下我們通常不能從服務(wù)端推送消息到瀏覽器里，而只能通過每個(gè)客戶端不斷的輪詢服務(wù)器，以獲取最新的消息，這樣一來效率非常低，而且不斷的向服務(wù)器發(fā)送請(qǐng)求對(duì)于訪問量大的應(yīng)用來說也會(huì)造成很大的資源占用。

于是人們就發(fā)現(xiàn)了這種技術(shù)，向服務(wù)器發(fā)起一個(gè)請(qǐng)求，然后服務(wù)器一直不響應(yīng)這個(gè)請(qǐng)求，這樣客戶端和服務(wù)端之間就形成了一個(gè)長連接，直到服務(wù)端響應(yīng)這個(gè)請(qǐng)求后結(jié)束本次連接。借用一下IBM里的圖片：

通過Ajax技術(shù)可以實(shí)現(xiàn)長輪詢的服務(wù)器推模型，客戶端和服務(wù)端之間通過不斷的發(fā)起長輪詢即可以實(shí)現(xiàn)數(shù)據(jù)的交互，這個(gè)過程由于是Ajax實(shí)現(xiàn)的異步操作所以體驗(yàn)上會(huì)比較好，效率也很高。哎呀呀，說不清楚，找個(gè)網(wǎng)上的資料：

Comet方式通俗的說就是一種長連接機(jī)制(longlivedhttp)。同樣是由Browser端主動(dòng)發(fā)起請(qǐng)求，但是Server端以一種似乎非常慢的響應(yīng)方式給出回答。這樣在這個(gè)期間內(nèi)，服務(wù)器端可以使用同一個(gè)connection把要更新的數(shù)據(jù)主動(dòng)發(fā)送給Browser。因此請(qǐng)求可能等待較長的時(shí)間，期間沒有任何數(shù)據(jù)返回，但是一旦有了新的數(shù)據(jù)，它將立即被發(fā)送到客戶機(jī)。Comet又有很多種實(shí)現(xiàn)方式，但是總的來說對(duì)Server端的負(fù)載都會(huì)有增加.雖然對(duì)于單位操作來說，每次只需要建議一次connection,但是由于connection是保持較長時(shí)間的,對(duì)于server端的資源的占用要有所增加。

優(yōu)點(diǎn)：實(shí)時(shí)性好（消息延時(shí)小）；性能好（能支持大量用戶）

缺點(diǎn)：長期占用連接，喪失了無狀態(tài)高并發(fā)的特點(diǎn)。

應(yīng)用：股票系統(tǒng)、實(shí)時(shí)通訊。

參考資料:

Comet：基于HTTP長連接的“服務(wù)器推”技術(shù)

基于Asp.Net的實(shí)現(xiàn)Comet的技術(shù)基礎(chǔ)

Asp.Net本身就是為web而生的技術(shù)，所以先天是滿足滴。基于Ajax技術(shù)與Asp.net的異步請(qǐng)求處理可以為Comet提供更加強(qiáng)大的能力。在此隆重推出：IHttpAsyncHandler接口。

• IHttpAsyncHandler接口簡(jiǎn)介

IhttpAsyncHandler是繼承于IhttpHandler，但是不同的是IHttpAsyncHandler具有天生的異步能力。他比IHttpHandler多2個(gè)方法：

IAsyncResultBeginPRocessRequest(HttpContextcontext,AsyncCallbackcb,objectextraData);voidEndProcessRequest(IAsyncResultresult);

BeginProcessRequest方法返回的是IAsyncResult接口，通常在BeginProcessRequest中處理一些比較繁重費(fèi)時(shí)的任務(wù)，比如IO操作，讀取Web服務(wù)等。一旦異步操作完成之后，則可以通過EndProcessRequest方法獲得異步的結(jié)果。

IHttpAsyncHandler的好處在于，在它處理異步方法的時(shí)候，處理請(qǐng)求的線程可以暫時(shí)得到釋放，而有空閑去處理其他請(qǐng)求，等異步方法運(yùn)行完畢之后，在由線程去處理接下來的請(qǐng)求。

• Asp.Net實(shí)現(xiàn)Comet

有了技術(shù)基礎(chǔ)那么來看看如何實(shí)現(xiàn)這項(xiàng)技術(shù)：

在客戶端我們需要實(shí)現(xiàn)發(fā)送請(qǐng)求，這方面可以通過Ajax技術(shù)來實(shí)現(xiàn)，可以通過javascript比較簡(jiǎn)單方便的實(shí)現(xiàn)異步請(qǐng)求操作。

在服務(wù)端監(jiān)聽專門的請(qǐng)求類型，通過實(shí)現(xiàn)IhttpAsyncHandler處理請(qǐng)求，BeginProcessRequest方法中有個(gè)AsyncCallback類型的參數(shù)cb，這是個(gè)回調(diào)函數(shù)，在asp.net中如果不調(diào)用這個(gè)回調(diào)函數(shù)cb則不會(huì)響應(yīng)請(qǐng)求，即不會(huì)向客戶端返回內(nèi)容，這就實(shí)現(xiàn)長連接。直到服務(wù)端有數(shù)據(jù)需要返回給客戶端，服務(wù)端再調(diào)用cb函數(shù)以觸發(fā)執(zhí)行EndProcessRequest方法，此時(shí)客戶端才會(huì)接收到響應(yīng)包。

在客戶端接收完數(shù)據(jù)后可以繼續(xù)向服務(wù)端發(fā)起請(qǐng)求，重復(fù)這個(gè)過程就可以模擬出一個(gè)長連接的狀態(tài)。

AspComet組件介紹

在asp.net里有個(gè)開源的組件AspComet比較好的實(shí)現(xiàn)了Comet，此組件的開源站點(diǎn)：https://github.com/nmosafi/aspcomet。

在AspComet中的核心主要是通過Ajax發(fā)起請(qǐng)求，在服務(wù)端基于IhttpAsyncHandler來處理請(qǐng)求，通過一個(gè)消息總線處理了一整套的Web推技術(shù)。組件分為服務(wù)端和客戶端兩部分，都具備良好的擴(kuò)展性，服務(wù)端有比較靈活的委托處理，也可以通過自己繼承實(shí)現(xiàn)改寫自己需要的業(yè)務(wù)處理，非常方便的二次開發(fā)。而客戶端也提供了良好的封裝性，支持多種主流js腳本庫，如Jquery，dojo等，在官方的demo中就提供了這兩種腳本庫的實(shí)現(xiàn)。

在閱讀了Aspcomet的源代碼后還是比較感嘆的，雖然看起來很費(fèi)勁，但也著實(shí)感覺到了這套代碼對(duì)二次開發(fā)提供了很好的支持。基本都是面向?qū)ο髞韺?shí)現(xiàn)了整個(gè)組件，即使是JS也應(yīng)用了很多的設(shè)計(jì)模式。下面就這個(gè)組件的主要實(shí)現(xiàn)做一些介紹：

服務(wù)端

1、首先必須實(shí)現(xiàn)IhttpAsyncHandler接口

CometHttpHandler：IhttpAsyncHandler，此類就是用于異步請(qǐng)求的處理單元，簡(jiǎn)單的說就是服務(wù)端的入口。在這里通過BeginProcessRequest方法將請(qǐng)求的內(nèi)容hold住，同時(shí)也將callback也Hold住。當(dāng)然這里有個(gè)重點(diǎn)要注意就是MessageBus，所有消息如何hold住就得看它的了，因?yàn)橛行┫⑹且纯谭祷亟o客戶端的，而有些是要經(jīng)過消息總線處理后再轉(zhuǎn)發(fā)的，也有的是要留下來作為長連接的。具體的會(huì)在講消息總線時(shí)再說明。

最終CometHttpHandler會(huì)在請(qǐng)求需要結(jié)束時(shí)調(diào)用EndProcessRequest方法，從而將消息返回給一直等待的連接，客戶端會(huì)接收并處理此請(qǐng)求的響應(yīng)包。

CometHttpHandler就是實(shí)現(xiàn)了一個(gè)入口和出口，通過IhttpAsyncHandler的異步處理能力從而實(shí)現(xiàn)了長連接狀態(tài)。

2、消息封包

對(duì)于客戶端和服務(wù)端之間交互必須有一個(gè)消息封包，否則雙方無法做一些約定，畢竟Http協(xié)議是松散的無狀態(tài)性。在AspComet中實(shí)現(xiàn)了一個(gè)類：Message

這個(gè)類AspComet的開發(fā)者叫其：bauyeuxmessage（介紹），貌似是Dojo提出的一套協(xié)議。

在這個(gè)消息封包中主要介紹幾個(gè)：

封包的內(nèi)容很豐富，有時(shí)候協(xié)議就是種約定，其實(shí)對(duì)于我們來說就是一個(gè)類嘛，甚至于你可以理解就是一個(gè)字符串，客戶端和服務(wù)端通過某種約定可以相互解析識(shí)別就可。

3、消息總線設(shè)計(jì)

在說到IhttpAnyscHandler時(shí)就提到了消息總線，在AspComet中抽象為一個(gè)接口：IMessageBus。

public interface IMessageBus{void HandleMessages(Message[] messages, ICometAsyncResult cometAsyncResult);}

就一個(gè)方法，這也就是AspComet用于處理消息的核心方法了，方法的意思就是處理消息，在這個(gè)方法里主要是將接收的消息分配給不同的消息處理者進(jìn)行處理，比如：發(fā)起握手協(xié)議時(shí)要將消息給MetaHandshakeHandler來處理，這就是一個(gè)消息中轉(zhuǎn)中心。

參數(shù)messages是消息封包，因?yàn)榭赡苁嵌鄠€(gè)消息所以用了數(shù)組。

參數(shù)cometAsyncResult是對(duì)異步請(qǐng)求回調(diào)函數(shù)的一個(gè)二次封裝，主要目的是將callback給接住，不讓其響應(yīng)，這樣就可以控制什么時(shí)候返回響應(yīng)包了。ICometAsyncResult接口就兩個(gè)方法

SendAwaitingMessages是用于將發(fā)送等待的消息，主要是用于將要發(fā)送的消息寫入到發(fā)送管道中

CompleteRequestWithMessages是用于完成請(qǐng)求的過程，主要是調(diào)一下callback以告訴IhttpAsyncHandler請(qǐng)求可以返回啦

通過這兩個(gè)方法的配合就可以實(shí)現(xiàn)將消息向客戶端發(fā)送消息啦。

這里提一點(diǎn)：其實(shí)向客戶端發(fā)送數(shù)據(jù)的方法很簡(jiǎn)單，Http分請(qǐng)求包和響應(yīng)包，客戶端發(fā)給服務(wù)端的叫請(qǐng)求（Request），服務(wù)端發(fā)給客戶端的叫響應(yīng)（Response），這下應(yīng)該明白了吧。SendAwaitingMessages就是把數(shù)據(jù)寫入到Response里，這樣客戶端不就有接收的數(shù)據(jù)了嗎？

4、各類型消息的處理

在消息總線里提到了消息處理者，為什么會(huì)有這個(gè)東東存在呢？其實(shí)這跟整個(gè)的通信過程有關(guān)，有握手過程、連接建立過程、斷開過程等等，這就要有一整套處理的方法，也就是要對(duì)每種不同的過程做一個(gè)類型分開處理。在AspComet中有一個(gè)接口：ImessageHandler，它定義了一個(gè)消息處理的統(tǒng)一方法：

通過繼承這個(gè)接口實(shí)現(xiàn)特定的消息處理類就可以完成一些特定的業(yè)務(wù)了，下面列舉一下各種消息處理類：

從字面意思應(yīng)該就可以理解大體了，發(fā)什么消息做什么處理，就這個(gè)意思。

說到消息的分類處理有個(gè)東西必須說明，在MessageBus中如何區(qū)分消息類型并找到對(duì)應(yīng)的處理者呢？這就是和ImessagesProcessor的功勞了。

在這個(gè)接口中Process方法就是用于處理每條消息的轉(zhuǎn)發(fā)，這個(gè)設(shè)計(jì)也很好，我們甚至可以實(shí)現(xiàn)一個(gè)自己的MessagesProcessor完全按自己的要求進(jìn)行消息轉(zhuǎn)發(fā)和處理。在此我還是看一下官方的默認(rèn)實(shí)現(xiàn)吧，在AspComet組件中有個(gè)默認(rèn)的實(shí)現(xiàn)MessagesProcessor，代碼如下：

在代碼中可以看到，MessageProcessor是通過一個(gè)HandlerFactory來獲取實(shí)際的ImessageHandler實(shí)例，進(jìn)而處理消息的，這個(gè)過程也不復(fù)雜，官方提供的實(shí)現(xiàn)就是MessageHandlerFactory類：

在這里處理的方法是根據(jù)channel的不同調(diào)用相應(yīng)的handler。

回到ImessageHandler，就得說明一下AspComet對(duì)單獨(dú)消息處理時(shí)釋放出來的委托設(shè)計(jì)，在Handler執(zhí)行Handlemessage方法時(shí)會(huì)調(diào)用相應(yīng)的委托，外部程序可以訂閱委托實(shí)現(xiàn)進(jìn)行一些處理。比如我在握手過程中驗(yàn)證客戶端合法性，但這個(gè)客戶端的合法性需要外部應(yīng)用程序才能檢驗(yàn)，怎么辦呢？就可以通過MetaHandshakeHandler中HandleMessage方法釋放出來的兩個(gè)委托進(jìn)行處理，代碼如下：

在這段代碼里有兩個(gè)EventHub.Publish(…)的調(diào)用，這就是兩個(gè)委托調(diào)用，我們要實(shí)現(xiàn)客戶端合法性驗(yàn)證就要在第一個(gè)委托時(shí)做處理，比如上面代碼中有兩行這樣的代碼：

這就是調(diào)用一個(gè)委托，參數(shù)是handshakingEvent。外部訂閱此委托的程序會(huì)處理相應(yīng)的邏輯，如果不符合要求則將其Cancel屬性設(shè)置為true，就說明本次消息發(fā)送過程要取消掉，并且可以寫入相應(yīng)的原因。下面是一個(gè)實(shí)現(xiàn)的例子：

CheckHandshake方法就是訂閱了委托的方法，其中的參數(shù)就是從EventHub.Publish(handshakingEvent);中傳過來的。在CheckHandshake里可以取得相應(yīng)的Client對(duì)象并做一些檢查等，如果不符合要求可以將ev.Cancel設(shè)置為true，并將原因?qū)懭隒ancellationReason屬性發(fā)回給客戶端。

5、客戶端對(duì)象管理

在服務(wù)端要管理客戶端的信息，這樣才能在消息廣播時(shí)向特定的客戶端發(fā)送，為了保持客戶端的應(yīng)用無關(guān)性，AspComet定義了Iclient接口：

Iclient說明

這里定義了對(duì)Client的一些基礎(chǔ)定義，繼承此接口實(shí)現(xiàn)一個(gè)客戶端類就行了。

這里所說有客戶端并非指的實(shí)際的瀏覽器端