.NET平台下可复用的Tcp通信层实现

    2006年已经来临,回首刚走过的2005,心中感慨万千。在人生和生活的目标上,有了清晰明确的定位,终于知道了自己喜欢什么样的生活,喜欢什么样的生活方式;在技术上,成熟了不少,眼界也开阔的不少,从面向对象到组件、从.NetJ2EE、从微软到开源,颇有收获。特别值得一提的是,认识了Rod Johnson这个大牛人,也终于在自己的项目中正式使用Spring.net框架来开发了,这确实是一个优秀的框架。而在已经到来的2006年,我有一个主要目标就是B/S应用开发,来填补自己在企业级开发上的另一半空白。     
    以前就很想将自己在
Tcp通信层的开发心得、经验共享出来,但一直没有实现,究其原因,还是自己太懒了。今天终于找到一个时机,写下这篇文章,也算是对2005年的另一种形式的回忆吧。

    绝大多数C/S(包括多层)结构的系统中,终端与服务器的通信都是通过Tcp进行的(使用Udp的也有一些,但是其相对于Tcp简单许多,所以不在这里的讨论之列)。通常,这样的C/S系统都需要处理极大的并发,也就是说随时都可能有成千上万个用户在线,并且每分钟都可能有数以百计的用户上线/下线。由于每个用户都与服务器存在着一个Tcp连接,如何管理所有这些连接,并使我们的Tcp通信层稳定高效地工作,是我开发的这个“TcpTcp通信层”设计实现的主要目标。
    自从20049月开始至今,我就一直负责某C/S系统的服务器端的架构设计,并负责整个通信层的实现,在探索的过程中,逐渐形成了一套可复用的“Tcp通信层框架”(“框架”这个词真的蛮吓人,呵呵),其位于EnterpriseServerBase类库的EnterpriseServerBase.Network命名空间中。现将我在通信层这一块的设计/开发经验记录于此,以便日后回顾。也期大家多多赐教。
    我期望的“Tcp通信层”并不只是能接受连接、管理连接、转发用户请求这么简单,为了构建一个高度可复用的、灵活的、可接插的Tcp通信层,需要定义很多的规则、接口、契约,这需要做很多的工作。“Tcp通信层”决不仅仅只是Tcp协议通信,由于通信与消息联系紧密,不可避免的需要将“通信的消息”纳入到我们的分析中来,比如,基于Tcp传输的特性,我们可能需要对接收到的消息进行分裂、重组等(后文中会解释为什么、以及如何做)。请允许我在这里澄清一下,如果只是解决“仅仅”的Tcp通信问题,我只需要介绍Tcp组件就可以了,但是如果要解决“整个Tcp通信层”的问题,并使之可高度复用,那就需要介绍很多额外的东西,比如,上面提到的“消息”,以及“消息”所涉及的通信协议。
    在我们应用的通信层中,存在以Tcp组件为核心的多个组件,这些组件相互协作,以构建/实现高度可复用的Tcp通信层。这些组件之间的关系简单图示如下:
    .NET平台下可复用的Tcp通信层实现
 

    我先解释一下上图。当网络(Tcp)组件从某个Tcp连接上接收到一个请求时,会将请求转发给消息分派器,消息分派器通过IDataStreamHelper组件获取请求消息的类型,然后根据此类型要求处理器工厂创建对应类型的请求处理器,请求处理器处理请求并返回结果。接下来再由网络组件把结果返回给终端用户。在消息分派器进行请求消息分派之前,可能涉及一系列的操作,像消息加密/解密、消息分裂/重组、消息验证等。而且,根据不同的应用,可能有其它的消息转换要求,而且这些操作可能是多样化的,为了满足这种多样性和可接插性,这就需要消息分派器提供一个插入点,让我们可以随心所欲地插入自定义的对请求/回复消息的预处理和后处理。
    上图中消息分派器中可接插的操作除了消息分裂器(使用实线框)是必须的,消息加密器和消息验证器(使用虚线框)是可选的,应根据你应用的实际情况加以决定是否使用。关于这几个典型的可接插的组件的功能作用会在后文中介绍。在继续介绍Tcp组件的实现之前,有必要先提一下IDataStreamHelper接口的作用,IDataStreamHelper接口用于抽象我们实际的通信协议,并能从任何一请求/回复消息中提取关于本条消息的元数据,比如,消息的长度、类型等信息。具体的应用必须根据自己的消息协议来实现IDataStreamHelper接口。关于该接口的定义也在后文中给出。
    关于上图,需要提醒的是,整个消息的流动是由Tcp组件驱动的!这篇文章以Tcp组件和消息分派器组件为索引来组织整个可复用的Tcp通信层的实现。首先,我们来深入到Tcp组件的具体实现中去。 

