[11]Linux网络编程模型

最新推荐文章于 2024-10-19 20:58:11 发布

zimengyu2020

最新推荐文章于 2024-10-19 20:58:11 发布

阅读量238

点赞数

分类专栏：嵌入式Linux应用开发文章标签：网络编程 linux

嵌入式Linux应用开发专栏收录该内容

11 篇文章 0 订阅

订阅专栏

[1]多进程并发模型

bind(srvfd);
listen(srvfd);
for(;;){
    clifd=accept(srvfd,...);//开始接受客户端来的连接
    ret=fork();
    switch(ret)
    {
      case-1:
        do_err_handler();
        break;
      case0  :  // 子进程
        client_handler(clifd);
        break;
      default:  // 父进程
        close(clifd);
        continue;
    }
}
//======================================================
void client_handler(clifd){
    read(clifd,buf,...);      //从客户端读取数据
    dosomthingonbuf(buf);  
    write(clifd,buf)          //发送数据到客户端
}

上述程序在accept系统调用时，如果没有客户端来建立连接，则会阻塞在accept处。一旦某个客户端连接建立起来，则立即开启一个新的进程来处理与这个客户的数据交互。避免程序阻塞在read调用，而影响其他客户端的连接。

[2]多线程并发模型

在多进程并发模型中，每一个客户端连接开启fork一个进程，虽然Linux中引入了写实拷贝机制，大大降低了fork一个子进程的消耗，但若客户端连接较大，则系统依然将不堪负重。通过多线程(或线程池)并发模型，可以在一定程度上改善这一问题。
在服务端的线程模型实现方式一般有三种：
（1）按需生成(来一个连接生成一个线程)
（2）线程池(预先生成很多线程)
（3）Leader follower（LF）

void *thread_callback( void *args ) //线程回调函数
{
        int clifd = *(int *)args ;
        client_handler(clifd);
}
//===============================================================
void client_handler(clifd){
    read(clifd,buf,...);       //从客户端读取数据
    dosomthingonbuf(buf);  
    write(clifd,buf)          //发送数据到客户端
}
//===============================================================
bind(srvfd);
listen(srvfd);
for(;;){
    clifd = accept();
    pthread_create(...,thread_callback,&clifd);
}

服务端分为主线程和工作线程，主线程负责accept()连接，而工作线程负责处理业务逻辑和流的读取等。因此，即使在工作线程阻塞的情况下，也只是阻塞在线程范围内，对继续接受新的客户端连接不会有影响。
第二种实现方式，通过线程池的引入可以避免频繁的创建、销毁线程，能在很大程序上提升性能。但不管如何实现，多线程模型先天具有如下缺点：
1）稳定性相对较差。一个线程的崩溃会导致整个程序崩溃。
2）临界资源的访问控制，在加大程序复杂性的同时，锁机制的引入会是严重降低程序的性能。性能上可能会出现“辛辛苦苦好几年，一夜回到解放前”的情况。

[3]IO多路复用模型（select/poll）

多进程模型和多线程(线程池)模型每个进程/线程只能处理一路IO，在服务器并发数较高的情况下，过多的进程/线程会使得服务器性能下降。而通过多路IO复用，能使得一个进程同时处理多路IO，提升服务器吞吐量。
在Linux支持epoll模型之前，都使用select/poll模型来实现IO多路复用。以select为例，其核心代码如下：

bind(listenfd);
listen(listenfd);
FD_ZERO(&allset);
FD_SET(listenfd,&allset);
for(;;){
    select(...);
    if(FD_ISSET(listenfd,&rset)){    /*有新的客户端连接到来*/
        clifd=accept();
        cliarray[]=clifd;      /*保存新的连接套接字*/
        FD_SET(clifd,&allset);  /*将新的描述符加入监听数组中*/
    }
    for(;;){    /*这个for循环用来检查所有已经连接的客户端是否由数据可读写*/
        fd=cliarray[i];
        if(FD_ISSET(fd,&rset))
            dosomething();
    }
}

select IO多路复用同样存在一些缺点，罗列如下：
单个进程能够监视的文件描述符的数量存在最大限制，通常是1024，当然可以更改数量，但由于select采用轮询的方式扫描文件描述符，文件描述符数量越多，性能越差；(在linux内核头文件中，有这样的定义：#define __FD_SETSIZE 1024)
内核 / 用户空间内存拷贝问题，select需要复制大量的句柄数据结构，产生巨大的开销；
select返回的是含有整个句柄的数组，应用程序需要遍历整个数组才能发现哪些句柄发生了事件；
select的触发方式是水平触发，应用程序如果没有完成对一个已经就绪的文件描述符进行IO操作，那么之后每次select调用还是会将这些文件描述符通知进程。
相比select模型，poll使用链表保存文件描述符，因此没有了监视文件数量的限制，但其他三个缺点依然存在。
拿select模型为例，假设我们的服务器需要支持100万的并发连接，则在__FD_SETSIZE 为1024的情况下，则我们至少需要开辟1k个进程才能实现100万的并发连接。除了进程间上下文切换的时间消耗外，从内核/用户空间大量的无脑内存拷贝、数组轮询等，是系统难以承受的。因此，基于select模型的服务器程序，要达到10万级别的并发访问，是一个很难完成的任务。

select

select()用来等待文件描述符状态的改变。

int select(int maxfd, fd_set *readfds, fd_set *writefds, fe_set
*exceptfds, const struct timeval *timeout)

maxfd:文件描述符的范围，比待检的最大文件描述符大1。
readfds:被读监控的文件描述符集，调用后返回异常文件描述符数组。
writefds:被写监控的文件描述符集，调用后返回异常文件描述符数组。
exceptfds:被异常监控的文件描述符集，调用后返回异常文件描述符数组。
timeout:超时时间，为0立即返回，为NULL一直阻塞，正整数等待超时时间。
返回值:
1. 正常情况下返回满足要求的文件描述符个数；
2. 经过了timeout等待后仍无文件满足要求，返回值为0；
3. 如果select被某个信号中断，它将返回-1并设置errno为EINTR；
4. 如果出错，返回-1并设置相应的errno。

文件描述符集操作

#include <sys/select.h>
int FD_ISSET(int fd,fd_set *set);   //用来测试描述词组set中相关fd的位是否为真；如果为真返回非零值，否则返回0。
void FD_CLR(int fd,fd_set *set);    //用来清除描述词组set中相关fd的位；
void FD_SET(int fd,fd_set *set);    //用来设置描述词组set中相关fd的位；
void FD_ZERO(fd_set *set);          //用来清除描述词组set的全部位。