ESFramework介绍之(32)―― Tcp客户端核心组件关系图

    如果你的客户端基于ESFramework构建,并使用Tcp与服务端通信。通过这篇文章你将知道如何迅速、高效地创建客户端应用。

    ESFramework对基于Tcp客户端的支持主要在ESFramework.Network.Tcp.Passive命名空间,下图给出了该命名空间中的核心组件,以及这些组件之间的关系:

    下面解释一下这些组件的作用、职责。我们从最底层的通信组件NetworkStream向上看:
(1)NetworkStream 即是System.Net.Sockets.NetworkStream类,在ESFramework中,它是最底层的通信组件。

(2)ITcpAutoSender组件,它主要实现了数据的自动发送和数据优先级。关于ITcpAutoSender的更多信息,可以参见ESFramework介绍之(16)―― Tcp数据自动发送器ITcpAutoSender

(3)ITcpPassive组件,这个组件类似于服务端的ITcp组件,所有应用的网络数据的进出都必须经过它。ITcpPassive 封装了数据接收线程,完全向客户端隐藏了网络通信细节。ITcpPassive构建在ITcpAutoSender之上,所有的数据发送都委托给ITcpAutoSender。而数据的接收仍然是直接使用NetworkStream 。

(4)ITcpServerAgent组件,它使得使用基于消息请求/回复的与服务器的交互就像本地方法调用一样。关于它的详细介绍,请参见ESFramework介绍之(7)-- 服务器代理IServerAgent 。