一.Tcp组件

1Tcp组件的主要职责
       Tcp组件的主要职责并不是在一个很短的时间内总结出来的,它是逐步完善的(至今可能还不够全面)。为了使Tcp组件具有高度的可复用性,需要考虑很多的需求,而所有这些需求中具有共性的、占主导位置的需求就被纳入到Tcp组件的职责中来了。这个职责的集合如下:
(1)       管理所有的Tcp连接以及连接对应的上下文(Context)。
(2)       当某用户上线或下线时,能发出事件通知。
(3)       当在线用户(连接)的数量发生变化时,能发出事件通知。
(4)       当用户的请求得到回复时,发出事件通知。这一点对于记录用户请求和跟踪用户请求非常有用)
(5)       能及时主动关闭指定连接。比如,当某一非法用户登录后,用户验证组件通知Tcp组件强行关闭该用户对应的连接。
(6)      
除了能转发用户请求及对请求的应答(通过消息分派器)外,还能直接对指定的用户发送数据。这也要求我们的Tcp连接是多线程安全的。
(7)       提供绕开Tcp组件直接从Tcp连接同步接收数据的功能。比如,客户端需要上传一个Blob,我们可能希望直接从Tcp连接进行接收数据,这是有好处的,后面可以看到。
    这里列出的是Tcp组件的主要职责,还有很多细节性的没有罗列出来,如果一个Tcp组件解决了上述所有问题,对我来说,应该就是一个很好用、很适用的Tcp组件了。

2Tcp组件接口定义
       相信很多朋友和我一样,刚接触Tcp服务端开发的时候,通常是当一个Tcp连接建立的时候,就分配一个线程在该连接上监听请求消息,这种方式的缺点有很多,最主要的缺点是效率低、管理复杂。
    我的最初的Tcp组件是C++版本的,那时很有幸接触到了windows平台上最高效的Tcp通信模型――完成端口模型,完全理解这个模型需要点时间,但是Win32 多线程程序设计》(侯捷翻译)和《windows网络编程》这两本书可以给你不少帮助。异步机制是完成端口的基础,完成端口模型的本质思想是将"启动异步操作的线程""提供服务的线程"(即工作者线程)拆伙。理解这一点很重要。在.Net中没有对应的组件或类对应于完成端口模型,解决方案有两个:一是通过P/Invoke来实现自己的完成端口组件,另一种方式是通过.Net的现有通信设施来模拟完成端口实现。
    本文给出第二种方案的实现说明,另外,我也给出通过“异步+线程池”的方式的Tcp组件实现,这种方式对于大并发量也可以很好的管理。也就是我,我的EnterpriseServerBase类库中,有两种不同方式的Tcp组件实现,一个是模拟完成端口模型,一个是“异步+线程池”方式。无论是哪种方式,它们都实现了相同的接口ITcpITcp这个接口涵盖了上述的Tcp组件的所有职责,这个接口并不复杂,如果理解了,使用起来也非常简单。我们来看看这个接口的定义:

      public   interface  ITcp :INet ,ITcpEventList ,ITcpClientsController
    {
        
int  ConnectionCount{ get  ;}  // 当前连接的数量
    }    

    这个接口继承了另外三个接口,INet ,ITcpEventList ,ITcpClientsControllerINet接口是为了统一基于TcpUdp的通信组件而抽象出来的,它包含了以下内容:

    public   interface  INet
    {
        
void  InitializeAll(IReqestStreamDispatcher i_dispatcher , int  port ,  bool  userValidated) ;        
        
void  InitializeAll() ;
        
void  UnitializeAll() ;        

        NetAddinType GetProtocalType() ; 
// Udp, Tcp
         event  CallBackDynamicMessage DynamicMsgArrived ;  // 通常是通信插件中一些与服务和用户无关的动态信息,如监听线程重启等
         void  Start() ;
        
void  Stop() ;

        IReqestStreamDispatcher Dispatcher{
set ;}  // 支持依赖注入
         int                         Port{ get  ; set  ;}
        
bool                     UserValidated{ set  ;}
    }
    
    
public   enum  NetAddinType
    {
        Tcp ,Udp
    }    

    
