MMO中的聊天服务主要功能就是做客户端之间的聊天内容转发。但是聊天的形式有很多，例如私聊、同场景聊、队伍内聊、工会内聊、全服务器聊、甚至临 时组建房间聊。这些逻辑功能其实都是可以做在逻辑服务器上的，最多改改世界服务器，但是这样完成功能的话，不免将聊天本身的逻辑与游戏逻辑关联起来。我们 希望做得更上一层，将聊天服务本身脱离开来。但是独立聊天服务还不够，因为就算独立出来了，也有可能在实现上与具体的游戏逻辑相关联。所以，我们做了进一 步的抽象，想实现一个更为通用的聊天服务器。
设计实现
实体设计
聊天这个过程，我们将其抽象为实体(entity)与实体间的对话。这个实体概念其实很宽泛。任何可接收聊天消息的都算做实体，例如单个玩家、一个 场景、一个队伍、一个房间、一个工会、甚至整个服务器。这个思想其实就是支持整个聊天服务器设计的最根本思想。最开始，我将聊天服务器分为个体和组两个概 念，其实这个抽象程度都太低，并且会导致实现上的复杂。相反，将整个系统完全使用实体这个概念来组装，就简单很多。当然，实体是有很多种类的，在处理接收 聊天消息这个动作时，其处理方式就不同。例如单个玩家实体仅做消息的发送，场景实体则是将消息发给场景内的所有玩家，队伍实体就是将消息发给队伍内的所有 玩家。从这一点来看，我们的实体种类其实并不多，因为场景、队伍这些，都是组实体(group entity)。用C++来描述：
class Entity {
public:
// send text to this entity
virtual bool Send(Entity *sender, const std::string &text) = 0;
protected:
GUID m_id;
int m_type;
};
class SockEntity : pubilc Entity {
public:
virtual bool Send(Entity *sender, const std::string &text) {
// find the map socket and send text to the socket
long socket = FindSocket(this);
Message msg(MSG_CS2E_SENDTEXT);
msg.Add(sender->ID());
msg.Add(text);
msg.SendToSocket(socket);
return true;
}
};
class GroupEntity : public Entity {
public:
virtual bool Send(Entity *sender, const std::string &text) {
for (std::list<Entity*>::const_iterator it = m_mems.begin(); it != m_mems.end(); ++it) {
(*it)->Send(sender, text);
}
return true;
}
private:
std::list<Entity*> m_mems;
};
SockEntity用于表示物理上聊天服务器的客户端，例如游戏客户端。
网络拓扑
实际上，除了转发聊天内容外(Entity::Send)，实体还有很多其他行为，例如最起码的，创建组实体，往组实体里添加成员等。在设计上，组 实体的创建由逻辑服务器或者其他服务器来完成，目前游戏客户端是没有创建组实体的权限的（实现上我们还为实体添加了权限验证机制）。在网络拓扑上，聊天服 务器始终是作为服务器角色，而它的客户端则包括游戏客户端、逻辑服务器、甚至其他服务器，这样聊天服务器在提供了固定的协议后，它就是完全独立的，不依赖 任何其他组件：
CS
/ | \
/ | \
/ | \
GC GC GS
(CS: Chat Server, GC: Game Client, GS: Game Server)
基于此，我们扩充了Entity的类体系：
class ClientEntity : public SockEntity {
private:
GUID m_gsEntity; // 标示该客户端实体位于哪个逻辑服务器实体上
};
class GSEntity : public SockEntity {
};
消息协议
聊天服务器的核心实现，其实就是针对以上实体做操作。因此，聊天服务器的消息协议方面，也主要是针对这些实体的操作，包括：
-
创建
实体的创建很简单，不同的实体其创建所需的参数都不一样。例如客户端实体创建时需要传入一个逻辑服务器实体的ID，组实体的创建可以携带组成员实体列表。 为了处理权限和安全问题，在具体实现上，逻辑服务器实体的创建是由聊天服务器本地的配置决定，即聊天服务器启动则根据配置创建好逻辑服务器实体；客户端实 体是当角色进入逻辑服务器后，由服务器创建，客户端无法创建实体。
-
删除
实体的删除为了处理方便，约定删除请求必须由实体的创建者发起。因为从逻辑上将，某个模块如果可以创建一个实体，那么其必然知道什么时候该删除这个实体。
-
修改
修改指的是修改实体内部实现的一些属性，例如组实体修改其组成员。这个操作是非常重要的。对于SockEntity而 言，修改意味着修改其连接状态，例如当逻辑服务器在聊天服务器上创建了客户端实体后，实际上此时客户端并没有在网络方面连接聊天服务器，此时这个Entity实 际上是不可用的，因为它无法用于发送消息。这个时候我们标志该实体的状态为非连接状态。当客户端主动连接上聊天服务器后，客户端就主动发起修改自己对应的 客户端实体请求，该请求将自己的状态修改为连接状态。当客户端关闭时，聊天服务器网络层接收到连接断开通知，该通知肯定是早于逻辑服务器发来的删除实体通 知的，此时将该客户端实体状态修改为断开状态，并在接收到逻辑服务器删除实体通知时将其真正删除。这里展示的这种状态修改策略，实际上在整个系统中是非常 重要的。它用于指导网络连接和上层逻辑之间的关系，因为整个聊天系统中，各个进程的状态是不可预料的（随时可能宕掉），当某个进程尤其是逻辑服务器宕掉 后，聊天服务器是得不到任何正常逻辑通知的，它只能得到网络连接的通知。
总结
整个系统实现下来，实际上是非常简单的，代码量也很少。当然还有很多细节问题，例如聊天信息中携带物品信息，这涉及到异步预处理聊天内容，这里就不 方便细说了。
原文地址： http://codemacro.com/2012/08/29/mmo-chat-server/
written by Kevin Lynx posted at http://codemacro.com