云风的 BLOG: 开发笔记 (11) : 组播服务

最近一口气招了 5 个程序员, 在他们没有到岗之前，我不想把自己过多陷入游戏实现的细节上面。所以，除了维护一些前面的代码，陆续发现和修复一些 bug 外，我计划再完善一些基础设施的设计。这些基础模块暂时可以没有，如果实现好了又可以直接加入现有系统。这样比较利于后面的工作划分。

其中之一是服务器组播的模块。

先回顾一下前面提到的服务器架构（skynet ），它可以解决各个服务节点的命名问题，以及把消息从一个节点发送到另一个节点的能力。在不改变接口协议的前提下，最简单实现组播的方法就是把一个组命名为一个节点，由这个节点负责群法消息。

其工作原理类似于 UDP 的局域网组播。我还在网易时，实现过另一个类似的服务，见这篇 blog 。这次重新在另一个系统结构上做，有稍许不同。

主要的问题在于，组的管理（加入，退出组）和组本身如何区分。

按道理，组的管理和组播本来依赖同一份数据，即组员列表。系统构架最好是实现为表里如一。也就是说，接口上看起来是怎样切分功能的，那么实际功能就怎样物理上隔离比较好。那么，组播消息和组管理，最好看起来就在一个组的节点上。

但这样，会把“组”变成一个于单点不同的对象。必须对网络框架的 API 做修改。我首先放弃了这种方案。

另一个自然的方案是，把所有组的管理放在一起，由一个具名服务来提供。任何一个节点可以向这个组管理节点发送组管理的请求。比如创建一个新的组，并且把若干节点加入这个组里。并给这个组取一个名字。以后向这个特定名字的节点发送的消息，均组播给所有组员。

这样做比较干净，对组发消息可以和对单节点发消息一致。但组管理服务器和组本身看起来是两个名字。如果遵循表里如一的原则，它们的实现也最好在两个节点上。可是用现有的 skynet 接口，它们两者之间很难通讯。

蜗牛同学说服我，组播将是一个重要的基础设施，可以做在底层，成为系统的一部分。那么脏一点也无所谓了。就是说，表面上看起来它是一个独立服务，实际上是系统的一部分。我接受这个建议，这样就不用纠结于怎么把这个东西设计的更好的问题上了。反正不改动之前的设计，额外加这么一块最不影响开发进度了。

有了这样一个基础服务，下面做场景服务、队伍 API 、聊天服务，都会简单很多。

在没有把这个基础服务在通讯框架上实现出来之前，暂时先在 lua 层的库里面做个钩子，截获这些组播相关的调用，由每个节点自行群发消息也很容易模拟出来。

现在的高手挺多的

看来云风不做GRAPHICS很多年了:-)

看不懂啊，高手就是高手

有一个开源得项目 spread也是干这个事的。 http://www.spread.org/

还是没看懂，高手写得总是那么出神入化的

可以这么说吗？本篇所描述的是一个简单的发布订阅模型？

Posted by: ychellboy | (2) February 22, 2012 11:42 AM

还没看，先墙下位置哈哈

云风的 BLOG