寫了這么多篇介紹ESFramework的文章才想起來還有一些很基礎(chǔ)的內(nèi)容沒有介紹,前面介紹的一些組件、框架基本上是與協(xié)議無關(guān)的(比如無論是Tcp還是Udp甚至是Remoting、WebService都可以通用),然而到了應(yīng)用的最底層,我們總需要選擇一種通信協(xié)議,.net Framework對(duì)Remoting和WebService已經(jīng)封裝的足夠好了,而對(duì)Tcp和Udp提供的API還是很低級(jí),所以ESFramework對(duì)這兩種協(xié)議進(jìn)行了高層的封裝,而且這些封裝與ESFramework的其它組件協(xié)調(diào)一致,合作起來天衣無縫!
本文就先從封裝的Tcp組件開始介紹(Tcp組件的前身可以參見 .NET平臺(tái)下可復(fù)用的Tcp通信層實(shí)現(xiàn) 和 .NET平臺(tái)下可復(fù)用的Tcp通信層實(shí)現(xiàn)(續(xù)) )。
支持ESFramework的Tcp組件都需要實(shí)現(xiàn)ITcp接口:
上面接口定義中的注釋已經(jīng)解釋了大多數(shù)內(nèi)容,額外地,我需要解釋一下幾件事情:
(1)為什么ITcp沒有從一個(gè)更基礎(chǔ)的接口比如INet繼承,這樣ITcp和IEsbUdp(后面將要介紹的Udp組件的基礎(chǔ)接口)就有了共同的根源?
早在EnterpriseServerBase中確實(shí)是這樣設(shè)計(jì)的,但是在ESFramework中卻將它們嚴(yán)格的隔離開來,原因在于,Tcp與Udp是如此的不同,如果要它們相互遷就共同遵守同一個(gè)“有意義”的基礎(chǔ)接口并不是一件愉快的事情。這里說的“有意義”,指的是,我們可以通過這個(gè)接口來幾乎完整的操縱不同的Tcp組件和Udp組件,而不需要進(jìn)行向下轉(zhuǎn)換。我們?cè)谝粋€(gè)早期的應(yīng)用中,使之即支持Tcp協(xié)議,有支持Udp協(xié)議,只需簡(jiǎn)單修改一下配置文件,就可以簡(jiǎn)單的從一個(gè)協(xié)議切換到另一個(gè)。我們實(shí)現(xiàn)了這個(gè)目標(biāo),但是程序的實(shí)現(xiàn)中摻雜了太多的if...else和向下轉(zhuǎn)換,有人一定會(huì)建議,使用多態(tài)可以避免if...else,讓我告訴你這樣做的難處在哪里。如果使用多態(tài)替換if...else,就需要將更多的東西抽象到形式一致的接口中,但是,Tcp和Udp組件的很多方法的簽名是無法達(dá)成一致的,除非都使用Object類型,可是,如果都使用Object類型的參數(shù),在方法的實(shí)現(xiàn)中,仍然需要向下進(jìn)行轉(zhuǎn)換。可見這樣做并沒有任何好處。首先是使得邏輯更加復(fù)雜含混,而且對(duì)效率也沒有任何幫助。
所以太不相同的事物,就沒有必要給它們安排一個(gè)共同的祖先。也許,我們可以給予一個(gè)沒有多大意義的基礎(chǔ)接口,比如像
(2)通過MaxMessageSize屬性可以設(shè)置應(yīng)用中所允許的單個(gè)消息的最大長(zhǎng)度,如果從某連接上接收到的消息的長(zhǎng)度大于此值,則Tcp組件會(huì)關(guān)閉對(duì)應(yīng)的連接。如果對(duì)消息長(zhǎng)度沒有限制,則可以設(shè)置為int.MaxValue。
(3)Dispatcher屬性是為Tcp組件設(shè)置消息分配器,每當(dāng)Tcp組件接收到一個(gè)完整的消息,就會(huì)把它交給分配器進(jìn)行分派處理。消息分配器是ESFramework的核心組件,前面已經(jīng)做了詳細(xì)介紹。
(4)BufferPool是緩沖區(qū)池,如果tcp發(fā)現(xiàn)即將接收的消息的長(zhǎng)度大于RecieveBuffSize屬性給定的值,則會(huì)從BufferPool申請(qǐng)更大的緩沖區(qū)來接收消息,為了避免大緩沖區(qū)的重復(fù)創(chuàng)建/銷毀的開銷,并增加復(fù)用,所以使用BufferPool來管理較大的緩沖區(qū)。
(5)ServiceCommitted事件,當(dāng)服務(wù)器處理完一個(gè)用戶請(qǐng)求并把回復(fù)發(fā)送出去后,將觸發(fā)該事件。如果ServiceCommitted事件被引發(fā),表示回復(fù)數(shù)據(jù)已經(jīng)被發(fā)送出去了。
(6)我們看到了ITcp從ITcpClientsController繼承,ITcpClientsController接口用于服務(wù)器主動(dòng)控制TCP客戶的連接,比如,在消息分配器組件中可能需要控制ITcp組件來直接向某個(gè)用戶發(fā)送Active數(shù)據(jù),這時(shí)只需要引用ITcpClientsController就可以了。
關(guān)于ITcp的介紹就是這些,然而如何實(shí)現(xiàn)ITcp卻有多種方法,不同的實(shí)現(xiàn)方法所得到的并發(fā)量和效率可能千差萬別。所以ITcp的實(shí)現(xiàn)對(duì)與系統(tǒng)的效率和并發(fā)量有著非常關(guān)鍵的影響。ESFramework中ITcp的參考實(shí)現(xiàn)是AgileTcp(將在后文中講述),如果你有更好的實(shí)現(xiàn),完全可以在采用ESFramework框架的同時(shí)使用自己實(shí)現(xiàn)的Tcp組件,ESFramework為你保留了這種權(quán)利--ESFramework所有的重要組件都是可以替換的,只要遵循相同的接口即可:)
感謝關(guān)注!
轉(zhuǎn)到: ESFramework 可復(fù)用的通信框架(序)
本文就先從封裝的Tcp組件開始介紹(Tcp組件的前身可以參見 .NET平臺(tái)下可復(fù)用的Tcp通信層實(shí)現(xiàn) 和 .NET平臺(tái)下可復(fù)用的Tcp通信層實(shí)現(xiàn)(續(xù)) )。
支持ESFramework的Tcp組件都需要實(shí)現(xiàn)ITcp接口:

