muduo库chat server对TCP粘包问题的处理

粘包问题的最本质原因在与接收对等方无法分辨消息与消息之间的边界在哪。我们通过使用某种方案给出边界，例如：

发送定长包。如果每个消息的大小都是一样的，那么在接收对等方只要累计接收数据，直到数据等于一个定长的数值就将它作为一个消息。
包尾加上\r\n标记。FTP协议正是这么做的。但问题在于如果数据正文中也含有\r\n，则会误判为消息的边界。
包头加上包体长度。包头是定长的4个字节，说明了包体的长度。接收对等方先接收包体长度，依据包体长度来接收包体。
使用更加复杂的应用层协议。

muduo库采用的是第三种方案，包头存放包体长度。

实现比较简单，直接上代码：

//在该函数中解析消息，是ChatServer首先调用的函数，通过定长包的形式解决了TCP的粘包问题
void onMessage(const muduo::net::TcpConnectionPtr& conn,
muduo::net::Buffer* buf,
muduo::Timestamp receiveTime)
{
while (buf->readableBytes() >= kHeaderLen) // kHeaderLen == 4 //判断是否超过包头，如果包头都超不过，那半个消息都算不上
{
// FIXME: use Buffer::peekInt32()
const void* data = buf->peek();  //偷看一下readable的当前首地址
int32_t be32 = *static_cast<const int32_t*>(data); // SIGBUS   //转化成32位
const int32_t len = muduo::net::sockets::networkToHost32(be32);  //转换成主机字节序
if (len > 65536 || len < 0)  //如果消息超过64K，或者长度小于0，不合法，干掉它。
{
LOG_ERROR << "Invalid length " << len;
conn->shutdown();  // FIXME: disable reading
break;
}
else if (buf->readableBytes() >= len + kHeaderLen)  //如果缓冲区可读的数据是否>=len+head，说明是一条完整的消息，取走
{                                                //len是头部规定的体部长度
buf->retrieve(kHeaderLen);  //取头部
muduo::string message(buf->peek(), len);  //取包体
messageCallback_(conn, message, receiveTime);   //取出包体后就可以处理回调了
buf->retrieve(len);  //然后把字节取走
}
else   //未达到一条完整的消息
{
break;
}
}
}