這是《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: &
