本文讲介绍一个与 Boost.Asio 的示例代码中的聊天服务器功能类似的网络服务程序，包括客户端 与服务端的 muduo 实现。这个例子的主要目的是介绍如何处理分包，并初步涉及 Muduo 的多线程功能 。Muduo 的下载地址： http://muduo.googlecode.com/files/muduo-0.1.7-alpha.tar.gz ，SHA1 873567e43b3c2cae592101ea809b30ba730f2ee6，本文的完整代码可在线阅读
http://code.google.com/p/muduo/source/browse/trunk/examples/asio/chat/ 。
TCP 分包
前面一篇《五个简单 TCP 协议》中处理的协议没有涉及分包，在 TCP 这种字节流协议上做应用层 分包是网络编程的基本需求。分包指的是在发生一个消息(message)或一帧(frame)数据时，通过一定的 处理，让接收方能从字节流中识别并截取（还原）出一个个消息。“粘包问题”是个伪问题。
对于短连接的 TCP 服务，分包不是一个问题，只要发送方主动关闭连接，就表示一条消息发送完毕 ，接收方 read() 返回 0，从而知道消息的结尾。例如前一篇文章里的 daytime 和 time 协议。
对于长连接的 TCP 服务，分包有四种方法：
1. 消息长度固定，比如 muduo 的 roundtrip 示例就采用了固定的 16 字节消息；
2. 使用特殊的字符或字符串作为消息的边界，例如 HTTP 协议的 headers 以 "rn" 为字段的分隔 符；
3. 在每条消息的头部加一个长度字段，这恐怕是最常见的做法，本文的聊天协议也采用这一办法；
4. 利用消息本身的格式来分包，例如 XML 格式的消息中 <root>...</root> 的配对 ，或者 JSON 格式中的 { ... } 的配对。解析这种消息格式通常会用到状态机。
在后文的代码讲解中还会仔细讨论用长度字段分包的常见陷阱。
聊天服务
本文实现的聊天服务非常简单，由服务端程序和客户端程序组成，协议如下：
* 服务端程序中某个端口侦听 (listen) 新的连接；
* 客户端向服务端发起连接；
* 连接建立之后，客户端随时准备接收服务端的消息并在屏幕上显示出来；
* 客户端接受键盘输入，以回车为界，把消息发送给服务端；
* 服务端接收到消息之后，依次发送给每个连接到它的客户端；原来发送消息的客户端进程也会收 到这条消息；
* 一个服务端进程可以同时服务多个客户端进程，当有消息到达服务端后，每个客户端进程都会收 到同一条消息，服务端广播发送消息的顺序是任意的，不一定哪个客户端会先收到这条消息。
* （可选）如果消息 A 先于消息 B 到达服务端，那么每个客户端都会先收到 A 再收到 B。
这实际上是一个简单的基于 TCP 的应用层广播协议，由服务端负责把消息发送给每个连接到它的客 户端。参与“聊天”的既可以是人，也可以是程序。在以后的文章中，我将介绍一个稍微复杂的一点的 例子 hub，它有“聊天室”的功能，客户端可以注册特定的 topic(s)，并往某个 topic 发送消息，这 样代码更有意思。