muduo应用层缓冲区buffer设计

一：

    muduo的I/O模型采用非阻塞模式，避免阻塞在read()或write()或其他系统调用上。

    

    TcpConnection必须要有output buffer 考虑一个常见场景：程序想通过TCP连接返送100k字节的数据，但在write()调用中，操作系统只接受了80k字节（受TCP advertised window的控制，细节见TCPv1），你肯定不想在原地等待，因为不知道会等待多久（取决于对方什么时候接收数据，然后滑动TCP窗口）。程序应该尽快交出控制权，返回eventloop。在这种情况下，剩余的20k字节数据怎么办？

    对，答案就是网络库来接管。网络库把它保存在output buffer里，然后注册POLLOUT事件，一旦socket变得可写就立刻发送给数据。当然，这第二次write()也不一定能完全写入20字节，那就继续关注POLLOUT事件。如果写完，停止关注POLLOUT，防止busy loop。（因为epoll采用level trigger）。

    如果output buffer里还有待发送的数据，而程序又想关闭连接（对程序而言，调用TcpConncetion之后就认为数据迟早会发送出去），这是不能立刻关闭连接，这就是muduo库的shutdown()没有立即关闭连接的原因。以后博客会写。

    

    TcpConnection必须要有input buffer TCP是一个无边界的字节流协议，接收方必须要处理“收到的数据尚不构成一条完整的消息”和“一次收到两条消息的数据”等等情况。一个常见的场景是，发送方send了两条10k字节的消息（共20k），接收方收到数据的情况可能是：

• 一次性收到20k数据
• 分两次收到，第一次5k，第二次15k
• 分三次收到，第一次6k，第二次8k，第三次6k
• 等等任何可能

    以上情况俗称“粘包”问题。

    

    网络库在处理“socket可读”事件的时候，必须一次性把socket中数据读完（从操作系统buffer搬到应用层buffer），否则会反复触发POLLIN事件，造成busy loop。

    如何处理？

    接收到数据，存在input buffer，通知上层的应用程序，OnMessage(buffer)回调，根据应用层协议判定是否是一个完整的包，进行codec解码，如果不是一条完整的消息，不会取走数据，也不会进行相应的处理。如果是一条完整的消息，将取走这条消息，并进行相应的处理。如何处理就是上层应用程序的职责了。

    所以，muduo库都是带缓冲的I/O，不会自己去read()或write()某个socket，只会操作TcpConnection的input buffer和output buffer。更确切的说，是在OnMessage()回调里读取input buffer；调用TcpConnection::send()来间接操作output buffer，一般不会直接操作output buffer。

    有关buffer的设计图示可以参考陈硕的博客： http://www.cppblog.com/Solstice/archive/2011/04/17/144378.html ，本文主要以程序角度来分析buffer的实现。

    

二：

首先来看一下Buffer的类成员：

class Buffer : public mud