zl程序教程

您现在的位置是:首页 >  后端

当前栏目

怎样通过MSG_WAITALL设置阻塞时间,IO模式精细讲解: MSG_DONTWAIT 、 MSG_WAITALL

模式IO 设置 时间 通过 怎样 讲解 msg
2023-09-27 14:29:30 时间
if(::setsockopt(cClient,SOL_SOCKET,SO_SNDTIMEO,(char *) TimeOut,sizeof(TimeOut))==SOCKET_ERROR){
if(::setsockopt(cClient,SOL_SOCKET,SO_RCVTIMEO,(char *) TimeOut,sizeof(TimeOut))==SOCKET_ERROR){

非阻塞IO::

非阻塞模式下无论操作是否完成都会立刻返回,需要通过其他方式来判断具体操作是否成功。

 

IO模式设置:
一般对于一个socket 是阻塞模式还是非阻塞模式有两种方式::

 方法1、fcntl 设置;

方法2、recv,send 系列的参数。(读取,发送时,临时将sockfd或filefd设置为非阻塞)

 

方法一、fcntl 函数可以将一个socket 句柄设置成非阻塞模式:
flags = fcntl(sockfd, F_GETFL, 0); //获取文件的flags值。

 fcntl(sockfd, F_SETFL, flags | O_NONBLOCK); //设置成非阻塞模式;

flags = fcntl(sockfd,F_GETFL,0);

fcntl(sockfd,F_SETFL,flags ~O_NUNBLOCK); //设置成阻塞模式;

设置之后每次的对于sockfd 的操作都是非阻塞的。

 

方法二、recv, send 函数的最后有一个flag 参数可以设置成MSG_DONTWAIT

临时将sockfd 设置为非阻塞模式,而无论原有是阻塞还是非阻塞。

recv(sockfd, buff, buff_size,MSG_DONTWAIT); //非阻塞模式的消息发送

send(scokfd, buff, buff_size, MSG_DONTWAIT); //非阻塞模式的消息接受

 

 

阻塞与非阻塞读的区别: //阻塞和非阻塞的区别在于没有数据到达的时候是否立刻返回.

读(read/recv/msgrcv):

读的本质来说其实不能是读,在实际中, 具体的接管数据不是由这些调用来进行,是由于系统底层自动完成的。read 也好,recv 也好只负责把数据从底层缓冲copy 到我们指定的位置.

对于读来说(read, 或者recv) ::

阻塞情况下::

在阻塞条件下,read/recv/msgrcv的行为::

1、如果没有发现数据在网络缓冲中会一直等待,

2、当发现有数据的时候会把数据读到用户指定的缓冲区,但是如果这个时候读到的数据量比较少,比参数中指定的长度要小,read 并不会一直等待下去,而是立刻返回。

read 的原则::是数据在不超过指定的长度的时候有多少读多少,没有数据就会一直等待。

所以一般情况下::我们读取数据都需要采用循环读的方式读取数据,因为一次read 完毕不能保证读到我们需要长度的数据,

read 完一次需要判断读到的数据长度再决定是否还需要再次读取。

非阻塞情况下::

在非阻塞的情况下,read 的行为::

1、如果发现没有数据就直接返回,

2、如果发现有数据那么也是采用有多少读多少的进行处理.

所以::read 完一次需要判断读到的数据长度再决定是否还需要再次读取。

 

对于读而言:: 阻塞和非阻塞的区别在于没有数据到达的时候是否立刻返回.
recv 中有一个MSG_WAITALL 的参数::

recv(sockfd, buff, buff_size, MSG_WAITALL),
在正常情况下recv 是会等待直到读取到buff_size 长度的数据,但是这里的WAITALL 也只是尽量读全,在有中断的情况下recv 还是可能会被打断,造成没有读完指定的buff_size的长度。

所以即使是采用recv + WAITALL 参数还是要考虑是否需要循环读取的问题,在实验中对于多数情况下recv (使用了MSG_WAITALL)还是可以读完buff_size,

所以相应的性能会比直接read 进行循环读要好一些。

 

注意:: //使用MSG_WAITALL时,sockfd必须处于阻塞模式下,否则不起作用。

//所以MSG_WAITALL不能和MSG_NONBLOCK同时使用。

要注意的是使用MSG_WAITALL的时候,sockfd 必须是处于阻塞模式下,否则WAITALL不能起作用。

 

 

阻塞与非阻塞写的区别: //
写(send/write/msgsnd)::

写的本质也不是进行发送操作,而是把用户态的数据copy 到系统底层去,然后再由系统进行发送操作,send,write返回成功,只表示数据已经copy 到底层缓冲,而不表示数据已经发出,更不能表示对方端口已经接管到数据.
对于write(或者send)而言,

阻塞情况下:: //阻塞情况下,write会将数据发送完。(不过可能被中断)

在阻塞的情况下,是会一直等待,直到write 完,全部的数据再返回.这点行为上与读操作有所不同。

原因::

读,究其原因主要是读数据的时候我们并不知道对端到底有没有数据,数据是在什么时候结束发送的,如果一直等待就可能会造成死循环,所以并没有去进行这方面的处理;

写,而对于write, 由于需要写的长度是已知的,所以可以一直再写,直到写完.不过问题是write 是可能被打断吗,造成write 一次只write 一部分数据, 所以write 的过程还是需要考虑循环write, 只不过多数情况下一次write 调用就可能成功.

 

非阻塞写的情况下:: //

非阻塞写的情况下,是采用可以写多少就写多少的策略.与读不一样的地方在于,有多少读多少是由网络发送的那一端是否有数据传输到为标准,但是对于可以写多少是由本地的网络堵塞情况为标准的,在网络阻塞严重的时候,网络层没有足够的内存来进行写操作,这时候就会出现写不成功的情况,阻塞情况下会尽可能(有可能被中断)等待到数据全部发送完毕, 对于非阻塞的情况就是一次写多少算多少,没有中断的情况下也还是会出现write 到一部分的情况.


IO:阻塞和非阻塞、同步和异步 当数据还没准备好时,调用了阻塞的方法,则线程会被挂起,会让出CPU时间片,此时是无法处理过来的请求,需要等待其他线程来进行唤醒,该线程才能进行后续操作或者处理其他请求。
Java IO基础(同步阻塞IO) Java IO是一套Java 用来读写数据(输入和输出)的API,大部分程序都需要处理一些输入,并由输入产生一些输出(PS: 输入和输出是相对CPU而言的,input 就是从外面到CPU,output就是从CPU到外面,CPU是主人公)。java.io 包下有大约80多个类,大概可以分成四组:
Java NIO、BIO、 AIO 与 同步、阻塞、非阻塞、异步IO 简析 我相信大部分人看到这些名词,都是一头雾水的,如果你去搜索引擎搜索,那么恭喜你,你又会被各种文章中的高大上的名词搞得云里雾里。那么,我们应该怎么理清这么名词之间的关系呢? 所谓 同步/异步/阻塞/非阻塞 IO ,是指操作系统中的对 IO 处理的不同方法,而 Java 对这些不同操作方法做了一些包装,由此有了 BIO / NIO / AIO 几种操作接口。 我不想复制一些高大上的概念,只是想尽量好好说话,说清楚他们之间的关系。 有 A、B、C、D 四个线程可以生产文件,假设他们的返回的文件是一样的,对应我们的服务端 有 E、F、G、H 四个线程在随机时间向服务端上传一个文本,并且要求
常见IO五种模型-阻塞IO、非阻塞IO、IO多路复用、信号驱动IO、异步IO 用户空间与内核空间 进程的寻址空间会划分为两部分:内核空间、用户空间 用户空间只能执行受限的命令,而且不能直接调用系统资源,必须通过内核提供的接口来访问 内核空间可以执行特权命令。调用一切系统资源