public   delegate   void  CallBackDynamicMessage( string  msg) ;

    IReqestStreamDispatcher就是我们上述图中的消息分派器,这是Tcp通信层中的中央,它的重要性已从前面的关系图中可见一斑了。IReqestStreamDispatcher需要在初始化的时候提供,或者通过Dispatcher属性通过IOC容器进行设值法注入。UserValidated属性用于决定当用户的第一个请求不是登录请求时,是否立即关闭Tcp连接。其它的属性已经加上了注释,非常容易理解。
    ITcpEventList接口说明了Tcp组件应当发布的事件,主要对应于前述Tcp组件职责的(2)(3)(4)点。其定义如下:

    public   interface  ITcpEventList
    {            
        
event  CallBackForTcpUser2   SomeOneConnected ;     // 上线
         event  CallBackForTcpUser1   SomeOneDisConnected ;  // 掉线
         event  CallBackForTcpCount   ConnectionCountChanged ; // 在线人数变化
         event  CallBackForTcpMonitor ServiceCommitted ; // 用户请求的服务的回复信息    
         event  CallBackForTcpUser    UserAction ;        
    }

    每一个在线用户都对应着一个Tcp连接,我们使用tcp连接的Hashcode作为ConnectID来标志每一个连接。UserAction将用户与服务器的交互分为三类:登录、退出和标准功能访问,如以下枚举所示。

    public   enum  TcpUserAction
    {
        Logon , Exit , FunctionAccess , 
// 标准的功能访问        
    }

最后一个接口ITcpClientsController,主要用来完成上述Tcp组件职责的(5)(6)(7)三点。定义如下:

    ///   <summary>
    
///  ITcpController 用于服务器主动控制TCP客户的连接
    
///   </summary>
     public   interface  ITcpClientsController
    {
        
// 同步接收消息
         bool  SynRecieveFrom( int  ConnectID , byte [] buffer,  int  offset,  int  size , out   int  readCount) ;

        
// 主动给某个客户同步发信息
         void  SendData( int  ConnectID , byte [] data) ;
        
void  SendData( int  ConnectID,  byte [] data , int  offset , int  size) ;

        
// 主动关闭连接
         void  DisposeOneConnection( int  connectID ,DisconnectedCause cause) ;
    }

    这个接口中的方法的含义是一目了然的。
    上述的几个接口已经完整的覆盖了前述的Tcp组件的所有职责,在了解了这些接口定义的基础上,大家已经能够使用EnterpriseServerBase类库中的Tcp组件了。如果想复用的不仅仅是Tcp组件,而是整个Tcp通信层,你就需要关注后面的内容。不管怎样,为了文章的完整性,我在这里先给出前面提到的Tcp组件的两种实现。 

3Tcp组件基本元素实现
       在实现Tcp组件之前,有一些基本元素需要先建立起来,比如安全的网络流、Tcp监听器、用户连接上下文、上下文管理者等。1)安全的网络流SafeNetworkStream
    前面已经提到过,为了能在Tcp组件外部 对指定的连接发送数据,必须保证我们的Tcp连接是线程安全的,而System.Net.Sockets.NetworkStream是非线程安全的,我们必须自己对其进行封装,以保证这一点。System.Net.Sockets.NetworkStream的线程安全的封装就是EnterpriseServerBase.Network.SafeNetworkStream类,它继承了ISafeNetworkStream接口:

 

    ///   <summary>
    
///  ISafeNetworkStream 线程安全的网络流 。
    
///  注意:如果调用的异步的begin方法,就一定要调用对应的End方法,否则锁将得不到释放。
    
///  作者:朱伟 [email protected] 
   
  ///   </summary>
     public interface ISafeNetworkStream :ITcpSender ,ITcpReciever
    {        
        
void Flush();
        
void Close() ;        
    }    


    
// 用于在TCP连接上发送数据,支持同步和异步
     public   interface  ITcpSender
    {                                                      
        
void  Write( byte [] buffer , int  offset , int  size) ;
        IAsyncResult BeginWrite(
byte [] buffer,  int  offset,  int  size, AsyncCallback callback,  object  state );
        
void  EndWrite(IAsyncResult asyncResult    );
    }

    