(5)HookList,即INetMessageHook链,这个我们在介绍服务端时已经见过很多了。ESFramework对于客户端提供了Hook的支持,但是没有提供对Spy的支持,这是因为绝大多数情况下,我们的客户端并不需要Spy消息。(关于Hook与Spy的区别,可以参见ESFramework介绍之(30)―― 消息侦察者 INetMessageSpy

(6)IDataDealerFactory组件,处理器工厂,可以直接使用ESFramework.Network.Passive.EsbPassiveDealerFactory组件。

(7)EsbPassiveDataDealer组件,如果你的应用在ITcpServerAgent组件的层次上创建,那么就可以直接使用 EsbPassiveDataDealer来处理所有的来自服务端的数据。EsbPassiveDataDealer将所有来自服务器的数据分为如下几类:

    public enum PassiveMessageType
    {
        Response ,
        Ack ,
        P2PMessage ,
        Notify //服务器给的通知
    }

    其中,P2PMessage和Notify都是SingleMessage。服务器发过来的一个消息,如果没有请求与之对应,则称之为单身消息SingleMessage。EsbPassiveDataDealer将所有的SingleMessage交给ISingleMessageDealer组件处理,而将所有的回复消息或ACK消息放到IResponseManager(基于此,才可实现ITcpServerAgent的主要目的)。

(8)ISingleMessageDealer组件,用于处理所有的SingleMessage,如P2PMessage和Notify。

    通常,你的应用可以在两个层次上创建,ITcpPassive层次和ITcpServerAgent层次。
    我推荐在ITcpServerAgent层次上创建应用,这样你可以省去很多麻烦,充分发挥ESFramework框架的能力。而且,你会得到这些好处:
(1)回复消息与请求消息的自动匹配。如果应用构建于ITcpPassive层次,则你必须在应用中自己来将回复与请求一一对应起来。
(2)像调用本地方法一样与服务器进行交互。所有与服务器的交互都通过ITcpServerAgent.CommitRequest方法进行,如果需要回复消息,则回复消息直接通过ITcpServerAgent.CommitRequest方法的返回值获得。
(3)使得客户端业务功能可以以插件形式实现。这主要也是得力于ITcpServerAgent,它使得网络变得透明,并且将异步的消息请求/回复转变成同步。在插件内部,可以直接使用ITcpServerAgent与服务端交互来同步获取服务结果。关于客户插件IPassiveAddin的更多信息,可以参见ESFramework介绍之(8)-- 客户端插件IPassiveAddin
(4)你仅仅需要实现ISingleMessageDealer接口来处理服务端发过来的P2PMessage和Notify,而不必创建额外的处理器来处理Response和Ack消息。

转到  :ESFramework 可复用的通信框架(序) 

时间: 2024-09-20 16:51:33

ESFramework介绍之(32)―― Tcp客户端核心组件关系图的相关文章

AS与FS通信实现 —— ESFramework介绍之(33)

    (本文部分内容只适合ESFramework V0.3+)     在ESFramework介绍之(14)-- AS与FS通信方案 一文中,我们讲到了AS与FS之间基本的通信方案,并且采取了一些策略来保证AS与FS之间的稳定通信.本文我们将给出AS与FS通信的两种实现,即基于Tcp连接池的通信实现和基于Remoting的通信实现.     我们已经知道,AS与FS之间的通信分为两类,一类是非功能通信,一类是功能通信.非功能通信指的是FS向AS注册.注销等通信,这种通信仅仅是FS主动联系AS

ESFramework介绍之(18)―― Tcp用户管理器组件

    当我们的应用中客户端与AS之间是通过Tcp进行通信的时候,通常,应用也要求管理所有在线的用户.这种管理至少包含以下几点:(1) 当用户上线时,记录上线时间(2) 当用户请求服务时,记录请求服务的时间.服务的类型.本次服务下载的数据量(3) 当用户下线时,记录下线时间.并把本次用户登录.请求服务过程中的所有信息持久化保存(如记录到数据库)     在ESFramework中,实现这种管理的是ITcpUserManager组件,通常,该组件由AS使用(因为在AS.FS.IRAS中只有AS是必

ESFramework介绍之(34)―― ITcpServerAgent和IUdpServerAgent组件关系图

    (本文适用于ESFramework V0.3+)     在ESFramework介绍之(7)-- 服务器代理IServerAgent(2006.06.06修正) 的介绍中,我们已经认识了IServerAgent的职责与作用,并且知道了 ITcpServerAgent和IUdpServerAgent是分别使用于Tcp和Udp的ServerAgent.但是它们与其它组件(比如通信组件.消息处理器.处理器工厂)之间的联系是怎样的,前文讲的还不清楚,所以这里增加一篇文章,把这个关系理顺.下面分

ESFramework介绍之(8)-- 客户端插件IPassiveAddin

    前文已经提到了,在IServerAgent的基础上,客户端也可以采用插件的结构形式,客户端插件需要实现IPassiveAddin接口.    我的想法是,当客户端主程序加载一个新的PassiveAddin时,可以在某个菜单的子Items上添加一项,当双击这个子菜单项时,则弹出该客户端插件提供的"业务操作窗体".这只是使用客户端插件的可行方式之一,你完全可以根据你的应用来决定使用形式.IPassiveAddin接口定义如下:  1     /// <summary> 

ESFramework介绍之(10)-- Tcp连接池

    凡是带有"池"的,比如数据库连接池.对象池.缓冲区池(后面可以看到IBuffPool)等等,都是为了避免资源的反复创建/销毁所带来的开销.需要为哪些资源对象建立"池"了?这些资源对象通常符合下面几个特性:(1)在应用中需要反复的被创建/销毁.(2)创建/销毁的开销比较大(3)应用中给定时刻,对该资源对象的数量要求比较大(4)资源对象最好是无状态的(Stateless),这样方便直接复用     AS(回顾)将所有的功能服务请求转发给为该AS提供服务的FS群中

ESFramework介绍之(11)-- Tcp连接池管理器

    上文已经讲到,Tcp连接池管理器为我们的应用进行了很多复杂的管理,比如功能服务器的调度(实现FS的负载均衡).连接池的动态添加/移除.控制每个连接池的相关参数在UI上的显示等,并且连接池管理器与单个连接池拥有一样的接口ITcpPool.我们先回顾一下这个接口:   1     public interface ITcpPool 2     { 3         RentStreamResult RentTcpStream(int poolTypeKey ,int serviceKey 

ESFramework介绍之(4)――消息拦截器INetMessageHook

    网络上传输的消息经常是经过加密和压缩,有的特定类型的消息可能还需要进行其它变形,ESFramework通过INetMessageHook对这些功能提供支持.需要说明的是,ESFramework对消息进行截获(Hook)处理有两种方式,一是仅仅Hook处理消息主体(Body),而不对消息头作任何变换:另一种方式是对整个消息(包括消息头和主体)都进行Hook处理.通常,第一种方式已经能够满足我们的大多数应用,并且效率也更高,如果应用有更特殊的要求,可以采用第二种方式.本文先介绍第一种方式,后

ESFramework介绍之(9)-- 插件对(Addin Pair)调试“框架”

    使用ESFramework开发C/S(通常为4层.3层也没问题)应用,当需要增加一项新的业务时,我们需要做的仅仅是开发两个插件,一个是服务端的业务功能插件(FunAddin),一个是客户端插件(PassiveAddin),这两个插件合在一起称为Addin Pair.开发这两个插件,只需要关注于业务,而其它与业务无关的比如网络通信.加密.数据安全,都不用管.ESFramework很好的将这些关注点分离开来,使得写"业务"插件的程序员的工作变得非常单纯,在ESFramework介绍

ESFramework介绍之(17)―― 支持漫游用户和跨区域功能请求

    对于漫游用户的支持和跨区域功能请求的支持是ESFramework最基本的目的之一(回顾),在详细讲述解决方案之前,先了解一下关于这个问题的上下文.    在我们前面讲述的4层C/S架构中,每个AS负责一块区域.比如上海AS负责处理所有目标城市为上海的功能请求和管理所有在上海AS上注册的用户(比如PDA用户或手机用户).如果一个本是在上海注册的用户出差来到了武汉,最方便的,他会连上武汉的AS,这样对于武汉AS来说,这个用户就是漫游用户了.    如果上海的用户登陆上了上海的AS,但是他需要