muduo网络库－－功能架构总结

Muduo的事件循环／线程池／客户端／服务端／Io复用总结：

(1). 一个EventLoop的loop独占一个线程，EventLoop本身构成了此线程执行的语境．
(2). 利用EventLoop内的epoll描述符，事件循环可以对一个或多个描述符进行监听．
监听的事件可以指定，事件循环还支持任务回调．其他可访问到EventLoop的线程，可向其任务回调写入回调来提交任务．
(3). 每个描述符提供给epoll监听时允许绑定一个自定义数据，Muduo里每个描述符绑定一个指向Channel对象的指针，此Channel对象构成了每个描述符的语境．通过Channel语境可以提供描述符：当前与epoll的关系／要监听的事件／产生的事件／事件回调／．．．．
(4). 一个TcpClient代表一个客户端，提供的接口connect/disconnect/stop允许触发，套接字创建／连接请求发起／连接关闭／．．．．
(5). Muduo的事件循环既监听多个描述符，在事件发生时触发事件回调，又支持任务回调．
这样要求事件循环监听的每个描述符／处理的每个任务回调，必须在一个短的时间内完成事件处理／任务回调，这样才能保证高响应性．
防止阻塞于一个处理，导致后续处理，延迟较大才响应情况．为此，监听的描述符需要是非阻塞描述符，处理的任务回调需要是可以是快速处理完毕的任务回调．
(6). 非阻塞客户端流程：
a. 创建套接字+发起连接请求
b. 创建套接字语境Channel+事件循环监听套接字可读
c. 处理可读事件，处理结果是产生一个TcpConnecton对象代表一个已经连接套接字的语境
d. 已经连接套接字，需要有其Channel语境+事件循环监听套接字可读
对套接字可读的监听，在连接建立期间一直如此．仅在有要写到套接字的内容存储于缓冲区时，才需要监听其可写．
且在可写事件中，写入缓冲区数据后，若无数据等待写入，则关闭对其可写监视．
e. 连接关闭
收到对端的FIN，会触发读事件．读事件处理中，读0字节表示收到对端FIN，可关闭连接．
执行清理－－删除在epoll中对此描述符监视／回收套接字的语境Channel．

(7).非阻塞服务端流程：
a. 创建套接字+开始监听
b. 创建监听套接字语境Channel+事件循环监听套接字可读
c. 处理可读事件，处理结果是产生一个TcpConnection对象代表一个已经连接套接字语境
d. 已经连接套接字，需要有其Channel语境+事件循环监听套接字可读
对套接字可读的监听，在连接建立期间一直如此．仅在有要写到套接字的内容存储于缓冲区时，才需要监听其可写．且在可写事件中，写入缓冲区数据后，若无数据等待写入，则关闭对其可写监视．
e. 连接关闭
收到对端的FIN，会触发读事件．读事件处理中，读0字节表示收到对端FIN，可关闭连接．
执行清理－－删除在epoll中对此描述符监视／回收套接字的语境Channel．
服务器对象可以保存所有存在的已经连接套接字及其他信息，实现管理．
(8). 服务端的多线程模型
监听套接字依附的事件循环所在的线程，负责监听
服务器通过接口启动多个并行线程－－即线程池
监听套接字可读处理时，产生的每个已经连接套接字按负载均衡方式分配到线程池中线程
(9). 已经连接套接字的应用层缓冲区
每个已经连接套接字在应用层分别有一个发送缓冲区和接收缓冲区
a. 发送缓冲区用在要向套接字写入内容，但套接字目前不可写，无法完成写入时，这时，由于用了非阻塞套接字，让写入请求以轮询来等待是低效的．Muduo的处理时，把无法立即写入的写入到发送缓冲区．并开启对套接字可写的监听，在可写事件处理中，进行发送缓冲区内容写入．
若发送缓冲区在可写事件处理中全部写入了，关闭对套接字可写监听．（要不然，会出现，没数据可写，而可写事件持续被触发情形）
b. 接收缓冲区无条件用在套接字可读事件处理中，由于TCP是字节流的，每次可读，读出的是无法保证的一定数量的字节流，要向使用者提交读到的内容时，要保证必须读到完整的一条消息时才通知使用者．
所以需要将信息先存储到接收缓冲区，再判断接收缓存区是否存在一条完整信息．存在一条完整信息时，从接收缓冲区取出此信息，执行接收消息回调．

对于接收到的每条完整信息，实际使用时，客户端／服务端还会先指定一个应用层协议．双方依据协议来解释消息，确定消息边界．

事件处理＋非阻塞I/O下编程模式

一个完整的任务被拆分成多个事件
对每个事件处理时，可能需要结合语境信息作出相关处理，然后，视情况决定是否触发下一阶段的事件监听