2006年已经来临，回首刚走过的2005，心中感慨万千。在人生和生活的目标上，有了清晰明确的定位，终于知道了自己喜欢什么样的生活，喜欢什么样的生活方式；在技术上，成熟了不少，眼界也开阔的不少，从面向对象到组件、从.Net到J2EE、从微软到开源，颇有收获。特别值得一提的是，认识了Rod Johnson这个大牛人，也终于在自己的项目中正式使用Spring.net框架来开发了，这确实是一个优秀的框架。而在已经到来的2006年，我有一个主要目标就是B/S应用开发，来填补自己在企业级开发上的另一半空白。
以前就很想将自己在Tcp通信层的开发心得、经验共享出来，但一直没有实现，究其原因，还是自己太懒了。今天终于找到一个时机，写下这篇文章，也算是对2005年的另一种形式的回忆吧。
绝大多数C/S（包括多层）结构的系统中，终端与服务器的通信都是通过Tcp进行的（使用Udp的也有一些，但是其相对于Tcp简单许多，所以不在这里的讨论之列）。通常，这样的C/S系统都需要处理极大的并发，也就是说随时都可能有成千上万个用户在线，并且每分钟都可能有数以百计的用户上线/下线。由于每个用户都与服务器存在着一个Tcp连接，如何管理所有这些连接，并使我们的Tcp通信层稳定高效地工作，是我开发的这个“TcpTcp通信层”设计实现的主要目标。
自从2004年9月开始至今，我就一直负责某C/S系统的服务器端的架构设计，并负责整个通信层的实现，在探索的过程中，逐渐形成了一套可复用的“Tcp通信层框架”（“框架”这个词真的蛮吓人，呵呵），其位于EnterpriseServerBase类库的EnterpriseServerBase.Network命名空间中。现将我在通信层这一块的设计/开发经验记录于此，以便日后回顾。也期大家多多赐教。
我期望的“Tcp通信层”并不只是能接受连接、管理连接、转发用户请求这么简单，为了构建一个高度可复用的、灵活的、可接插的Tcp通信层，需要定义很多的规则、接口、契约，这需要做很多的工作。“Tcp通信层”决不仅仅只是Tcp协议通信，由于通信与消息联系紧密，不可避免的需要将“通信的消息”纳入到我们的分析中来，比如，基于Tcp传输的特性，我们可能需要对接收到的消息进行分裂、重组等（后文中会解释为什么、以及如何做）。请允许我在这里澄清一下，如果只是解决“仅仅”的Tcp通信问题，我只需要介绍Tcp组件就可以了，但是如果要解决“整个Tcp通信层”的问题，并使之可高度复用，那就需要介绍很多额外的东西，比如，上面提到的“消息”，以及“消息”所涉及的通信协议。
在我们应用的通信层中，存在以Tcp组件为核心的多个组件，这些组件相互协作，以构建/实现高度可复用的Tcp通信层。这些组件之间的关系简单图示如下：
我先解释一下上图。当网络（Tcp）组件从某个Tcp连接上接收到一个请求时，会将请求转发给消息分派器，消息分派器通过IDataStreamHelper组件获取请求消息的类型，然后根据此类型要求处理器工厂创建对应类型的请求处理器，请求处理器处理请求并返回结果。接下来再由网络组件把结果返回给终端用户。在消息分派器进行请求消息分派之前，可能涉及一系列的操作，像消息加密/解密、消息分裂/重组、消息验证等。而且，根据不同的应用，可能有其它的消息转换要求，而且这些操作可能是多样化的，为了满足这种多样性和可接插性，这就需要消息分派器提供一个插入点，让我们可以随心所欲地插入自定义的对请求/回复消息的预处理和后处理。
上图中消息分派器中可接插的操作除了消息分裂器（使用实线框）是必须的，消息加密器和消息验证器（使用虚线框）是可选的，应根据你应用的实际情况加以决定是否使用。关于这几个典型的可接插的组件的功能作用会在后文中介绍。在继续介绍Tcp组件的实现之前，有必要先提一下IDataStreamHelper接口的作用，IDataStreamHelper接口用于抽象我们实际的通信协议，并能从任何一请求/回复消息中提取关于本条消息的元数据，比如，消息的长度、类型等信息。具体的应用必须根据自己的消息协议来实现IDataStreamHelper接口。关于该接口的定义也在后文中给出。
关于上图，需要提醒的是，整个消息的流动是由Tcp组件驱动的！这篇文章以Tcp组件和消息分派器组件为索引来组织整个可复用的Tcp通信层的实现。首先，我们来深入到Tcp组件的具体实现中去。
[1] [2] [3] [4] [5] [6] 下一页