Muduo 网络编程示例之二：Boost.Asio 的聊天服务器TCP 分包聊天服务消息格式打包的代码分包的代码编解码器 LengthHeaderCodec服务端的实现客户端的实现简单测试

陈硕 (giantchen_AT_gmail)

Blog.csdn.net/Solstice

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

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

消息长度固定，比如 muduo 的 roundtrip 示例就采用了固定的 16 字节消息；

使用特殊的字符或字符串作为消息的边界，例如 HTTP 协议的 headers 以 "\r\n" 为字段的分隔符；

在每条消息的头部加一个长度字段，这恐怕是最常见的做法，本文的聊天协议也采用这一办法；

利用消息本身的格式来分包，例如 XML 格式的消息中 <root>...</root> 的配对，或者 JSON 格式中的 { ... } 的配对。解析这种消息格式通常会用到状态机。

在后文的代码讲解中还会仔细讨论用长度字段分包的常见陷阱。

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

服务端程序中某个端口侦听 (listen) 新的连接；

客户端向服务端发起连接；

连接建立之后，客户端随时准备接收服务端的消息并在屏幕上显示出来；

客户端接受键盘输入，以回车为界，把消息发送给服务端；

服务端接收到消息之后，依次发送给每个连接到它的客户端；原来发送消息的客户端进程也会收到这条消息；

一个服务端进程可以同时服务多个客户端进程，当有消息到达服务端后，每个客户端进程都会收到同一条消息，服务端广播发送消息的顺序是任意的，不一定哪个客户端会先收到这条消息。

（可选）如果消息 A 先于消息 B 到达服务端，那么每个客户端都会先收到 A 再收到 B。

这实际上是一个简单的基于 TCP 的应用层广播协议，由服务端负责把消息发送给每个连接到它的客户端。参与“聊天”的既可以是人，也可以是程序。在以后的文章中，我将介绍一个稍微复杂的一点的例子 hub，它有“聊天室”的功能，客户端可以注册特定的 topic(s)，并往某个 topic 发送消息，这样代码更有意思。

本聊天服务的消息格式非常简单，“消息”本身是一个字符串，每条消息的有一个 4 字节的头部，以网络序存放字符串的长度。消息之间没有间隙，字符串也不一定以 '\0' 结尾。比方说有两条消息 "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 发送。

muduo::Buffer 有一个很好的功能，它在头部预留了 8 个字节的空间，这样第 6 行的 prepend() 操作就不需要移动已有的数据，效率较高。

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

上面这段代码第 7 行用了 while 循环来反复读取数据，直到 Buffer 中的数据不够一条完整的消息。请读者思考，如果换成 if (buf->readableBytes() >= kHeaderLen) 会有什么后果。

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

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

每次收到一个字节的数据，onMessage() 被调用 21 次；

数据分两次到达，第一次收到 2 个字节，不足消息的长度字段；

数据分两次到达，第一次收到 4 个字节，刚好够长度字段，但是没有 body；

数据分两次到达，第一次收到 8 个字节，长度完整，但 body 不完整；

数据分两次到达，第一次收到 9 个字节，长度完整，body 也完整；

数据分两次到达，第一次收到 10 个字节，第一条消息的长度完整、body 也完整，第二条消息长度不完整；

请自行移动分割点，验证各种情况；

数据一次就全部到达，这时必须用 while 循环来读出两条消息，否则消息会堆积。

请读者验证 onMessage() 是否做到了以上几点。这个例子充分说明了 non-blocking read 必须和 input buffer 一起使用。

这段代码把以 Buffer* 为参数的 MessageCallback 转换成了以 const string& 为参数的 StringMessageCallback，让用户代码不必关心分包操作。客户端和服务端都能从中受益。

聊天服务器的服务端代码小于 100 行，不到 asio 的一半。

请先阅读第 68 行起的数据成员的定义。除了经常见到的 EventLoop 和 TcpServer，ChatServer 还定义了 codec_ 和 std::set<TcpConnectionPtr> connections_ 作为成员，connections_ 是目前已建立的客户连接，在收到消息之后，服务器会遍历整个容器，把消息广播给其中每一个 TCP 连接。

首先，在构造函数里注册回调：

如果你读过 asio 的对应代码，会不会觉得 Reactor 往往比 Proactor 容易使用？

我有时觉得服务端的程序常常比客户端的更容易写，聊天服务器再次验证了我的看法。客户端的复杂性来自于它要读取键盘输入，而 EventLoop 是独占线程的，所以我用了两个线程，main() 函数所在的线程负责读键盘，另外用一个 EventLoopThread 来处理网络 IO。我暂时没有把标准输入输出融入 Reactor 的想法，因为服务器程序的 stdin 和 stdout 往往是重定向了的。

来看代码，首先，在构造函数里注册回调，并使用了跟前面一样的 LengthHeaderCodec 作为中间层，负责打包分包。

开三个命令行窗口，在第一个运行

$ ./asio_chat_server 3000

第二个运行

$ ./asio_chat_client 127.0.0.1 3000

第三个运行同样的命令

这样就有两个客户端进程参与聊天。在第二个窗口里输入一些字符并回车，字符会出现在本窗口和第三个窗口中。

下一篇文章我会介绍 Muduo 中的定时器，并实现 Boost.Asio 教程中的 timer2~5 示例，以及带流量统计功能的 discard 和 echo 服务器（来自 Java Netty）。流量等于单位时间内发送或接受的字节数，这要用到定时器功能。

(待续)

    本文转自 陈硕  博客园博客，原文链接：http://www.cnblogs.com/Solstice/archive/2011/02/04/1949106.html，如需转载请自行联系原作者