// 用于在TCP连接上接收数据,支持同步和异步
     public   interface  ITcpReciever
    {
        
int  Read ( byte [] buffer , int  offset , int  size) ;
        IAsyncResult BeginRead(    
byte [] buffer,  int  offset,  int  size, AsyncCallback callback,  object  state );
        
int  EndRead(IAsyncResult asyncResult );
    }   

    该接口几乎与System.Net.Sockets.NetworkStream提供的方法一样,只不过它们是线程安全的。这样,针对同一个SafeNetworkStream,我们就可以在不同的线程中同时在其上进行数据接收/发送(主要是发送)了。

2Tcp监听器EnterpriseServerBase.Network.XTcpListener
    不可否认,System.Net.Sockets.TcpListener只是提供了一些最低阶的工作,为了将监听线程、端口、监听事件整合起来,我引入了EnterpriseServerBase.Network.XTcpListener类,它可以启动和停止,并且当有Tcp连接建立的时候,会触发事件。XTcpListener实现了IXTcpListener接口,其定义如下:

    public   interface  IXTcpListener
    {
        
void  Start() ;  // 开始或启动监听线程
         void  Stop() ;   // 暂停,但不退出监听线程

        
void  ExitListenThread() ; // 退出监听线程

        
event  CBackUserLogon     TcpConnectionEstablished ;  // 新的Tcp连接成功建立
         event  CallBackDynamicMsg DynamicMsgArrived ;
    }

    XTcpListener可以在不同的Tcp组件中复用,这是一种更细粒度的复用。
 

3)用户连接上下文ContextKey
       ContextKey用于将所有的与一个用户Tcp连接相关的信息(比如接收缓冲区、连接的状态――空闲还是忙碌、等)封装起来,并且还能保存该用户的请求中上次未处理完的数据,将其放于接收缓冲区的头部,并与后面接收到的数据进行重组。说到这里,你可能不太明白,我需要解释一下。Tcp协议可以保证我们发出的消息完整的、有序的、正确的到达目的地,但是它不能保证,我们一次发送的数据对方也能一次接收完全。比如,我们发送了一个100Bytes的数据,对方可能要接收两次才能完全,先收到60Bytes,再收到40Bytes,这表明我们可能会收到“半条”消息。还有一种情况,你连续发了两条100Bytes的消息,而对方可能一次就接收了160Bytes,所以需要对消息进行分裂,从中分裂出完整的消息然后进行处理。这,就是前面所说的需要对消息进行分裂、重组的原因。知道这点后,IContextKey接口应该比较容易理解了,因为该接口的很多元素的存在都是为了辅助解决这个问题。IContextKey的定义如下:

    public   interface  IContextKey
    {
        NetStreamState       StreamState{
get  ; set  ;}   // 网络流的当前状态--空闲、忙碌
        ISafeNetworkStream NetStream{ get  ; set  ;}   

        
byte []  Buffer{ get  ; set  ;}     // 接收缓冲区
         int         BytesRead{ get  ; set  ;}  // 本次接收的字节数
         int         PreLeftDataLen{ get  ; set  ;}        
        
bool     IsFirstMsg{ get  ; set  ;}  // 是否为建立连接后的第一条消息

        
int  StartOffsetForRecieve{ get  ;} 
        
int  MaxRecieveCapacity{ get  ;}  // 本次可以接收的最大字节数
        RequestData RequestData{ get  ;}

        
void  ResetBuffer( byte [] leftData) ; // leftData 表示上次没有处理完的数据,需要与后面来的数据进行重组,然后再次处理
    }

    对于消息的分裂和重组是由消息分裂器完成的,由于Tcp组件的实现不需要使用消息分裂器,所以消息分裂器的说明将在后面的消息分派器实现中讲解。 

4)上下文管理者ContextKeyManager
       ContextKeyManager用于管理所有的ContextKey,其实现的接口IContextKeyManager很容易理解:

    public   interface  IContextKeyManager
    {
        
void  InsertContextKey(ContextKey context_key) ;
        
void  DisposeAllContextKey() ;
        
bool  IsAllStreamSafeToStop() ;  // 是否可以安全退出
         void  RemoveContextKey( int  streamHashCode) ;
        
int  ConnectionCount { get  ;}
        ISafeNetworkStream GetNetStream(
int  streamHashCode) ;
        
event  CallBackCountChanged StreamCountChanged ;
    }

    在上述四个基本元素的支持下,再来实现Tcp组件就方便了许多,无论是以何种方式(如完成端口模型、异步方式)实现Tcp组件,这些基本元素都是可以通用的,所以如果你要实现自己的Tcp组件,也可以考虑复用上述的一些基本元素。复用可以在不同的粒度进行,复用真是无处不在,呵呵。 