1
public
interface
ITcp:ITcpClientsController,IDisposable
2 {
3 void Initialize();
4 void Start();
5 void Stop(); // 釋放所有連接
6
7 int Port{ get ; set ;}
8 int ConnectionCount{ get ;} // 當(dāng)前連接的數(shù)量
9 int RecieveBuffSize{ get ; set ;}
10 int MaxMessageSize{ set ;} // 當(dāng)發(fā)現(xiàn)的消息長(zhǎng)度大于MaxMessageSize,將關(guān)閉對(duì)應(yīng)的連接
11
12 ITcpStreamDispatcherDispatcher{ set ;} // 支持依賴注入
13 IContractHelperContractHelper{ set ;}
14 IBufferPoolBufferPool{ set ;}
15 IEsbLoggerEsbLogger{ set ;} // 記錄運(yùn)行日志
16
17 event CbSimpleIntSomeOneConnected; // 上線,ConnectID
18 event CbSimpleIntConnectionCountChanged; // 在線人數(shù)變化
19
20 event CallBackDisconnectSomeOneDisConnected; // 掉線,ConnectID
21 event CallBackRespondServiceCommitted; // 用戶請(qǐng)求的服務(wù)的回復(fù)信息
22 event CallBackRespondServiceDirectCommitted; // 對(duì)應(yīng)ITcpClientsController.SendData,此時(shí)無法確定ServiceKey
23 }
24
25 public delegate void CallBackRespond( int connectID,NetMessagemsg);
26 public delegate void CallBackDisconnect( int connectID,DisconnectedCausecause);
2 {
3 void Initialize();
4 void Start();
5 void Stop(); // 釋放所有連接
6
7 int Port{ get ; set ;}
8 int ConnectionCount{ get ;} // 當(dāng)前連接的數(shù)量
9 int RecieveBuffSize{ get ; set ;}
10 int MaxMessageSize{ set ;} // 當(dāng)發(fā)現(xiàn)的消息長(zhǎng)度大于MaxMessageSize,將關(guān)閉對(duì)應(yīng)的連接
11
12 ITcpStreamDispatcherDispatcher{ set ;} // 支持依賴注入
13 IContractHelperContractHelper{ set ;}
14 IBufferPoolBufferPool{ set ;}
15 IEsbLoggerEsbLogger{ set ;} // 記錄運(yùn)行日志
16
17 event CbSimpleIntSomeOneConnected; // 上線,ConnectID
18 event CbSimpleIntConnectionCountChanged; // 在線人數(shù)變化
19
20 event CallBackDisconnectSomeOneDisConnected; // 掉線,ConnectID
21 event CallBackRespondServiceCommitted; // 用戶請(qǐng)求的服務(wù)的回復(fù)信息
22 event CallBackRespondServiceDirectCommitted; // 對(duì)應(yīng)ITcpClientsController.SendData,此時(shí)無法確定ServiceKey
23 }
24
25 public delegate void CallBackRespond( int connectID,NetMessagemsg);
26 public delegate void CallBackDisconnect( int connectID,DisconnectedCausecause);
上面接口定義中的注釋已經(jīng)解釋了大多數(shù)內(nèi)容,額外地,我需要解釋一下幾件事情:
(1)為什么ITcp沒有從一個(gè)更基礎(chǔ)的接口比如INet繼承,這樣ITcp和IEsbUdp(后面將要介紹的Udp組件的基礎(chǔ)接口)就有了共同的根源?
早在EnterpriseServerBase中確實(shí)是這樣設(shè)計(jì)的,但是在ESFramework中卻將它們嚴(yán)格的隔離開來,原因在于,Tcp與Udp是如此的不同,如果要它們相互遷就共同遵守同一個(gè)“有意義”的基礎(chǔ)接口并不是一件愉快的事情。這里說的“有意義”,指的是,我們可以通過這個(gè)接口來幾乎完整的操縱不同的Tcp組件和Udp組件,而不需要進(jìn)行向下轉(zhuǎn)換。我們?cè)谝粋€(gè)早期的應(yīng)用中,使之即支持Tcp協(xié)議,有支持Udp協(xié)議,只需簡(jiǎn)單修改一下配置文件,就可以簡(jiǎn)單的從一個(gè)協(xié)議切換到另一個(gè)。我們實(shí)現(xiàn)了這個(gè)目標(biāo),但是程序的實(shí)現(xiàn)中摻雜了太多的if...else和向下轉(zhuǎn)換,有人一定會(huì)建議,使用多態(tài)可以避免if...else,讓我告訴你這樣做的難處在哪里。如果使用多態(tài)替換if...else,就需要將更多的東西抽象到形式一致的接口中,但是,Tcp和Udp組件的很多方法的簽名是無法達(dá)成一致的,除非都使用Object類型,可是,如果都使用Object類型的參數(shù),在方法的實(shí)現(xiàn)中,仍然需要向下進(jìn)行轉(zhuǎn)換。可見這樣做并沒有任何好處。首先是使得邏輯更加復(fù)雜含混,而且對(duì)效率也沒有任何幫助。
所以太不相同的事物,就沒有必要給它們安排一個(gè)共同的祖先。也許,我們可以給予一個(gè)沒有多大意義的基礎(chǔ)接口,比如像
public
interface
INet
{
void Initialize();
void Start();
void Stop();
int Port{ get ; set ;}
}
這沒有多大的用處。如果有一天,ESFramework發(fā)現(xiàn)了可以從ITcp和IEsbUdp中抽象出一個(gè)有意義的基礎(chǔ)接口的時(shí)候,會(huì)重構(gòu)來得到這個(gè)接口,這也是很簡(jiǎn)單的。
{
void Initialize();
void Start();
void Stop();
int Port{ get ; set ;}
}
(2)通過MaxMessageSize屬性可以設(shè)置應(yīng)用中所允許的單個(gè)消息的最大長(zhǎng)度,如果從某連接上接收到的消息的長(zhǎng)度大于此值,則Tcp組件會(huì)關(guān)閉對(duì)應(yīng)的連接。如果對(duì)消息長(zhǎng)度沒有限制,則可以設(shè)置為int.MaxValue。
(3)Dispatcher屬性是為Tcp組件設(shè)置消息分配器,每當(dāng)Tcp組件接收到一個(gè)完整的消息,就會(huì)把它交給分配器進(jìn)行分派處理。消息分配器是ESFramework的核心組件,前面已經(jīng)做了詳細(xì)介紹。
(4)BufferPool是緩沖區(qū)池,如果tcp發(fā)現(xiàn)即將接收的消息的長(zhǎng)度大于RecieveBuffSize屬性給定的值,則會(huì)從BufferPool申請(qǐng)更大的緩沖區(qū)來接收消息,為了避免大緩沖區(qū)的重復(fù)創(chuàng)建/銷毀的開銷,并增加復(fù)用,所以使用BufferPool來管理較大的緩沖區(qū)。

