对于linux socket和epoll配合.docVIP

【转载】对于linux socket与epoll配合 【转载】对于linux socket与epoll配合相关的一些心得记录2010-09-05 22：59linker：int nRecvBuf=32*1024；//设置为32K setsockopt(s,SOL_SOCKET,SO_RCVBUF,(const char*)nRecvBuf,sizeof(int))； 1、通过上面语句可以简单设置缓冲区大小,测试证明：跟epoll结合的时候只有当单次发送的数据全被从缓冲区读完毕之后才会再次被触发，多次发送数据如果没有读取完毕当缓冲区未满的时候数据不会丢失，会累加到后面。 2、如果缓冲区未满，同一连接多次发送数据会多次收到EPOLLIN事件。 单次发送数据socket缓冲区大小的数据数据会被阻塞分次发送，所以循环接收可以用ENLIGE错误判断。 3、如果缓冲区满，新发送的数据不会触发epoll事件(也无异常)，每次recv都会为缓冲区腾出空间，只有当缓冲区空闲大小能够再次接收数据epollIN事件可以再次被触发 接收时接收大小为0表示客户端断开(不可能有0数据包触发EPOLLIN),-1表示异常，针对errorno进行判断可以确定是合理异常还是需要终止的异常，0而不等于缓冲区大小表示单次发送结束。 4、如果中途临时调整接收缓存区大小，并且在上一次中数据没有完全接收到用户空间，数据不会丢失，会累加在一起 所以总结起来，系统对于数据的完整性还是做了相当的保正，至于稳定性没有作更深一步的测试 新增加： 5、如果主accept监听的soctet fd也设置为非阻塞，那么单纯靠epoll事件来驱动的服务器模型会存在问题，并发压力下发现，每次accept只从系统中取得第一个，所以如果恰冯多个连接同时触发server fd的EPOLLIN事件，在返回的event数组中体现不出来，会出现丢失事件的现象，所以当用ab等工具简单的压载就会发现每次都会有最后几条信息得不到处理，原因就在于此，我现在的解决办法是将server fd的监听去掉，用一个线程阻塞监听，accept成功就处理检测client fd，然后在主线程循环监听client事件，这样epoll在边缘模式下出错的概率就小，测试表明效果明显 6、对于SIG部分信号还是要做屏蔽处理，不然对方socket中断等正常事件都会引起整个服务的退出 7、sendfile(fd,f-SL-sendBuffer.inFd,(off_t*)f-SL-sendBuffer.offset,size_need)；注意sendfile函数的地三个变量是传送地址，偏移量会自动增加，不需要手动再次增加，否则就会出现文件传送丢失现象 8、单线程epoll驱动模型误解：以前我一直认为单线程是无法处理web服务器这样的有严重网络延迟的服务，但nginx等优秀服务器都是机遇事件驱动模型，开始我在些的时候也是担心这些问题，后来测试发现，当client socket设为非阻塞模式的时候，从读取数据到解析http协议，到发送数据均在epoll的驱动下速度非常快，没有必要采用多线程，我的单核cpu(奔三)就可以达到10000page/second，这在公网上是远远无法达到的一个数字(网络延迟更为严重)，所以单线程的数据处理能力已经很高了，就不需要多线程了，所不同的是你在架构服务器的时候需要将所有阻塞的部分拆分开来，当epoll通知你可以读取的时候，实际上部分数据已经到了socket缓冲区，你所读取用的事件是将数据从内核空间拷贝到用户空间，同理，写也是一样的，所以epoll重要的地方就是将这两个延时的部分做了类似的异步处理，如果不需要处理更为复杂的业务，那单线程足以满足1000M网卡的最高要求，这才是单线程的意义。 我以前构建的web服务器就没有理解epoll，采用epoll的边缘触发之后怕事件丢失，或者单线程处理阻塞，所以自己用多线程构建了一个任务调度器，所有收到的事件统统压进任无调度器中，然后多任务处理，我还将read和write分别用两个调度器处理，并打算如果中间需要特殊的耗时的处理就增加一套调度器，用少量线程+epoll的方法来题高性能，后来发现read和write部分调度器是多余的，epoll本来就是一个事件调度器，在后面再次缓存事件分部处理还不如将epoll设为水平模式，所以多此一举，但是这个调度起还是有用处的 上面讲到如果中间有耗时的工作，比如数据库读写，外部资源请求(文件，socket)等这些操作就不能阻塞在主线程里面，所以我设计的这个任务调度器就有用了，在epoll能处理的事件驱动部分就借用epoll的，中间部分采用模块化的设计，用函数指针达到面相对象语言中的委托的作用，就可以满足不同的需要将任务(fd标识)加入调度器，让