4.完成端口Tcp组件实现
    前面已经提到,完成端口模型本质思想是将"启动异步操作的线程""提供服务的线程"(即工作者线程)拆伙。只要做到这一点,就模拟了完成端口。
    分析一下我们需要几种类型的线程,首先我们需要一个线程来接收TCP连接请求,这就是所谓监听线程,当成功的接收到一个连接后,就向连接发送一个异步接收数据的请求,由于是异步操作,所以会立即返回,然后再去接收新的连接请求,如此监听线程就循环运作起来了(已经封装成前述的XTcpListener组件了)。值得提出的是,在异步接收的回调函数中,应该对接收到的数据进行处理,完成端口模型所做的就是将接收到的数据放在了完成端口队列中,注意,是一个队列。第二种线程类型,就是工作者线程。工作者线程的个数有个经验值是( Cpu个数×2 2),当然具体取多少,还要取决于你的应用的要求。工作者线程的任务就是不断地从完成端口队列中取出数据,并处理它,然后如果有回复,再将回复写入对应的连接。
    好,让我们来定义接口IRequestQueueManager,用于模拟完成端口的队列,该队列是线程安全的,用于将所有的请求进行排队,然后由工作者线程来轮流处理这些请求。

    public   interface  IRequestQueueManager :IRequestPusher
    {        
        
object  Pop() ; // 弹出队列中的下一个请求
         void  Clear() ;
        
int  Length { get  ;}  // 队列长度
    }
    
    
public   interface  IRequestPusher
    {
        
void  Push( object  package) ;  // 向队列中压入一个请求
    }

    在IRequestQueueManager的基础上,可以将工作者线程和启动异步操作的线程拆开了。由于工作者线程只与端口队列相关,所以我决定将它们一起封装起来--成为IIOCPManager,用于管理请求队列和工作者线程。

    ///   <summary>
    
///  IIOCPManager 完成端口管理者,主要管理工作者线程和完成端口队列。
    
///   </summary>
     public   interface  IIOCPManager : IRequestPusher
    {
        
void  Initialize(IOCPPackageHandler i_packageHandler , int  threadCount) ;
        
void  Start() ;  // 启动工作者线程
         void  Stop() ;   // 退出工作者线程    

        
int  WorkThreadCount{ get  ;}

        
event  CallBackPackageHandled PackageHandled ;
    }

    
// IOCPPackageHandler 用于处理从完成端口队列中取出的package
     public   interface  IOCPPackageHandler
    {
         
void  HandlerPackage( object  package) ;  // 一般以同步实现
    }

    有了IRequestQueueManagerIIOCPManager的支持,实现基于完成端口模型的Tcp组件就非常简单了。当然,你也可以单独使用IIOCPManager。你只要提供一个监听者线程接收连接,并将从连接接收到的数据通过IRequestPusher接口放入端口队列就可以了。 当然,为了处理接收到的数据,我们需要提供一个实现了IOCPPackageHandler接口的对象给IOCPManager。值得提出的是,你可以在数据处理并发送了回复数据后,再次投递一个异步接收请求,以保证能源源不断的从对应的TCP连接接收数据。下面,我们来看基于完成端口模型的Tcp组件的完整实现。

完成端口Tcp组件



5.异步Tcp组件实现
    这种方式的主要思想是:当一个新的Tcp连接建立时,就在该连接上发送一个异步接收的请求(BeginRead),并在异步回调中处理该请求,当请求处理完毕,再次发送异步接收请求,如此循环下去。异步接收启用的是系统默认线程池中的线程,所以,在异步Tcp组件中不用显式管理工作线程。异步Tcp组件的实现相对于完成端口模型而言简单许多,也单纯一些,不用管理请求队列,不需使用工作者线程等等。但是,相比于完成端口模型,其也有明显的缺陷:一个Tcp连接绑定到了一个线程,即使这个线程是后台线程池中的。如果用户数量巨大,这对性能是极其不利的;而完成端口模型,则可以限定工作者线程的个数,并且可以根据应用的类型进行灵活调节。
    异步Tcp组件实现源码。 

 

异步Tcp组件


       今天介绍了Tcp通信层中的核心――Tcp组件,仅仅复用Tcp组件已经能为我们省去很多麻烦了,如果想进行更高层次的复用――整个Tcp通信层的复用,请关注本篇的续文。







你可能感兴趣的:(TCP通信)