Muduo网络编程示例之二：Boost.Asio 的聊天服务器

这是《Muduo 网络编程示例》系列的第二篇文章。

TCP 分包
前面一篇《html">五个简单 TCP 协议》中处理的协议没有涉及分包，在 TCP 这种字节流协议上做应用层分包是网络编程的基本需求。分包指的是在发生一个消息(message)或一帧(frame)数据时，通过一定的处理，让接收方能从字节流中识别并截取（还原）出一个个消息。“粘包问题”是个伪问题。

对于短连接的 TCP 服务，分包不是一个问题，只要发送方主动关闭连接，就表示一条消息发送完毕，接收方 read() 返回 0，从而知道消息的结尾。例如前一篇文章里的 daytime 和 time 协议。

对于长连接的 TCP 服务，分包有四种方法：

消息长度固定，比如 muduo 的 roundtrip 示例就采用了固定的 16 字节消息；
使用特殊的字符或字符串作为消息的边界，例如 HTTP 协议的 headers 以 " " 为字段的分隔符；
在每条消息的头部加一个长度字段，这恐怕是最常见的做法，本文的聊天协议也采用这一办法；
利用消息本身的格式来分包，例如 XML 格式的消息中 ... 的配对，或者 JSON 格式中的 { ... } 的配对。解析这种消息格式通常会用到状态机。
在后文的代码讲解中还会仔细讨论用长度字段分包的常见陷阱。

聊天服务
本文实现的聊天服务非常简单，由服务端程序和客户端程序组成，协议如下：

服务端程序中某个端口侦听 (listen) 新的连接；
客户端向服务端发起连接；
连接建立之后，客户端随时准备接收服务端的消息并在屏幕上显示出来；
客户端接受键盘输入，以回车为界，把消息发送给服务端；
服务端接收到消息之后，依次发送给每个连接到它的客户端；原来发送消息的客户端进程也会收到这条消息；
一个服务端进程可以同时服务多个客户端进程，当有消息到达服务端后，每个客户端进程都会收到同一条消息，服务端广播发送消息的顺序是任意的，不一定哪个客户端会先收到这条消息。
（可选）如果消息 A 先于消息 B 到达服务端，那么每个客户端都会先收到 A 再收到 B。
这实际上是一个简单的基于 TCP 的应用层广播协议，由服务端负责把消息发送给每个连接到它的客户端。参与“聊天”的既可以是人，也可以是程序。在以后的文章中，我将介绍一个稍微复杂的一点的例子 hub，它有“聊天室”的功能，客户端可以注册特定的 topic(s)，并往某个 topic 发送消息，这样代码更有意思。

消息格式
本聊天服务的消息格式非常简单，“消息”本身是一个字符串，每条消息的有一个 4 字节的头部，以网络序存放字符串的长度。消息之间没有间隙，字符串也不一定以结尾。比方说有两条消息 "hello" 和 "chenshuo"，那么打包后的字节流是：

0x00, 0x00, 0x00, 0x05, h, e, l, l, o, 0x00, 0x00, 0x00, 0x08, c, h, e, n, s, h, u, o

共 21 字节。

打包的代码
这段代码把 const string& message 打包为 muduo::net::Buffer，并通过 conn 发送。

1: void send(muduo::net::TcpConnection* conn, const string& message) 2: { 3: muduo::net::Buffer buf; 4: buf.append(message.data(), message.size()); 5: int32_t len = muduo::net::sockets::hostToNetwork32(static_cast(message.size())); 6: buf.prepend(&len, sizeof len); 7: conn->send(&buf); 8: }muduo::Buffer 有一个很好的功能，它在头部预留了 8 个字节的空间，这样第 6 行的 prepend() 操作就不需要移动已有的数据，效率较高。

分包的代码
解析数据往往比生成数据复杂，分包打包也不例外。

1: void onMessage(const muduo::net::TcpConnectionPtr& conn, 2: muduo::net::Buffer* buf, 3: muduo::Timestamp receiveTime) 4: { 5: while (buf->readableBytes() >= kHeaderLen) 6: { 7: const void* data = buf->peek(); 8: int32_t tmp = *static_cast<const int32_t*>(data); 9: int32_t len = muduo::net::sockets::networkToHost32(tmp); 10: if (len > 65536 || len < 0) 11: { 12: LOG_ERROR << "Invalid length " << len; 13: conn->shutdown(); 14: } 15: else if (buf->readableBytes() >= len + kHeaderLen) 16: { 17: buf->retrieve(kHeaderLen); 18: muduo::string message(buf->peek(), len); 19: buf->retrieve(len); 20: messageCallback_(conn, message, receiveTime); // 收到完整的消息，通知用户 21: } 22: else 23: { 24: break; 25: } 26: } 27: }上面这段代码第 7 行用了 while 循环来反复读取数据，直到 Buffer 中的数据不够一条完整的消息。请读者思考，如果换成 if (buf->readableBytes() >= kHeaderLen) 会有什么后果。

以前面提到的两条消息的字节流为例：

0x00, 0x00, 0x00, 0x05, h, e, l, l, o, 0x00, 0x00, 0x00, 0x08, c, h, e, n, s, h, u, o

假设数据最终都全部到达，onMessage() 至少要能正确处理以下各种数据到达的次序，每种情况下 messageCallback_ 都应该被调用两次：

每次收到一个字节的数据，onMessage() 被调用 21 次；
数据分两次到达，第一次收到 2 个字节，不足消息的长度字段；
数据分两次到达，第一次收到 4 个字节，刚好够长度字段，但是没有 body；
数据分两次到达，第一次收到 8 个字节，长度完整，但 body 不完整；
数据分两次到达，第一次收到 9 个字节，长度完整，body 也完整；
数据分两次到达，第一次收到 10 个字节，第一条消息的长度完整、body 也完整，第二条消息长度不完整；
请自行移动分割点，验证各种情况；
数据一次就全部到达，这时必须用 while 循环来读出两条消息，否则消息会堆积。
请读者验证 onMessage() 是否做到了以上几点。这个例子充分说明了 non-blocking read 必须和 input buffer 一起使用。

编解码器 LengthHeaderCodec

有人评论 Muduo 的接收缓冲区不能设置回调函数的触发条件，确实如此。每当 socket 可读，Muduo 的 TcpConnection 会读取数据并存入 Input Buffer，然后回调用户的函数。不过，一个简单的间接层就能解决问题，让用户代码只关心“消息到达”而不是“数据到达”，如本例中的 LengthHeaderCodec 所展示的那一样。

1: #ifndef MUDUO_EXAMPLES_ASIO_CHAT_CODEC_H 2: #define MUDUO_EXAMPLES_ASIO_CHAT_CODEC_H 3: 4: #include 5: #include 6: #include 7: #include 8: 9: #include 10: #include 11: 12: using muduo::Logger; 13: 14: class LengthHeaderCodec : boost::noncopyable 15: { 16: public: 17: typedef boost::function<void (const muduo::net::TcpConnectionPtr&, 18: const muduo::string& message, 19: muduo::Timestamp)> StringMessageCallback; 20: 21: explicit LengthHeaderCodec(const StringMessageCallback& cb) 22: : messageCallback_(cb) 23: { 24: } 25: 26: void onMessage(const muduo::net::TcpConnectionPtr& conn, 27: &

补充：软件开发 , C语言 ,