linux非阻塞的socket EAGAIN的错误处理【转】-阿里云开发者社区

开发者社区> 桃子红了呐> 正文

linux非阻塞的socket EAGAIN的错误处理【转】

简介:
+关注继续查看

转自:http://blog.csdn.net/tianmohust/article/details/8691644

复制代码
版权声明:本文为博主原创文章,未经博主允许不得转载。
在Linux中使用非阻塞的socket的情形下。

(一)发送时

  当客户通过Socket提供的send函数发送大的数据包时,就可能返回一个EAGAIN的错误。该错误产生的原因是由于send 函数中的size变量大小超过了tcp_sendspace的值。tcp_sendspace定义了应用在调用send之前能够在kernel中缓存的数据量。当应用程序在socket中设置了O_NDELAY或者O_NONBLOCK属性后,如果发送缓存被占满,send就会返回EAGAIN的错误。 

  为了消除该错误,有三种方法可以选择: 
  1.调大tcp_sendspace,使之大于send中的size参数 
  ---no -p -o tcp_sendspace=65536 

  2.在调用send前,在setsockopt函数中为SNDBUF设置更大的值 

  3.使用write替代send,因为write没有设置O_NDELAY或者O_NONBLOCK

(二)接收时

       接收数据时常遇到Resource temporarily unavailable的提示,errno代码为11(EAGAIN)。这表明你在非阻塞模式下调用了阻塞操作,在该操作没有完成就返回这个错误,这个错误不会破坏socket的同步,不用管它,下次循环接着recv就可以。对非阻塞socket而言,EAGAIN不是一种错误。在VxWorks和Windows上,EAGAIN的名字叫做EWOULDBLOCK。其实这算不上错误,只是一种异常而已。

  另外,如果出现EINTR即errno为4,错误描述Interrupted system call,操作也应该继续。

  最后,如果recv的返回值为0,那表明对方已将连接断开,我们的接收操作也应该结束。

(三)以下是另一种解释

假如发送端流量大于接收端的流量(意思是epoll所在的程序读比转发的socket要快),由于是非阻塞的socket,那么send()函数虽然返回,但实际缓冲区的数据并未真正发给接收端,这样不断的读和发,当缓冲区满后会产生EAGAIN错误(参考man send),同时,不理会这次请求发送的数据.所以,
        需要封装socket_send()的函数用来处理这种情况,该函数会尽量将数据写完再返回,返回-1表示出错。在socket_send()内部,当写缓冲已满(send()返回-1,且errno为EAGAIN),那么会等待后再重试.这种方式并不很完美,在理论上可能会长时间的阻塞在socket_send()内部,但暂没有更好的办法.
这种方法类似于readn和writen的封装(自己写过,在《UNIX环境高级编程》中也有介绍)

[cpp] view plain copy

    size_t socket_send(int sockfd, const char* buffer, size_t buflen)  
    {  
        size_t tmp;  
        size_t total = buflen;  
        const char *p = buffer;  
      
        while(1)  
        {  
            tmp = send(sockfd, p, total, 0);  
      
            if(tmp < 0)  
            {  
                // 当send收到信号时,可以继续写,但这里返回-1.  
                if(errno == EINTR)  
                {  
                    return -1;  
                }  
      
                // 当socket是非阻塞时,如返回此错误,表示写缓冲队列已满,  
                // 在这里做延时后再重试.  
                if(errno == EAGAIN)  
                {  
                    usleep(1000);  
                    continue;  
                }  
      
                return -1;  
            }  
      
            if((size_t)tmp == total)  
            {  
                return buflen;  
            }  
      
            total -= tmp;  
            p += tmp;  
        }  
      
        return tmp;  
    }  
       
复制代码

 





本文转自张昺华-sky博客园博客,原文链接:http://www.cnblogs.com/sky-heaven/p/7387732.html,如需转载请自行联系原作者

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
在与SQL Server建立连接时出现与网络相关的或特定于实例的错误
        向往前一样,学习牛腩新闻发布系统的视频,敲代码,打开数据库,出现一个框框,详细内容如下:                 数据库连接不上,所有的工作都要歇班,捣鼓了会儿,简单总结一下解决该问题的方法。
1236 0
从时间碎片角度理解阻塞IO模型及非阻塞模型
如何提升服务器的并发处理能力? 消灭碎片化时间,可以提升服务器的并发处理能力。 如何消灭碎片化时间? 让线程分工协作各司其职,是一个很好的手段。 原来的阻塞模型下,一个线程要干所有的事情。分工协作机制下,一部分线程专门用于接受客户端的连接、一部分专门用于获取请求的数据、一部分专门执行计算工作、还有一部分线程专门用于响应客户端。
1165 0
阻塞队列BlockingQueue用法(转)
多线程环境中,通过队列可以很容易实现数据共享,比如经典的“生产者”和“消费者”模型中,通过队列可以很便利地实现两者之间的数据共享。 假设我们有若干生产者线程,另外又有若干个消费者线程。如果生产者线程需要把准备好的数据共享给消费者线程,利用队列的方式来传递数据,就可以很方便地解决他们之间的数据共享问题。
846 0
Spring MVC 基于阻塞队列 LinkedBlockingQueue 的同步长轮询功能实现
标题 Spring MVC 基于阻塞队列 LinkedBlockingQueue 的同步长轮询功能实现,其实本文介绍的也是生产者消费者的一种实现。生产者不必是一个始终在执行的线程,它可以是一个接口,接受客户端的请求,向队列中插入消息;消费者也不必是一个始终在执行的线程,它同样也可以是一个接口,接受客户端的请求,从队列中取出属于自己的消息;看到很多介绍生产者消息者实现的文章,实现场景都很简单,现实应用往往会比较复杂,有一些附加条件,本例中就需要根据消息中的 familyId 来判断消息是不是下发给自己的。
1136 0
关于IO的同步,异步,阻塞,非阻塞
上次写了一篇文章:Unix IO 模型学习。恰巧在这次周会的时候,@fp1203 (goldendoc成员之一) 正好在讲解poll和epoll的底层实现。中途正好讨论了网络IO的同步、异步、阻塞、非阻塞的概念,当时讲下来,大家的理解各不相同,各执己见。
614 0
在与 SQL Server 建立连接时出现与网络相关的或特定于实例的错误
错误信息: 标题: 连接到服务器 ------------------------------ 无法连接到 (local)。 ------------------------------ 其他信息: 在与 SQL Server 建立连接时出现与网络相关的或特定于实例的错误。未找到或无法访问服务器。请验证实例名称是否正确并且 SQL Server 已配置为允许远程连接。 (provider
1426 0
如何处理Angular依赖注入的错误消息: NullInjectorError No provider for EffectsRootModule!
如何处理Angular依赖注入的错误消息: NullInjectorError No provider for EffectsRootModule!
8 0
4269
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
《2021云上架构与运维峰会演讲合集》
立即下载
《零基础CSS入门教程》
立即下载
《零基础HTML入门教程》
立即下载