Windows用以下方法将socket设置为非阻塞方式 : unsigned long ul=1; SOCKET s=socket(AF_INET,SOCK_STREAM,0); int ret=ioctlsocket(s, FIONBIO, (unsigned long *)&ul);//设置成非阻塞模式. if(ret==SOCKET_ERROR)//设置失败. { } Linux用以下方法将socket设置为非阻塞方式  int flags = fcntl(socket, F_GETFL,

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

文章出自:http://blog.csdn.net/VCSockets/ 1.TCP中的阻塞Socket和非阻塞Socket 阻塞与非阻塞是对一个文件描述符指定的文件或设备的两种工作方式. 阻塞的意思是指,当试图对该文件描述符进行读写时,如果当时没有东西可读或者暂时不可写,程序就进入等待状态,直到有东西可读或者可写为止. 非阻塞的意思是,当没有东西可读或者不可写时,读写函数就马上返回,而不会等待. !!!阻塞模式 在阻塞模式的套接字上,调用任何一个Windows Sockets API都会耗费不

阻塞socket --阻塞调用是指调用结果返回之前,当前线程会被挂起.函数只有在得到结果之后才会返回. --对于文件操作 read,fread函数调用会将线程阻塞(平常使用read感觉不出来阻塞, 因为以前的程序read都是从本机上读取数据,所以速度很快,无法感觉出来,但是从网络上读取就会有阻塞现象). --对于socket来讲,accept与recv.recvfrom函数调用会将线程阻塞. --为了避免整个进程被阻塞后挂起,所以在阻塞模式下,往往需要采用多线程技术. --一个进程中可并发的线程

阻塞IO与非阻塞IO 通常情况下的Socket都是阻塞式的, 程序的输入输出都会让当前线程进入阻塞状态, 因此服务器需要为每一个客户端都创建一个线程. 从JAVA1.4开始引入了NIO API, NIO可以实现非阻塞IO, 这样就可以使用一个线程处理所有的客户请求. 基于NIO的非阻塞Socket通信 服务器将用来监听客户端请求的channel注册到selector上,启动一个线程,使用selector的select()获取求情的客户端的channel数量, 当监听到有客户端请求时,就通过Sel

读操作 对于阻塞的socket,当socket的接收缓冲区中没有数据时,read调用会一直阻塞住,直到有数据到来才返 回.当socket缓冲区中的数据量小于期望读取的数据量时,返回实际读取的字节数.当sockt的接收缓冲 区中的数据大于期望读取的字节数时,读取期望读取的字节数,返回实际读取的长度. 对于非阻塞socket而言,socket的接收缓冲区中有没有数据,read调用都会立刻返回.接收缓冲区中有数据时,与阻塞socket有数据的情况是一样的,如果接收缓冲区中没有数据,则返回错误号为 EW

读操作 对于阻塞的socket,当socket的接收缓冲区中没有数据时,read调用会一直阻塞住,直到有数据到来才返回.当socket缓冲区中的数据量小于期望读取的数据量时,返回实际读取的字节数.当sockt的接收缓冲区中的数据大于期望读取的字节数时,读取期望读取的字节数,返回实际读取的长度. 对于非阻塞socket而言,socket的接收缓冲区中有没有数据,read调用都会立刻返回.接收缓冲区中有数据时,与阻塞socket有数据的情况是一样的,如果接收缓冲区中没有数据,则返回错误号为 EWOU

一.前言 最近在做Matalb/Simulink与C/C++的混合编程,主要是完成TCP.UDP.SerialPort等常见通信方式的中间件设计,为Simulink模型提供数据采集及解析模块. 问题在于没有搞清楚Simulink中调用C/C++的内在机制,将测试OK的C++程序移植到mex上时,总会出现很多问题,比如通信的阻塞与非阻塞,有时候自己写半天可能在性能上并不比Matalb内置模块好,所以搞清楚一些原理性的东西还是很有必要的. 参考资料: 1. 阻塞与非阻塞socket的优缺点 http

阻塞socket. –阻塞调用是指调用结果返回之前,当前线程会被挂起.函数只有在得到结果之后才会返回. –对于文件操作read,fread函数调用会将线程阻塞. –对于socket,accept与recv.recvfrom函数调用会将线程阻塞. –为了避免整个进程被阻塞后挂起,所以在阻塞模式下,往往需要采用多线程技术. –一个进程中可并发的线程总数是有限的,在处理大量客户端sokcet连接(比如上万个client socket),通过线程并发处理socket并不方便,效率也不高.   非阻塞so

