寫了這么多篇介紹ESFramework的文章才想起來還有一些很基礎的內容沒有介紹，前面介紹的一些組件、框架基本上是與協議無關的（比如無論是Tcp還是Udp甚至是Remoting、WebService都可以通用），然而到了應用的最底層，我們總需要選擇一種通信協議，.net Framework對Remoting和WebService已經封裝的足夠好了，而對Tcp和Udp提供的API還是很低級，所以ESFramework對這兩種協議進行了高層的封裝，而且這些封裝與ESFramework的其它組件協調一致，合作起來天衣無縫！
本文就先從封裝的Tcp組件開始介紹（Tcp組件的前身可以參見 .NET平臺下可復用的Tcp通信層實現 和 .NET平臺下可復用的Tcp通信層實現（續） ）。
支持ESFramework的Tcp組件都需要實現ITcp接口：
上面接口定義中的注釋已經解釋了大多數內容，額外地，我需要解釋一下幾件事情：
（1）為什么ITcp沒有從一個更基礎的接口比如INet繼承，這樣ITcp和IEsbUdp（后面將要介紹的Udp組件的基礎接口）就有了共同的根源？
早在EnterpriseServerBase中確實是這樣設計的，但是在ESFramework中卻將它們嚴格的隔離開來，原因在于，Tcp與Udp是如此的不同，如果要它們相互遷就共同遵守同一個“有意義”的基礎接口并不是一件愉快的事情。這里說的“有意義”，指的是，我們可以通過這個接口來幾乎完整的操縱不同的Tcp組件和Udp組件，而不需要進行向下轉換。我們曾在一個早期的應用中，使之即支持Tcp協議，有支持Udp協議，只需簡單修改一下配置文件，就可以簡單的從一個協議切換到另一個。我們實現了這個目標，但是程序的實現中摻雜了太多的if...else和向下轉換，有人一定會建議，使用多態可以避免if...else，讓我告訴你這樣做的難處在哪里。如果使用多態替換if...else，就需要將更多的東西抽象到形式一致的接口中，但是，Tcp和Udp組件的很多方法的簽名是無法達成一致的，除非都使用Object類型，可是，如果都使用Object類型的參數，在方法的實現中，仍然需要向下進行轉換。可見這樣做并沒有任何好處。首先是使得邏輯更加復雜含混，而且對效率也沒有任何幫助。
所以太不相同的事物，就沒有必要給它們安排一個共同的祖先。也許，我們可以給予一個沒有多大意義的基礎接口，比如像
（2）通過MaxMessageSize屬性可以設置應用中所允許的單個消息的最大長度，如果從某連接上接收到的消息的長度大于此值，則Tcp組件會關閉對應的連接。如果對消息長度沒有限制，則可以設置為int.MaxValue。
（3）Dispatcher屬性是為Tcp組件設置消息分配器，每當Tcp組件接收到一個完整的消息，就會把它交給分配器進行分派處理。消息分配器是ESFramework的核心組件，前面已經做了詳細介紹。
（4）BufferPool是緩沖區池，如果tcp發現即將接收的消息的長度大于RecieveBuffSize屬性給定的值，則會從BufferPool申請更大的緩沖區來接收消息，為了避免大緩沖區的重復創建/銷毀的開銷，并增加復用，所以使用BufferPool來管理較大的緩沖區。
（5）ServiceCommitted事件，當服務器處理完一個用戶請求并把回復發送出去后，將觸發該事件。如果ServiceCommitted事件被引發，表示回復數據已經被發送出去了。
（6）我們看到了ITcp從ITcpClientsController繼承，ITcpClientsController接口用于服務器主動控制TCP客戶的連接，比如，在消息分配器組件中可能需要控制ITcp組件來直接向某個用戶發送Active數據，這時只需要引用ITcpClientsController就可以了。
關于ITcp的介紹就是這些，然而如何實現ITcp卻有多種方法，不同的實現方法所得到的并發量和效率可能千差萬別。所以ITcp的實現對與系統的效率和并發量有著非常關鍵的影響。ESFramework中ITcp的參考實現是AgileTcp（將在后文中講述），如果你有更好的實現，完全可以在采用ESFramework框架的同時使用自己實現的Tcp組件，ESFramework為你保留了這種權利－－ESFramework所有的重要組件都是可以替換的，只要遵循相同的接口即可：）
感謝關注！
轉到： ESFramework 可復用的通信框架（序）
本文就先從封裝的Tcp組件開始介紹（Tcp組件的前身可以參見 .NET平臺下可復用的Tcp通信層實現 和 .NET平臺下可復用的Tcp通信層實現（續） ）。
支持ESFramework的Tcp組件都需要實現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 ;} // 當前連接的數量
9 int RecieveBuffSize{ get ; set ;}
10 int MaxMessageSize{ set ;} // 當發現的消息長度大于MaxMessageSize，將關閉對應的連接
11
12 ITcpStreamDispatcherDispatcher{ set ;} // 支持依賴注入
13 IContractHelperContractHelper{ set ;}
14 IBufferPoolBufferPool{ set ;}
15 IEsbLoggerEsbLogger{ set ;} // 記錄運行日志
16
17 event CbSimpleIntSomeOneConnected; // 上線,ConnectID
18 event CbSimpleIntConnectionCountChanged; // 在線人數變化
19
20 event CallBackDisconnectSomeOneDisConnected; // 掉線,ConnectID
21 event CallBackRespondServiceCommitted; // 用戶請求的服務的回復信息
22 event CallBackRespondServiceDirectCommitted; // 對應ITcpClientsController.SendData，此時無法確定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 ;} // 當前連接的數量
9 int RecieveBuffSize{ get ; set ;}
10 int MaxMessageSize{ set ;} // 當發現的消息長度大于MaxMessageSize，將關閉對應的連接
11
12 ITcpStreamDispatcherDispatcher{ set ;} // 支持依賴注入
13 IContractHelperContractHelper{ set ;}
14 IBufferPoolBufferPool{ set ;}
15 IEsbLoggerEsbLogger{ set ;} // 記錄運行日志
16
17 event CbSimpleIntSomeOneConnected; // 上線,ConnectID
18 event CbSimpleIntConnectionCountChanged; // 在線人數變化
19
20 event CallBackDisconnectSomeOneDisConnected; // 掉線,ConnectID
21 event CallBackRespondServiceCommitted; // 用戶請求的服務的回復信息
22 event CallBackRespondServiceDirectCommitted; // 對應ITcpClientsController.SendData，此時無法確定ServiceKey
23 }
24
25 public delegate void CallBackRespond( int connectID,NetMessagemsg);
26 public delegate void CallBackDisconnect( int connectID,DisconnectedCausecause);
上面接口定義中的注釋已經解釋了大多數內容，額外地，我需要解釋一下幾件事情：
（1）為什么ITcp沒有從一個更基礎的接口比如INet繼承，這樣ITcp和IEsbUdp（后面將要介紹的Udp組件的基礎接口）就有了共同的根源？
早在EnterpriseServerBase中確實是這樣設計的，但是在ESFramework中卻將它們嚴格的隔離開來，原因在于，Tcp與Udp是如此的不同，如果要它們相互遷就共同遵守同一個“有意義”的基礎接口并不是一件愉快的事情。這里說的“有意義”，指的是，我們可以通過這個接口來幾乎完整的操縱不同的Tcp組件和Udp組件，而不需要進行向下轉換。我們曾在一個早期的應用中，使之即支持Tcp協議，有支持Udp協議，只需簡單修改一下配置文件，就可以簡單的從一個協議切換到另一個。我們實現了這個目標，但是程序的實現中摻雜了太多的if...else和向下轉換，有人一定會建議，使用多態可以避免if...else，讓我告訴你這樣做的難處在哪里。如果使用多態替換if...else，就需要將更多的東西抽象到形式一致的接口中，但是，Tcp和Udp組件的很多方法的簽名是無法達成一致的，除非都使用Object類型，可是，如果都使用Object類型的參數，在方法的實現中，仍然需要向下進行轉換。可見這樣做并沒有任何好處。首先是使得邏輯更加復雜含混，而且對效率也沒有任何幫助。
所以太不相同的事物，就沒有必要給它們安排一個共同的祖先。也許，我們可以給予一個沒有多大意義的基礎接口，比如像
public
interface
INet
{
void Initialize();
void Start();
void Stop();
int Port{ get ; set ;}
}
這沒有多大的用處。如果有一天，ESFramework發現了可以從ITcp和IEsbUdp中抽象出一個有意義的基礎接口的時候，會重構來得到這個接口，這也是很簡單的。
{
void Initialize();
void Start();
void Stop();
int Port{ get ; set ;}
}
（2）通過MaxMessageSize屬性可以設置應用中所允許的單個消息的最大長度，如果從某連接上接收到的消息的長度大于此值，則Tcp組件會關閉對應的連接。如果對消息長度沒有限制，則可以設置為int.MaxValue。
（3）Dispatcher屬性是為Tcp組件設置消息分配器，每當Tcp組件接收到一個完整的消息，就會把它交給分配器進行分派處理。消息分配器是ESFramework的核心組件，前面已經做了詳細介紹。
（4）BufferPool是緩沖區池，如果tcp發現即將接收的消息的長度大于RecieveBuffSize屬性給定的值，則會從BufferPool申請更大的緩沖區來接收消息，為了避免大緩沖區的重復創建/銷毀的開銷，并增加復用，所以使用BufferPool來管理較大的緩沖區。
public
interface
IBufferPool
{
byte []RentBuffer( int minSize);
void GivebackBuffer( byte []buffer);
}
{
byte []RentBuffer( int minSize);
void GivebackBuffer( byte []buffer);
}
（5）ServiceCommitted事件，當服務器處理完一個用戶請求并把回復發送出去后，將觸發該事件。如果ServiceCommitted事件被引發，表示回復數據已經被發送出去了。
（6）我們看到了ITcp從ITcpClientsController繼承，ITcpClientsController接口用于服務器主動控制TCP客戶的連接，比如，在消息分配器組件中可能需要控制ITcp組件來直接向某個用戶發送Active數據，這時只需要引用ITcpClientsController就可以了。
public
interface
ITcpClientsController
{
// 主動給某個客戶同步發信息
void SendData( int ConnectID,NetMessagemsg);
// 主動關閉連接
void DisposeOneConnection( int connectID,DisconnectedCausecause);
}
{
// 主動給某個客戶同步發信息
void SendData( int ConnectID,NetMessagemsg);
// 主動關閉連接
void DisposeOneConnection( int connectID,DisconnectedCausecause);
}
關于ITcp的介紹就是這些，然而如何實現ITcp卻有多種方法，不同的實現方法所得到的并發量和效率可能千差萬別。所以ITcp的實現對與系統的效率和并發量有著非常關鍵的影響。ESFramework中ITcp的參考實現是AgileTcp（將在后文中講述），如果你有更好的實現，完全可以在采用ESFramework框架的同時使用自己實現的Tcp組件，ESFramework為你保留了這種權利－－ESFramework所有的重要組件都是可以替換的，只要遵循相同的接口即可：）
感謝關注！
轉到： ESFramework 可復用的通信框架（序）
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
