http://blog.csdn.net/tianmohust/article/details/8691644 在Linux中使用非阻塞的socket的情形下. (一)发送时 当客户通过Socket提供的send函数发送大的数据包时,就可能返回一个EAGAIN的错误.该错误产生的原因是由于send 函数中的size变量大小超过了tcp_sendspace的值.tcp_sendspace定义了应用在调用send之前能够在kernel中缓存的数据量.当应用程序在socket中设置了O_NDELAY或

转自:http://blog.csdn.net/tianmohust/article/details/8691644 版权声明:本文为博主原创文章,未经博主允许不得转载. 在Linux中使用非阻塞的socket的情形下. (一)发送时 当客户通过Socket提供的send函数发送大的数据包时,就可能返回一个EAGAIN的错误.该错误产生的原因是由于send 函数中的size变量大小超过了tcp_sendspace的值.tcp_sendspace定义了应用在调用send之前能够在kernel中缓存

        在linux进行非阻塞的socket接收数据时经常出现Resource temporarily unavailable,errno代码为11(EAGAIN),这表明你在非阻塞模式下调用了阻塞操作,在该操作没有完成就返回这个错误,这个错误不会破坏socket的同步,不用管它,下次循环接着recv就可以. 对非阻塞socket而言,EAGAIN不是一种错误.在VxWorks和Windows上,EAGAIN的名字叫做EWOULDBLOCK. 另外,如果出现EINTR即errno为4,错

关于poll模型监听的事件以及返回事件,我们定义宏如下: #define kReadEvent (POLLIN | POLLPRI) #define kWriteEvent (POLLOUT | POLLWRBAND) #define kReadREvent (POLLIN | POLLPRI | POLLRDHUP) #define kWriteREvent (POLLOUT) 前面我们说明了,为什么非阻塞IO必须具备缓冲区.事实上,对于server而言,每条TCP连接应该具有两个缓冲区,一个

我们为客户端的编写再做一些工作. 这次我们使用非阻塞IO实现connect函数. int connect(int sockfd, const struct sockaddr *addr, socklen_t addrlen); 非阻塞IO有以下用处: 1.将三次握手的处理过程生下来,处理其他事情. 2.使用这个同时建立多个连接. 3.实现超时connect功能,本节实现的connect就可以指定时间,超时后算作错误处理.   在阻塞IO中,调用connect后一般会阻塞,直到确定连接成功或者失败

本文我们来实现回射服务器的Buffer.   Buffer的实现   上节提到了非阻塞IO必须具备Buffer.再次将Buffer的设计描述一下: 这里必须补充一点,writeIndex指向空闲空间的第一个位置. 这里有三个重要的不变式: 1. 0 <= readIndex <= writeIndex <= BUFFER_SIZE 2. writeIndex – readIndex 为可以从buffer读取的字节数 3. BUFFER_SIZE – writeIndex 为buffer还

当我们以非阻塞的方式来进行连接的时候,返回的结果如果是 -1,这并不代表这次连接发生了错误,如果它的返回结果是 EINPROGRESS,那么就代表连接还在进行中. 后面可以通过poll或者select来判断socket是否可写,如果可以写,说明连接完成了.

本文无太多内容,主要是几个前面提到过的注意点: 一是epoll的fd需要重新装填.我们将tcp_connection_t的指针保存在数组中,所以我们以这个数组为依据,重新装填fd的监听事件. //重新装填epoll内fd的监听事件 int i; ; i < EVENTS_SIZE; ++i) { if(connsets[i] != NULL) { int fd = i; //fd tcp_connection_t *pt = connsets[i]; //tcp conn uint32_t ;

使用poll与epoll的区别主要在于: poll可以每次重新装填fd数组,但是epoll的fd是一开始就加入了,不可能每次都重新加入 于是采用这种策略: epoll除了listenfd一开始就监听read事件,其他的客户fd加入epoll时,监听的事件都为空. 然后在每次epoll_wait之前,使用epoll_ctl重新设置fd的监听事件. 所以这部分的代码如下:   //重新装填epoll事件 sockfd_event = ; stdin_event = ; stdout_event =

前面几节我们讨论了非阻塞IO的基本概念.Buffer的设计以及非阻塞connect的实现,现在我们使用它们来完成客户端的编写. 我们在http://www.cnblogs.com/inevermore/p/4049165.html中提出过,客户端需要监听stdin.stdout和sockfd. 这里需要注意的是 只有缓冲区可写的时候,才去监听sockfd和stdin的读事件. 过去在阻塞IO中,我们总是监听sockfd的读事件,因为每当sockfd可读,我们就去调用用户的回调函数处理read事件

上文描述了最简易的非阻塞IO,采用的是轮询的方式,这节我们使用IO复用模型.   阻塞IO   过去我们使用IO复用与阻塞IO结合的时候,IO复用模型起到的作用是并发监听多个fd. 以简单的回射服务器为例,我们只监听了某fd是否可读,一旦fd有数据,我们立刻read,然后将其write给对方. 在阻塞IO里面,我们总是认为fd是可写的.因为即使底层的IO缓冲区已满,稍微等待片刻即可.这与read卡在一个无数据的fd上是两种情况.所以从这个角度出发,是不需要监听fd的写事件的. 总之,在阻塞IO中