阻塞socket和非阻塞socket 建立连接阻塞方式下,connect首先发送SYN请求道服务器,当客户端收到服务器返回的SYN的确认时,则connect返回.否则的话一直阻塞.非阻塞方式,connect将启用TCP协议的三次握手,但是connect函数并不等待连接建立好才返回,而是立即返回.返回的错误码为EINPROGRESS,表示正在进行某种过程. 接收连接对于阻塞方式的倾听socket,accept在连接队列中没有建立好的连接时将阻塞,直到有可用的连接,才返回.非阻塞倾听socket,在

转自http://www.cnblogs.com/yuxingfirst/archive/2013/03/08/2950281.html 我们知道,linux下socket编程有常见的几个系统调用: 对于服务器来说, 有socket(), bind(),listen(), accept(),read(),write() 对于客户端来说,有socket(),connect() 这里主要要讲的是客户端这边的connect函数. 对于客户端来说,需要打开一个套接字,然后与对端服务器连接,例如: int

server #include <stdio.h> #include <winsock2.h> #include <iostream> #pragma comment(lib, "WS2_32.lib") #define PORT 9999 #define DATA_BUFSIZE 8192 typedef struct _SOCKET_INFORMATION{ CHAR Buffer[DATA_BUFSIZE]; //发送和接收数据的缓冲区 WSA

 SOCKET cClient;     cClient=socket(AF_INET,SOCK_STREAM,0);     //设置为非阻塞套接字     int iMode = 1;     ioctlsocket(cClient, FIONBIO, (u_long FAR*)&iMode);     //定义服务端     SOCKADDR_IN saddr;     saddr.sin_addr.S_un.S_addr=inet_addr(CMT->iplist[i]);    

推荐阅读IBM developerWorks中NIO的入门教程,尤其是对块I/O和流I/O不太清楚的开发者. 说到socket服务器,第一反应是java.net.Socket这个类.事实上在并发和响应时间要求不高的场合,是可以用java.net.Socket来实现的,比如写一个局域网聊天工具.发送文件等.但它的缺点也很明显,需要自行对接受的线程进行维护,管理缓冲区的分配等,我尝试过用java.net.Socket完成一个瞬时负载在千人左右的服务器,却因后期改动和维护异常麻烦而放弃. Java自1

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

转自:http://wenku.baidu.com/link?url=V-TghOmERC0eq0aoXEyhpTw3W5OlqbItwTJE_csI29ysi9vKkCG1lDxq0wWdpImvg3qFf1BKUrDEPUz-4uCbiROduS0EswpvmBvuzVfbtuO NIO 设计背后的基石:反应器模式,用于事件多路分离和分派的体系结构模式. 反应器(Reactor):用于事件多路分离和分派的体系结构模式 通常的,对一个文件描述符指定的文件或设备, 有两种工作方式: 阻塞与非阻塞

在上一篇文章 <socket编程——一个简单的例子> http://blog.csdn.net/wind19/archive/2011/01/21/6156339.aspx 中写了一个简单的tcp socket通信程序,可以进行数据的交互,但有一个问题是这个程序是阻塞的,任何socket函数都要等返回后才能进行下一步动作,如果recv一直没有数据,那么就一直不会返回,整个进程就阻塞在那.所以我们要进行改造一下,让程序不再阻塞在那,而是在有数据到来的时候读一下数据,有数据要写的时候发送一下数据.

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

服务器 package com.java.xiong.Net17; import java.io.IOException; import java.net.InetSocketAddress; import java.nio.ByteBuffer; import java.nio.channels.Channel; import java.nio.channels.SelectionKey; import java.nio.channels.Selector; import java.nio.c

read返回值 >0   读取数据的长度 =0   接收到对端发送的FIN,表示对端的写端关闭. <0   如果errno=EINTR.收到信号并从信号处理函数返回时,慢系统调用会返回并设置errno为EINTR,应该重新调用read.  如果errno=EAGAIN.表示当前暂时没有数据可读,应该稍后读取. 其它一般表示出错. write返回值 >0   接收数据的长度 <0   如果errno=EINTR.收到信号并从信号处理函数返回时,慢系统调用会返回并设置errno为EIN

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