多路IO复用服务器——select模型和poll模型

文章目录

  • 一、多路IO复用服务器是什么?
  • 二、使用原理
  • 三、种类
  • 四、select模型
  • 五、select模型优缺点
  • 六、poll模型
  • 总结


一、多路IO复用服务器是什么?

服务器要与客户端完成tcp连接,并保持连接维护可用sock。
每个都需要准备一个进程管一个sock,代价太大,不能让进程等待数据。
解决办法:监听sock,设置sock事件管理(sock事件:读、写、异常)
监听事件触发->事件触发->处理事件->处理完毕

二、使用原理

用一种技术来帮忙监听sock,搞一个进程使用IO复用技术监听所有可监听的sock,监听与辨别就绪(客户端还是服务端),然后处理就绪。
主要特点是recv和accept不再是阻塞,监听功能交给了IO复用,它只负责读取就可以了。
lO复用技术有名多路IO转接技术,可以帮助开发者监听大量的sock。可以单进程实现一对多。
如果此模型在读取处理请求时无法建立新连接,连接时依然无法读取数据。

三、种类

IO复用技术有很多种:select、poll、epoll。详细认识一下select模型(其他的差不多)

四、select模型

要想使用select模型,就先得建立一个监听集合。select模型的监听集合是fd_set类型,存储所有监听的sock。大小固定为1024。集合里每一位对应一个sock。服务器最开始有个serverfd的sock。
监听数量要的是maxfd+1,并且记得**+3**(监听集合对应文件描述符表:最开始应该会有0,1,2(标准输入,标注输出、标准出错))
所以要执行时时刻记录最大的描述符 maxfd。
监听集合里面设置的是0或1代表是否监听。
调用select函数,但其实它也是一个阻塞监听函数,使用的是轮询监听。参数是监听数量、监听事件选择(以集合为单位批处理),监听阻塞函数,工作模式(NULL代表阻塞监听)。返回值是int类型,就绪码。
监听集合里的是一个传入传出参数,传入代表监听谁,传出代表谁就绪了。
当监听的sock就绪,select会修改监听集合改为就绪集合传出,便于用户判断就绪的sock。将就绪sock保留为1,没就绪清0。
单进程需要一个数组存储sock。
serverfd就绪->建立tcp->将新的sock设置到监听集合中,并将它放入sock数组。
clientfd就绪->读取数据处理并响应->如果客户端断开将此sock从数组中删除,将监听取消。

监听集合(就绪集合)下一次不能再次使用。监听集合当就绪后会被修改, 所以用户要将传入和传出分离。

如果就绪的数量 >1 产生异常,因为就绪的sock存储在oset中, 用户处理完就绪后(建立连接读取完数据), 将刚刚处理完毕的sock在oset中设置0 ,避免因为oset不变导致异常判断的问题。

五、select模型优缺点

优点:

  1. 使用比较简单, 了解监听集合以及IO复用机制即可使用帮助用户完成少量sock的网络事件监听。
  2. 跨平台兼容性比较好,在各个系统语言均有select支持。
  3. select支持微妙级定时, 可以满足一些特定需求。

缺点:

  1. select无法满足大监听需求, 最大监听数1024(fd set)。
  2. 轮询监听(CPU), 虽则轮询数量的增大, O处理性能(CPU)呈线性下降。
  3. select监听到就绪后只返回就绪的数量,需要用户自行遍历查找就绪的sock。
  4. 需要用户进行传入传出分离设置。
  5. 随着select的持续使用, 会有庞大的拷贝开销与挂载开销。(select每轮使用都需要将新的监听拷贝到内核空间, 但是监听集合中大量的项以前已经拷贝过, 重复且没有意义的拷贝开销)
  6. 监听的数量比较少,其次设置监听不灵活,无法针对不同的sock设置不同的监听。

六、poll模型

几乎与select一模一样。但是使用频率远低于select模型。

优点:

  1. 监听事件的种类丰富,对监听与就绪进行了传入传出分离, 无需用户分离。
  2. poll 支持用户自定义长度结构体数组作为集合,突破了1024限制(然而没解决轮询,没啥大用)

缺点:

  1. 轮询问题,拷贝开销与挂载开销,只返回就绪数量用户自行遍历查询就绪,poll只支持毫秒级别定时。
  2. 在某些特定的Linux版本才可以使用。

总结

IO复用技术其实就是一种sock监听技术。

你可能感兴趣的:(计算机网络知识,服务器,数据库,linux,c++)