MMO中的聊天服务主要功能就是做客户端之间的聊天内容转发。但是聊天的形式有很多，例如私聊、同场景聊、队伍内聊、工会内聊、全服务器聊、甚至临 时组建房间聊。这些逻辑功能其实都是可以做在逻辑服务器上的，最多改改世界服务器，但是这样完成功能的话，不免将聊天本身的逻辑与游戏逻辑关联起来。我们 希望做得更上一层，将聊天服务本身脱离开来。但是独立聊天服务还不够，因为就算独立出来了，也有可能在实现上与具体的游戏逻辑相关联。所以，我们做了进一 步的抽象，想实现一个更为通用的聊天服务器。

设计实现

实体设计

聊天这个过程，我们将其抽象为实体(entity)与实体间的对话。这个实体概念其实很宽泛。任何可接收聊天消息的都算做实体，例如单个玩家、一个 场景、一个队伍、一个房间、一个工会、甚至整个服务器。这个思想其实就是支持整个聊天服务器设计的最根本思想。最开始，我将聊天服务器分为个体和组两个概 念，其实这个抽象程度都太低，并且会导致实现上的复杂。相反，将整个系统完全使用实体这个概念来组装，就简单很多。当然，实体是有很多种类的，在处理接收 聊天消息这个动作时，其处理方式就不同。例如单个玩家实体仅做消息的发送，场景实体则是将消息发给场景内的所有玩家，队伍实体就是将消息发给队伍内的所有 玩家。从这一点来看，我们的实体种类其实并不多，因为场景、队伍这些，都是组实体(group entity)。用C++来描述：

classEntity {public://send text to this entityvirtualboolSend(Entity*sender,conststd::string&text)=0;protected:

GUID m_id;intm_type;

};classSockEntity : pubilc Entity {public:virtualboolSend(Entity*sender,conststd::string&text) {//find the map socket and send text to the socketlongsocket=FindSocket(this);

Message msg(MSG_CS2E_SENDTEXT);

msg.Add(sender->ID());

msg.Add(text);

msg.SendToSocket(socket);returntrue;

}

};classGroupEntity :publicEntity {public:virtualboolSend(Entity*sender,conststd::string&text) {for(std::list::const_iterator it=m_mems.begin(); it!=m_mems.end();++it) {

(*it)->Send(sender, text);

}returntrue;

}private:

std::listm_mems;

};

SockEntity用于表示物理上聊天服务器的客户端，例如游戏客户端。

网络拓扑

实际上，除了转发聊天内容外(Entity::Send)，实体还有很多其他行为，例如最起码的，创建组实体，往组实体里添加成员等。在设计上，组 实体的创建由逻辑服务器或者其他服务器来完成，目前游戏客户端是没有创建组实体的权限的(实现上我们还为实体添加了权限验证机制)。在网络拓扑上，聊天服 务器始终是作为服务器角色，而它的客户端则包括游戏客户端、逻辑服务器、甚至其他服务器，这样聊天服务器在提供了固定的协议后，它就是完全独立的，不依赖 任何其他组件：

CS/|\/|\/|\

GC   GC   GS

(CS: Chat Server, GC: Game Client, GS: Game Server)

基于此，我们扩充了Entity的类体系：

classClientEntity :publicSockEntity {private:

GUID m_gsEntity;//标示该客户端实体位于哪个逻辑服务器实体上};classGSEntity :publicSockEntity {

};

消息协议

聊天服务器的核心实现，其实就是针对以上实体做操作。因此，聊天服务器的消息协议方面，也主要是针对这些实体的操作，包括：

创建

实体的创建很简单，不同的实体其创建所需的参数都不一样。例如客户端实体创建时需要传入一个逻辑服务器实体的ID，组实体的创建可以携带组成员实体列表。 为了处理权限和安全问题，在具体实现上，逻辑服务器实体的创建是由聊天服务器本地的配置决定，即聊天服务器启动则根据配置创建好逻辑服务器实体；客户端实 体是当角色进入逻辑服务器后，由服务器创建，客户端无法创建实体。

删除

实体的删除为了处理方便，约定删除请求必须由实体的创建者发起。因为从逻辑上将，某个模块如果可以创建一个实体，那么其必然知道什么时候该删除这个实体。

修改

修改指的是修改实体内部实现的一些属性，例如组实体修改其组成员。这个操作是非常重要的。对于SockEntity而 言，修改意味着修改其连接状态，例如当逻辑服务器在聊天服务器上创建了客户端实体后，实际上此时客户端并没有在网络方面连接聊天服务器，此时这个Entity实 际上是不可用的，因为它无法用于发送消息。这个时候我们标志该实体的状态为非连接状态。当客户端主动连接上聊天服务器后，客户端就主动发起修改自己对应的 客户端实体请求，该请求将自己的状态修改为连接状态。当客户端关闭时，聊天服务器网络层接收到连接断开通知，该通知肯定是早于逻辑服务器发来的删除实体通 知的，此时将该客户端实体状态修改为断开状态，并在接收到逻辑服务器删除实体通知时将其真正删除。这里展示的这种状态修改策略，实际上在整个系统中是非常 重要的。它用于指导网络连接和上层逻辑之间的关系，因为整个聊天系统中，各个进程的状态是不可预料的(随时可能宕掉)，当某个进程尤其是逻辑服务器宕掉 后，聊天服务器是得不到任何正常逻辑通知的，它只能得到网络连接的通知。

总结

整个系统实现下来，实际上是非常简单的，代码量也很少。当然还有很多细节问题，例如聊天信息中携带物品信息，这涉及到异步预处理聊天内容，这里就不 方便细说了。