ESFramework 4.0 快速上手（06） －－ Rapid引擎（续）

《ESFramework 4.0 快速上手》系列介绍的都是如何使用Rapid引擎（快速引擎） -- RapidServerEngine 和 RapidPassiveEngine。其实，大家可以将这两个引擎看作是两个壳，内部包装的才是真正的ESFramework的网络引擎， ESFramework支持很多种网络引擎（客户端/服务端、二进制协议/文本协议、TCP/UDP），而RapidServerEngine和RapidPassiveEngine采用的是基于TCP和二进制协议的服务端引擎和客户端引擎。这两个壳存在的目的，就是使大家不用了解ESFramework内部机制，就可以非常快速的上手ESFramework应用开发。但是，限制也是有的，那就是Rapid引擎仅仅使用了ESFramework最基础的功能，还有很多重要的功能，就不好通过Rapid引擎体现出来了。当然，通过复杂的封装，也可以做到全部体现，但是那样的话，Rapid引擎的上手就不是那么容易了，Rapid就不"Rapid"了。

　　尽管如此，对于一些简单的应用，Rapid引擎已经足够应付了。在这里，我再补充一些为了更好地使用Rapid引擎时需要了解的一些信息。

1. 对称性

ESPlus.Application命名空间下的组件用于协助我们快速地开发ESFramework应用程序，并且对服务端和客户端都提供了支持。比如，对于上面提到的自定义信息的支持，就是ESPlus.Application.CustomizeInfo命名空间做的事情，其下包含两个子命名空间：ESPlus.Application.CustomizeInfo.Server和ESPlus.Application.CustomizeInfo.Passive，分别用于服务端和客户端。

　　你可能已经注意到，像 ESPlus.Application.xxxxxx.Server 和 ESPlus.Application.xxxxxx.Passive 通常是成对出现的，都是为了解决xxxxxx问题而对服务端和客户端的支持。而且，这种成对的关系也不会出现错误的匹配，比如，服务端调用ESPlus.Application.Basic.Server下的IBasicController的Broadcast方法进行广播（对所有人），一定是由ESPlus.Application.Basic.Passive下的IBasicBusinessHandler接口的HandleBroadcastFromServer方法来处理，而不会错乱匹配到由ESPlus.Application.CustomizeInfo.Passive空间下的ICustomizeInfoBusinessHandler接口的HandleBroadcastFromServer方法（用于处理组内广播）来处理。

2. Rapid引擎仅仅使用了ESPlus.Application下的两个命名空间

Rapid引擎主要使用了ESPlus.Application.Basic和ESPlus.Application.CustomizeInfo命名空间下的组件。如果要使用ESPlus.Application下的其它命名空间中的组件（如ESPlus.Application.FileTransfering命名空间用于文件传输），那么就不能使用Rapid引擎这个壳了，必须使用ESFramework 4.0 概述中列出的那些真正的网络引擎。

3. Rapid引擎中简单的好友管理和组管理

IRapidServerEngine的Initialize方法有个稍微复杂的重载，即多接受IFriendsManager和IGroupManager两个参数，我稍微解释一下这两个参数的作用。

（1）IFriendsManager是给ESPlus.Application.Basic.Server下的组件用的，当某用户上下线时，需要通知该用户的好友（通过ESPlus.Application.Basic.Passive.IBasicBusinessHandler接口的相关方法），那么服务端从哪里知道该用户有哪些好友了，就是IFriendsManager接口：

    public interface IFriendsManager
    {
        List<string> GetFriendList(string ownerID);
    }

如果，调用RapidServerEngine的Initialize方法时，该参数传入null，则RapidServerEngine会自动使用DefaultFriendsManager，这个实现的假设是所有的在线用户都是好友 -- 所以，任何一个用户上下线，都会通知所有其他的在线用户。

（2）IGroupManager接口是给ESPlus.Application.CustomizeInfo.Server命名空间下的组件用的，当客户端或服务端需要在某个组内广播消息时，服务端需要根据groupID获取该组的成员，这就是通过IGroupManager接口来获取的：

    public interface IGroupManager
    {
        /// <summary>
        /// 获取某个组的所有成员列表。
        /// </summary>      
        List<string> GetMemberList(string groupID);
    }

