本文介绍用 muduo 实现一个简单的 topic-based 消息广播服务，这其实是“聊天室”的一个简单 扩展，不过聊天的不是人，而是分布式系统中的程序。
本文的代码见 http://code.google.com/p/muduo/source/browse/trunk/examples/hub
在分布式系统中，除了常用的 end-to-end 通信，还有一对多的广播通信。一提到“广播”，或许 会让人联想到 IP 多播或 IP 组播，这不是本文的主题。本文将要谈的是基于 TCP 协议的应用层广播 。示意图如下：
上图中圆角矩形代表程序，"Hub"是一个服务程序，不是网络集线器，它起到类似集线器 的作用，故而得名。Publisher 和 Subscriper 通过 TCP 协议与 Hub 程序通信。Publisher 把消息发 到某个 topic 上，Subscribers 订阅该 topic，然后就能收到消息。即 publisher 借助 hub 把消息 广播给了多个 subscribers。这种 pub/sub 结构的好处在于可以增加多个 Subscriber 而不用修改 Publisher，一定程度上实现了“解耦”（也可以看成分布式的 observer pattern）。 由于走的是 TCP 协议，广播是基本可靠的，这里的“可靠”指的是“比 UDP 可靠”，不是“完全可靠”。（思考 ：如何避免 Hub 成为 single point of failure？）
为了避免串扰（cross-talk），每个 topic 在同一时间只应该有一个 publisher，hub 不提供 compare-and-swap 操作。
（“可靠 广播、原子广播”在分布式系统中有重大意义，是以 replicated state machine 方式实现可靠的分布 式服务的基础，“可靠广播”涉及 consensus 算法，超出了本文的范围。）
应用层广播在分布 式系统中用处很大，这里略举几例：
1. 体育比分转播。有 8 片比赛场地正在进行羽毛球比赛 ，每个场地的计分程序把当前比分发送到各自的 topic 上（第 1 号场地发送到 court1，第 2 号发送 到 court2，以此类推）。需要用到比分的程序（赛场的大屏幕显示，网上比分转播等等）自己订阅感 兴趣的 topic ，就能及时收到最新比分数据。由于本文实现的不是 100% 可靠广播，那么消息应该是 snapshot，而不是 incremental。（换句话说，消息的内容是“现在是几比几”，而不是“刚才谁得分 ”。）
2. 负载监控。每台机器上运行一个监控程序，周期性地把本机当前负载（CPU、网络、 磁盘、温度）publish 到以 hostname 命名的 topic 上，这样需要用到这些数据的程序只要在 hub 订 阅相应的 topic 就能获得数据，无需与多台机器直接打交道。（为了可靠起见，监控程序发送的消息 里边应该包含时间戳，这样能防止 stale 数据，甚至一定程度上起到心跳的作用。）沿着这个思路， 分布式系统中的服务程序也可以把自己的当前负载发布到 hub 上，供 load balancer 和 monitor 取 用。
协议
为了简单起见，muduo 的 hub 示例采用以 '/r/n' 分界的文本协议 ，这样用 telnet 就能测试 hub。协议只有三个命令：