随笔-网络编程-epoll水平触发和边缘触发

对于数据读取和发送的，水平触发和边缘触发的区别：

参考：彻底搞懂epoll的LT模式和ET模式

• 关于数据的读比较好理解，无论是LT模式还是ET模式，监听到读事件从socket开始读数据就好了，只不过读的逻辑有些差异，LT模式下，读事件触发后，可以按需收取想要的字节数，不用把本次接收到的数据收取干净，ET模式下，读事件触发后通常需要数据一次性收取干净。
• 而数据的写不太容易理解，因为数据的读是对端发来数据导致的，而数据的写其实是自己的逻辑层触发的，所以在通过网络发数据时通常都不会去注册监可写事件，一般都是调用 send 或者 write 函数直接发送，如果发送过程中， 函数返回 -1，并且错误码是 EWOULDBLOCK 表明发送失败，此时才会注册监听可写事件，并将剩余的服务存入自定义的发送缓冲区中，等可写事件触发后再接着将发送缓冲区中剩余的数据发送出去。

+++

常规设计：水平触发和边缘触发选择(对于【读】设计，【写】为直接调用send write)：

关于监听fd:

参考： https://www.cnblogs.com/GanSinba/p/17539700.html

对于监听的sock，最好使用水平触发模式，边缘触发模式会导致高并发情况下，有的客户端会连接不上。如果非要使用边缘触发，网上有的方案是用while来循环accept()。

关于read数据：

使用水平触发

使用水平触发的风险是如果上层应用没有去read 数据，就会一直触发; 但是，只要底层的框架设计好收到消息都会去读消息，那么也就没有这种风险

• 前言：用户场景，报文不会太大，所以用户层的缓冲区是固定大小，超过大小的报文视为异常报文，丢弃
• 使用边缘触发，未读完数据，会影响后续的报文的读取，所以选择水平触发
• 使用水平触发的风险是如果上层应用没有去read 数据，就会一直触发; 但是，只要底层的框架设计好收到消息都会去读消息，那么也就没有这种风险
• 只需要监听READ核CLOSE时间(WRITE不用)