如果在服务端Rapid引擎初始化时，该参数传入null，则RapidServerEngine会自动使用EmptyGroupManager，其GetMemberList方法将始终返回一个空的列表。如果需要用到组广播的功能，大家可以自己实现这个简单的接口，然后注入给服务端的Rapid引擎就行了。

（3）有很多朋友问到，如何添加好友，或如何创建组、或如何加入到某个组？这些都是由您的应用来决定的，ESFramework并没有任何限制。比如，ESFramework使用IGroupManager接口的目的仅仅是为了内置组内广播消息这一基本功能，所以，ESFramework对IGroupManager的定义非常简单，你的应用只要实现IGroupManager接口，就可以直接使用框架内置的广播功能了。

好，现在我们假设，你的项目需要类似QQ的加入群（组）的功能，那该怎么做了？其实您可以这样设计：定义一个请求加入组的自定义信息类型（比如1300），信息内容中包含了要加入群的号码；再定义一个加入组的回复的信息类型（比如1301），信息内容中包含了加入成功还是失败的结果。那么，在需要加入组的时候，客户端就发送类型为1300的信息给服务器，服务器收到并处理该消息后（比如可以将组关系保存到DB），返回类型为1301的消息给客户端，客户端收到1301类型的消息后，就可以UI上通知用户。具体的例子可以参见这篇文章。这样就实现了加入组的项目需求。类似，创建组、加好友、删除好友等需求都可以采用类似的做法，这些只要使用ESPlus提供的自定义信息功能就可以做到。如果你对自定义信息的使用还不是很熟悉，那么可以参考ESFramework 4.0 快速上手 －－ 如何使用自定义消息？。

关于ESFramework中好友与组更全面的描述，请参见ESFramework 4.0 进阶（11）－－ 好友与组。

4.UserID的长度

在ESFramework 4.0 进阶（01）－－ 消息一文中我们介绍了ESPlus提供了默认的消息头实现，而Rapid引擎使用的就是ESPlus提供的基于二进制的消息头StreamMessageHeader，这个消息头的默认长度是36字节，允许的UserID最大长度为11字节。但是，如果你的系统中需要用到的UserID长度超过了11字节，该怎么办了？我们可以通过调用StreamMessageHeader的SetMaxLengthOfUserID静态方法来设定ESFramework允许的UserID的最大长度：

        /// <summary>
        /// 设置UserID（包括GroupID）的最大长度(不能超过255)。注意，客户端与服务端要统一设置。
        /// </summary>  
        public static void SetMaxLengthOfUserID(byte maxLen)

注意，我们必须在Rapid引擎的Initialize方法执行之前调用SetMaxLengthOfUserID方法。而且，客户端和服务端必须采用相同的设置，否则，就一定会导致服务端和客户端通信出现异常。如果你的客户端是使用的Silverlight，那么使用ESFramework.SL时也是如此。

（1）服务端和桌面客户端请调用ESPlus.Core.StreamMessageHeader的SetMaxLengthOfUserID方法进行设置。

（2）Silverlight的客户端请调用ESFramework.SL.StreamMessageHeader的SetMaxLengthOfUserID方法进行设置。

在ESFramework内部，组ID（即上面提到的groupID）也采用与UserID相同的规则。

最后要提醒的是，在能满足项目需求的情况下，尽可能使UserID的最大长度短一点，这样可以使得消息头更加短小，从而避免浪费本不需要的带宽。尤其在高性能、巨大并发的应用中，这点就更关键了。

5.消息的最大长度

Rapid引擎内部默认设置的消息的最大长度为1M（1024*1024），并且这个长度还包含了上述消息头的长度。如果您的应用需要发的单个信息的长度超过了1M，就会被ESFramework认为是恶意的消息，ESFramework会丢弃该消息并关闭对应的连接。

我们建议：在能同样满足项目的需求下，应该尽可能地使传送的消息小，这样不仅可以节省带宽，而且还有助于提升并发的性能。如果应用中确实需要信息的长度超过1M，那么可以通过Rapid引擎暴露的内部核心引擎接口来设置所允许的最大消息长度：

（1）服务端：RapidServerEngine暴露的TcpServerEngine内核引擎，可以设置其MaxMessageSize属性的值。

（2）客户端：RapidPassiveEngine暴露的TcpPassiveEngine内核引擎，也可以设置其MaxMessageSize属性的值。