Linux IO通信模型漫谈

Linux IO通信模型漫谈

ID:37457580

大小:292.50 KB

页数:15页

时间:2019-05-24

Linux IO通信模型漫谈_第1页
Linux IO通信模型漫谈_第2页
Linux IO通信模型漫谈_第3页
Linux IO通信模型漫谈_第4页
Linux IO通信模型漫谈_第5页
资源描述:

《Linux IO通信模型漫谈》由会员上传分享,免费在线阅读,更多相关内容在行业资料-天天文库

1、互联网时代,几乎所有大型应用都或多或少与网络有关,而I/O模型又是一切网络编程的基础。本文以笔者熟悉的Unix/Linux接口为例,着重介绍了几种常用的I/O模型,希望能给各位服务器领域的同仁提供参考价值。阻塞型的网络编程接口   初学Socket编程,大家都是从 listen()、send()、recv()等接口开始的。使用这些接口可以实现一个非常简单的网络通讯程序,如下图所示。    在这个线程/时间图例中,黑色的粗线代表线程的等待时间,或者说成是被阻塞的。我们注意到accept()、send()、recv()这几个接口在调用时都发生了阻塞。实际上

2、,在缺省状态下,socket接口都是阻塞型的。这意味着当一个socket调用不能立即完成时,进程或线程将进入睡眠状态,等待操作完成。这给网络编程带来了一个很大的问题,如在调用send()的同时,线程将被阻塞,在此期间,线程将无法执行任何运算或响应任何的网络请求。这给多客户机、多业务逻辑的网络编程带来了挑战。要解决这个问题,我们自然而然的想到多线程。多线程的服务器程序   应对多客户机的网络应用,最简单的解决方式是在服务器端使用多线程(或多进程)。多线程(或多进程)的目的是让每个连接都拥有独立的线程(或进程),这样任何一个连接的阻塞都不会影响其他的连接。

3、   具体使用多进程还是多线程,并没有一个特定的模式。传统意义上,进程的开销要远远大于线程,所以,如果需要同时为较多的客户机提供服务,则不推荐使用多进程;如果单个服务执行体需要消耗较多的CPU资源,譬如需要进行大规模或长时间的数据运算或文件访问,则进程较为安全。在Unix/Linux环境中,使用pthread_create()创建新线程,fork()创建新进程。   我们假设对上述的服务器/客户机模型,提出更高的要求,即让服务器同时为多个客户机提供一问一答的服务。于是有了如下的模型。    在上述的线程/时间图例中,主线程持续等待客户端的连接请求,如果

4、有连接,则创建新线程,并在新线程中提供为前例同样的问答服务。很多初学者可能不明白为何一个socket可以accept多次。实际上,socket的设计者可能特意为多客户机的情况留下了伏笔,让accept()能够返回一个新的socket。下面是accept接口的原型:intaccept(ints,structsockaddr*addr,socklen_t*addrlen);输入参数s是从socket(),bind()和listen()中沿用下来的socket句柄值。执行完bind()和listen()后,操作系统已经开始在指定的端口处监听所有的连接请求,如

5、果有请求,则将该连接请求加入请求队列。调用accept()接口正是从sockets的请求队列抽取第一个连接信息,创建一个与s同类的新的socket返回句柄。新的socket句柄即是后续read()和recv()的输入参数。如果请求队列当前没有请求,则accept()将进入阻塞状态直到有请求进入队列。   上述多线程的服务器模型似乎完美的解决了为多个客户机提供问答服务的要求,但其实并不尽然。如果要同时响应成百上千路的连接请求,则无论多线程还是多进程都会严重占据系统资源,降低系统对外界响应效率,而线程与进程本身也更容易进入假死状态。   很多程序员可能会考

6、虑使用“线程池”或“连接池”。“线程池”旨在减少创建和销毁线程的频率,其维持一定合理数量的线程,并让空闲的线程重新承担新的执行任务。“连接池”维持连接的缓存池,尽量重用已有的连接、减少创建和关闭连接的频率。这两种技术都可以很好的降低系统开销,都被广泛应用很多大型系统,如websphere、tomcat和各种数据库等。   但是,“线程池”和“连接池”技术也只是在一定程度上缓解了频繁调用IO接口带来的资源占用。而且,所谓“池”始终有其上限,当请求大大超过上限时,“池”构成的系统对外界的响应并不比没有池的时候效果好多少。所以使用“池”必须考虑其面临的响应规

7、模,并根据响应规模调整“池”的大小。   对应上例中的所面临的可能同时出现的上千甚至上万次的客户端请求,“线程池”或“连接池”或许可以缓解部分压力,但是不能解决所有问题。   总之,多线程模型可以方便高效的解决小规模的服务请求,但面对大规模的服务请求,多线程模型并不是最佳方案。附:一个简单的多进程并发服务器demo/*==========================================================================Purpose:*Fork模型TCP并发服务器DemoNotes:*采用TCP短连接,服务

8、器将接收到从不同客户端传来的消息并打印到终端* 编译:gccfork.c-oforkAutho

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。