public
interface
IBufferPool
{
byte []RentBuffer( int minSize);
void GivebackBuffer( byte []buffer);
}
{
byte []RentBuffer( int minSize);
void GivebackBuffer( byte []buffer);
}
(5)ServiceCommitted事件,當(dāng)服務(wù)器處理完一個(gè)用戶請(qǐng)求并把回復(fù)發(fā)送出去后,將觸發(fā)該事件。如果ServiceCommitted事件被引發(fā),表示回復(fù)數(shù)據(jù)已經(jīng)被發(fā)送出去了。
(6)我們看到了ITcp從ITcpClientsController繼承,ITcpClientsController接口用于服務(wù)器主動(dòng)控制TCP客戶的連接,比如,在消息分配器組件中可能需要控制ITcp組件來直接向某個(gè)用戶發(fā)送Active數(shù)據(jù),這時(shí)只需要引用ITcpClientsController就可以了。
public
interface
ITcpClientsController
{
// 主動(dòng)給某個(gè)客戶同步發(fā)信息
void SendData( int ConnectID,NetMessagemsg);
// 主動(dòng)關(guān)閉連接
void DisposeOneConnection( int connectID,DisconnectedCausecause);
}
{
// 主動(dòng)給某個(gè)客戶同步發(fā)信息
void SendData( int ConnectID,NetMessagemsg);
// 主動(dòng)關(guān)閉連接
void DisposeOneConnection( int connectID,DisconnectedCausecause);
}
關(guān)于ITcp的介紹就是這些,然而如何實(shí)現(xiàn)ITcp卻有多種方法,不同的實(shí)現(xiàn)方法所得到的并發(fā)量和效率可能千差萬別。所以ITcp的實(shí)現(xiàn)對(duì)與系統(tǒng)的效率和并發(fā)量有著非常關(guān)鍵的影響。ESFramework中ITcp的參考實(shí)現(xiàn)是AgileTcp(將在后文中講述),如果你有更好的實(shí)現(xiàn),完全可以在采用ESFramework框架的同時(shí)使用自己實(shí)現(xiàn)的Tcp組件,ESFramework為你保留了這種權(quán)利--ESFramework所有的重要組件都是可以替換的,只要遵循相同的接口即可:)
感謝關(guān)注!
轉(zhuǎn)到: ESFramework 可復(fù)用的通信框架(序)
更多文章、技術(shù)交流、商務(wù)合作、聯(lián)系博主
微信掃碼或搜索:z360901061

微信掃一掃加我為好友
QQ號(hào)聯(lián)系: 360901061
您的支持是博主寫作最大的動(dòng)力,如果您喜歡我的文章,感覺我的文章對(duì)您有幫助,請(qǐng)用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點(diǎn)擊下面給點(diǎn)支持吧,站長(zhǎng)非常感激您!手機(jī)微信長(zhǎng)按不能支付解決辦法:請(qǐng)將微信支付二維碼保存到相冊(cè),切換到微信,然后點(diǎn)擊微信右上角掃一掃功能,選擇支付二維碼完成支付。
【本文對(duì)您有幫助就好】元
