ESFramework介绍之(31)―― 消息分类及对应的处理器

    这是一篇迟到了很久的文章,要不是今天看到Mediar朋友写的“基于ESFramewok的 客户端和客户端通迅”的文章,我也许还不会想起写这篇应该很早就发表的Blog,它可以帮助ESFramework的研究者/使用者们更好的使用ESFramework。Mediar朋友的那篇文章中介绍了通过服务器转发P2PMessage,Mediar手动实现了一个自己的处理器,实际上ESFramework已经内置了P2PMessage的处理器,那就是P2PMessageDealer,P2PMessageDealer不仅可以把消息转发给连接到同一个AS上的好友,而且可以转发给连接到异地AS上的好友。不管怎样,还是要感谢Mediar为我们提供的示例!

    到目前为止,ESFramework将接收自终端用户的消息分为6类,这可以通过ServiceType枚举看出来:

    public enum ServiceType
    {
        Basic ,           //IBasicRequestDealer
        Function ,
        P2PMessage ,      //对于P2P消息,服务器仅仅转发,P2PMessageDealer
        FriendRelation ,  //如好友列表、好友资料等 ,FriendRelationDealer
        GroupMessage ,    //如多人联网游戏中的同步消息等(动态组消息) -- ActiveGroupMessageDealer
        CustomServiceType //自定义服务种类
    }

    我先解释一下这几种类型的消息含义:
(1)Basic,基本消息是类似这样的消息,比如登录、退出、check消息等。
(2)Function,功能请求消息是所有请求功能服务的消息,这样的请求消息都有对应的回复消息,比如查询、要求服务器计算而得到结果等等。ESFramework中,几乎所有的Function类型的消息都是由功能插件处理的。
(3)P2PMessage,点对点消息,是指用户发给另一用户而经过服务器中转的消息,比如即时通讯中的聊天消息等。
(4)FriendRelation,好友关系请求消息,比如请求好友列表、好友资料等,这在很多IM应用中是常见的。
(5)GroupMessage,动态组请求消息。ESFramework支持运行时动态组创建、管理等。
(6)CustomServiceType ,自定义的消息类型,即你的应用中用到的除上面5种消息类型以外的消息。
(7)还要补充一种消息,跨区域(AS)请求,这种类型的消息将被本地AS转发到目标AS去处理。(回顾跨区域AS

    ESFramework为每种类型的消息都提供了默认的处理器(或处理器接口),它们是:
(1)对于Basic消息类型,ESFramework提供了IBasicRequestDealer接口,你的应用只要实现此接口就可处理所有的Basic消息。
(2)对于Function类型的消息,由于通常是由功能插件处理,所以ESFramework提供了FunAddinDealerFactory来处理所有的功能请求消息。
(3)P2PMessage,对于所有要转发的消息,ESFramework提供了P2PMessageDealer,P2PMessageDealer可以进行本区域转发和跨区域(AS)转发。如果需要将转发失败的消息存储以待以后重试,可以使用IOverdueMessageHandler
(4)FriendRelation,对于好友关系请求,ESFramework提供了FriendRelationDealer处理器,你只需要实现该处理器使用到的其它组件接口即可。
(5)GroupMessage,对于动态组请求消息,ESFramework提供了ActiveGroupMessageDealer可以直接进行处理。
(6)CustomServiceType ,对于应用自定义的消息类型,你需要实现自己的消息处理器。
(7)对于跨区域(AS)请求,你可以根据AS之间的通信方式实现特定的处理器。如果AS之间采用.net remoting通信,则ESFramework提供了ESFramework.Architecture.FourTier.ForeignDealer来处理跨区域请求。

    所有上述的消息处理器都可以装配到EsbRequestDealerFactory工厂,EsbRequestDealerFactory为每种类型的消息都预留了处理器插槽,你可以通过对应的属性进行处理器注入!图示如下:

    (图中黄色背景的组件都已经在ESFramework中提供了实现!BasicRequestDealer需要你实现IBasicRequestDealer接口)

    如果你的应用只需要使用其中几种类型的消息,那么只需要为EsbRequestDealerFactory装配对应的消息处理器,这样不会为不使用的消息类型付出任何额外的代价。

上一篇文章:ESFramework介绍之(30)―― 消息侦察者 INetMessageSpy

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

时间: 2024-09-20 16:37:57

ESFramework介绍之(31)―― 消息分类及对应的处理器的相关文章

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

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

ESFramework介绍之(30)―― 消息侦察者 INetMessageSpy

    (本文适用于ESFramework V0.2+)     现在我们回想一下,当网络组件(Tcp/Udp组件)接收到一个消息后,这个消息会流经哪些组件,然后再通过网络组件发送出去了.如果你研究过ESFramework V0.1,你会发现,消息"行走"的路线模型可以用下图表示出来:    请求消息(路径由黑线表示)经过网络组件后,会被Hook链中的各个Hook按照特定的顺序处理,然后到达消息处理器,消息处理器处理请求消息,并给出回复消息(路径由红线表示),回复消息同样再经过Hook

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

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

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

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

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

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

ESFramework介绍之(13)-- 功能插件处理器工厂

    上文讲述的是AS中的基于连接池的消息处理器,现在我们把焦点转移到功能服务器FS上来,看看FS上消息分派的过程.当FS接收到到一个请求后,会从已加载的功能插件列表中选择一个合适的插件来处理这个消息,而每一个功能插件就相当于一个消息处理器.FS和AS的结构一致:    要注意的是,功能服务器FS上收到的所有消息都应该交给功能插件来处理,不存在其它的处理方式.这是使得FS"纯粹"的必须要求.上图已经很清楚的表示了功能插件处理器工厂的位置和作用.它借助插件管理器实现"工厂&q

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

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

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介绍之(14)-- AS与FS通信方案

    前面我们已经多次提到,每个AS都有一组FS为之服务(回顾),AS将接收到的功能请求通过Tcp连接池 或Remoting转发给某个FS处理.下面我们将深入讨论AS和FS之间的通信机制.     首先要解决第一个问题,AS如何知道每个为之服务的FS的地址?    最常见的一种解决方案是,AS处的配置文件中有一个FS地址列表,AS每次启动时,就读取这个列表,然后与列表中的每个FS建立Tcp连接池.这种方案很容易实现,但是有很多缺点.最主要的是当动态的添加/移除FS时,都需要修改AS配置文件中的