开始准备看Java NIO的,这篇文章:http://xly1981.iteye.com/blog/1735862 里面提到了这篇文章 http://xmuzyq.iteye.com/blog/783218 同步.异步.阻塞.非阻塞.reactive.proactive等讲的不错. 在高性能的I/O设计中,有两个比较著名的模式Reactor和Proactor模式, 其中Reactor模式用于同步I/O, 而Proactor运用于异步I/O操作. 什么是同步和异步 同步和异步是针对应用程序和内核的

1.网络IO的两个阶段 waitdata copydata send 先经历:copydata阶段 recv 先经历:waitdata阶段 再经历 copydata阶段 2.阻塞的IO模型 之前写的都是阻塞 无论多线程 多进程 还是进程池 线程池 3.非阻塞IO模型 非阻塞:最直接的体现 所有和读写相关的函数 都不会阻塞 意味着 在读写的时候 并不能确定目前是否可以读写 一旦不能读写就派出异常 只能使用try except 看是否可以读写 在非阻塞io中 需要不断循环询问操作是否需要处理的数据

EAGAIN.EWOULDBLOCK.EINTR与非阻塞 长连接 EWOULDBLOCK用于非阻塞模式,不需要重新读或者写 EINTR指操作被中断唤醒,需要重新读/写 在Linux环境下开发经常会碰到很多错误(设置errno),其中EAGAIN是其中比较常见的一个错误(比如用在非阻塞操作中). 从字面上来看,是提示再试一次.这个错误经常出现在当应用程序进行一些非阻塞(non-blocking)操作(对文件或socket)的时候.例如,以 O_NONBLOCK的标志打开文件/socket/FIFO

最近在网络上看到一些帖子以及回复,同时又搜索了一些网络上关于阻塞非阻塞区别的描述,发现很多人在描述两者的发送接收时操作返回以及缓冲区处理的区别时有不同程度的误解.所以我想写一篇文章来纠正错误,并作为记录方便查阅,如有转载,注明作者(jwybobo2007)以及出处即可. 首先socket在默认情况下是阻塞状态的(未指异步操作以及其它一些特殊用途下,直接默认为非阻塞),这就使得发送以及接收操作处于阻塞的状态,即调用不会立即返回,而是进入睡眠等待操作完成.下面把讨论点分为发送以及接收.  一.发送选

[原创链接: http://www.smithfox.com/?e=191, 转载请保留此声明, 谢谢! ] I/O Model 是一个很大的话题, 也是一个实践性很强的事情, 网上有各种说法和资料, 我们必须用辩证的态度去看待(包括本Blog :) ), 因为有的信息是过时的, 有些则可能是未经实践的片面的理解. 为避免走题(走到 高并发问题 上去了), 本次讨论作了以下限制 (从另一方面讲, 也是一些思路)1. 单服务器的情况, (不考虑分布式)2. 主流硬件, (不考虑基于hardware

转自:http://blog.chinaunix.net/uid-24517549-id-4044877.html   首先socket在默认情况下是阻塞状态的,这就使得发送以及接收操作处于阻塞的状态,即调用不会立即返回,而是进入睡眠等待操作完成.   一.发送选用send(这里特指TCP)以及sendto(这里特指UDP)来描述 首先需要说明的是,不管阻塞还是非阻塞,在发送时都会将数据从应用缓冲区拷贝到内核缓冲区(SO_RCVBUF选项声明,除非缓冲区大小为0).     在阻塞模式下send

阻塞模式和非阻塞模式...... 我的理解是:阻塞模式就像是一个延时函数,当这个函数没处理完那么,所有的按照流程需要执行的代码都不会被执行,要等到这个延时完成,类似 平时看书上写的LED灯闪烁,用的delay()一样..而非阻塞模式就像他定义的那样,一般用的是中断,执行这条语句的时候,开启相应的中断达到一定的条件才进行处理,这样不会影响到流程的执行. 我的理解就是,阻塞就是死等,非阻塞就是中断 可以参考 /**  * @brief  Sends an amount of data in non

一.线程池实现阻塞IO 二.非阻塞IO模型 三.多路复用,降低CPU占用 四.模拟异步IO 一.线程池实现阻塞IO 线程阻塞IO 客户端 import socket c = socket.socket() c.connect(("127.0.0.1",9999)) while True: msg = input(">>>:") if not msg:continue c.send(msg.encode("utf-8")) dat

非阻塞IO 和阻塞IO: 在网络编程中对于一个网络句柄会遇到阻塞IO 和非阻塞IO 的概念, 这里对于这两种socket 先做一下说明:       基本概念: 阻塞IO:: socket 的阻塞模式意味着必须要做完IO 操作(包括错误)才会 返回. 非阻塞IO:: 非阻塞模式下无论操作是否完成都会立刻返回,需要通过其他方 式来判断具体操作是否成功.(对于connect,accpet操作,通过select判断, 对于recv,recvfrom,send,sendto通过返回值+错误码来判断) I