recv/send堵塞和非堵塞

最新推荐文章于 2023-08-05 10:56:42 发布
最新推荐文章于 2023-08-05 10:56:42 发布
阅读量5.6k 收藏 67
点赞数 18
分类专栏： 网络编程
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_35987777/article/details/107416597
版权

recv/send堵塞和非堵塞理解

参考：
TCP之深入浅出send和recv
linux下非阻塞的tcp研究

题外话

今天在看epoll的ET模式时，说ET模式时，套接字描述符必须设置成非堵塞模式，为什么 IO 多路复用要搭配非阻塞 IO?
于是想看看堵塞和非堵塞recv/send的区别，网上鱼龙混杂的博文，错误百出，查了好久，在此做个总结，如有错误的地方，希望大家指出来。

关于阻塞和非阻塞read/write，可以参考阻塞和非阻塞read/write
-------------------------------------这部分转载于TCP之深入浅出send和recv

TCP之深入浅出send和recv

需要理解的3个概念

1.TCP socket的buffer
每个TCP socket在内核中都有一个发送缓冲区和一个接收缓冲区，TCP的全双工的工作模式以及TCP的流量(拥塞)控制便是依赖于这两个独立的buffer以及buffer的填充状态。

接收缓冲区把数据缓存入内核，应用进程一直没有调用recv()进行读取的话，此数据会一直缓存在相应socket的接收缓冲区内。

再啰嗦一点，不管进程是否调用recv()读取socket，对端发来的数据都会经由内核接收并且缓存到socket的内核接收缓冲区之中。

recv()所做的工作，就是把内核缓冲区中的数据拷贝到应用层用户的buffer里面，并返回，仅此而已。进程调用send()发送的数据的时候，最简单情况（也是一般情况），将数据拷贝进入socket的内核发送缓冲区之中，然后send便会在上层返回。换句话说，send（）返回之时，数据不一定会发送到对端去（和write写文件有点类似），send()仅仅是把应用层buffer的数据拷贝进socket的内核发送buffer中，发送是TCP的事情，和send其实没有太大关系。接收缓冲区被TCP用来缓存网络上来的数据，一直保存到应用进程读走为止。

对于TCP，如果应用进程一直没有读取，接收缓冲区满了之后，发生的动作是：收端通知发端，接收窗口关闭（win=0）。这个便是滑动窗口的实现。保证TCP套接口接收缓冲区不会溢出，从而保证了TCP是可靠传输。因为对方不允许发出超过所通告窗口大小的数据。 这就是TCP的流量控制，如果对方无视窗口大小而发出了超过窗口大小的数据，则接收方TCP将丢弃它。

查看测试机的socket发送缓冲区大小，

cat /proc/sys/net/ipv4/tcp_wmem
4096	16384	4194304

第一个值是一个限制值，socket发送缓存区的最少字节数；
第二个值是默认值；
第三个值是一个限制值，socket发送缓存区的最大字节数；
根据实际测试,发送缓冲区的尺寸在默认情况下的全局设置是16384字节，即16k。
在测试系统上，发送缓存默认值是16k。
proc文件系统下的值和sysctl中的值都是全局值，应用程序可根据需要在程序中使用setsockopt（）对某个socket的发送缓冲区尺寸进行单独修改，详见文章《TCP选项之SO_RCVBUF和SO_SNDBUF》，不过这都是题外话。

2.接收窗口（滑动窗口）
TCP连接建立之时的收端的初始接受窗口大小是14600，细节如图2所示（129是收端，130是发端）
图2
图2
接收窗口是TCP中的滑动窗口，TCP的收端用这个接受窗口----win=14600，通知发端，我目前的接收能力是14600字节。
后续发送过程中，收端会不断的用ACK ( ACK的全部作用请参照博文《TCP之ACK发送情景 )。通知发端自己的接收窗口的大小状态，如图3，而发端发送数据的量，就根据这个接收窗口的大小来确定，发端不会发送超过收端接收能力的数据量。这样就起到了一个流量控制的的作用。
在这里插入图片描述
图3

图3说明
21,22两个包都是收端发给发端的ACK包

第21个包，收端确认收到的前7240个字节数据，7241的意思是期望收到的包从7241号开始，序号加了1.同时，接收窗口从最初的14656（如图2）经过慢启动阶段增加到了现在的29120。用来表明现在收端可以接收29120个字节的数据，而发端看到这个窗口通告，在没有收到新的ACK的时候，发端可以向收端发送29120字节这么多数据。

第22个包，收端确认收到的前8688个字节数据，并通告自己的接收窗口继续增长为32000这么大。

3.单个TCP的负载量和MSS的关系
MSS在以太网上通常大小是1460字节，而我们在后续发送过程中的单个TCP包的最大数据承载量是1448字节，这二者的关系可以参考博文《TCP之1460MSS和1448负载》。

实例详解send()

实例功能说明：接收端129作为客户端去连接发送端130，连接上之后并不调用recv（）接收，而是sleep（1000），把进程暂停下来，不让进程接收数据。内核会缓存数据至接收缓冲区。发送端作为服务器接收TCP请求之后，立即用ret = send(sock,buf,70k,0);这个C语句，向接收端发送70k数据。
我们现在来观察这个过程。看看究竟发生了些什么事。wireshark抓包截图如下图4
在这里插入图片描述
图4说明，包序号等同于时序

  1. 客户端sleep在recv（）之前，目的是为了把数据压入接收缓冲区。服务端调用"ret = send(sock,buf,70k,0);"这个C语句，向接收端发送70k数据。由于发送缓冲区大小16k，send（）无法将70k数据全部拷贝进发送缓冲区，故先拷贝16k进入发送缓冲区，下层发送缓冲区中有数据要发送，内核开始发送。上层send（）在应用层处于阻塞状态；
  2. 11号TCP包，发端从这儿开始向收端发送1448个字节的数据；
  3. 12号TCP包，发端没有收到之前发送的1448个数据的ACK包，仍然继续向收端发送1448个字节的数据；
  4. 13号TCP包，收端向发端发送1448字节的确认包，表明收端成功接收总共1448个字节。此时收端并未调用recv（）读取，目前发送缓冲区中被压入1448字节。由于处于慢启动状态，win接收窗口持续增大，表明接受能力在增加，吞吐量持续上升；
  5. 14号TCP包，收端向发端发送2896字节的确认包，表明收端成功接收总共2896个字节。此时收端并未调用recv（）读取，目前发送缓冲区中被压入2896字节。由于处于慢启动状态，win接收窗口持续增大，表明接受能力在增加，吞吐量持续上升；
  6. 15号TCP包，发端继续向收端发送1448个字节的数据；
  7. 16号TCP包，收端向发端发送4344字节的确认包，表明收端成功接收总共4344个字节。此时收端并未调用recv（）读取，目前发送缓冲区中被压入4344字节。由于处于慢启动状态，win接收窗口持续增大，表明接受能力在增加，吞吐量持续上升；
  8. 从这儿开始，我略去很多包，过程类似上面过程。同时，由于不断的发送出去的数据被收端用ACK确认，发送缓冲区的空间被逐渐腾出空地，send（）内部不断的把应用层buf中的数据向发送缓冲区拷贝，从而不断的发送，过程重复。70k数据并没有被完全送入内核,send()不管是否发送出去，send不管发送出去的是否被确认，send（）只关心buf中的数据有没有被全部送往发送缓冲区。如果buf中的数据没有被全部送往发送缓冲区，send（）在应用层阻塞，负责等待发送缓冲区中有空余空间的时候，逐步拷贝buf中的数据；如果buf中的数据被全部拷入发送缓冲区，send（）立即返回。
  9. 经过慢启动阶段接收窗口增大到稳定阶段，TCP吞吐量升高到稳定阶段，收端一直处于sleep状态，没有调用recv（）把内核中接收缓冲区中的数据拷贝到应用层去，此时收端的接收缓冲区中被压入大量数据；
  10. 66号、67号TCP数据包，发端继续向收端发送数据；
  11. 68号TCP数据包，收端发送ACK包确认接收到的数据，ACK=62265表明收端已经收到62264字节的数据，这些数据目前被压在收端的接收缓冲区中。win=3456，比较之前的16号TCP包的win=23296,表明收端的窗口已经处于收缩状态，收端的接收缓冲区中的数据迟迟未被应用层读走，导致接收缓冲区空间吃紧，故收缩窗口，控制发送端的发送量，进行流量控制；
  12. 69号、70号TCP数据包，发端在接收窗口允许的数据量的范围内，继续向收端发送2段1448字节长度的数据；
  13. 71号TCP数据包，至此，收端已经成功接收65160字节的数据，全部被压在接收缓冲区之中，接收窗口继续收缩，尺寸为1600字节；
  14. 72号TCP数据包，发端在接收窗口允许的数据量的范围内，继续向收端发送1448字节长度的数据；
  15. 73号TCP数据包，至此，收端已经成功接收66608字节的数据，全部被压在接收缓冲区之中，接收窗口继续收缩，尺寸为192字节。
  16. 74号TCP数据包，和我们这个例子没有关系，是别的应用发送的包；
  17. 75号TCP数据包，发端在接收窗口允许的数据量的范围内，向收端发送192字节长度的数据；
  18. 76号TCP数据包，至此，收端已经成功接收66800字节的数据，全部被压在接收缓冲区之中，win=0接收窗口关闭，接收缓冲区满，无法再接收任何数据；
  19. 77号、78号、79号TCP数据包，由keepalive触发的数据包，响应的ACK持有接收窗口的状态win=0，另外，ACK=66801表明接收端的接收缓冲区中积压了66800字节的数据。
  20. 从以上过程，我们应该熟悉了滑动窗口通告字段win所说明的问题，以及ACK确认数据等等。现在可得出一个结论，接收端的接收缓存尺寸应该是66800字节（此结论并非本篇主题）。
    send（）要发送的数据是70k，现在发出去了66800字节，发送缓存中还有16k，应用层剩余要拷贝进内核的数据量是N=70k-66800-16k。接收端仍处于sleep状态，无法recv（）数据，这将导致接收缓冲区一直处于积压满的状态，窗口会一直通告0(win=0)。发送端在这样的状态下彻底无法发送数据了，send（）的剩余数据无法继续拷贝进内核的发送缓冲区，最终导致send（）被阻塞在应用层；
  21. send（）一直阻塞中。。。

图4和send（）的关系说明完毕。

那什么时候send返回呢？有3种返回场景

send（）返回场景

  • 场景1，我们继续图4这个例子，不过这儿开始我们就跳出图4所示的过程了
  1. 接收端sleep（1000）到时间了，进程被唤醒，代码片段如图5
    在这里插入图片描述
    图5

随着进程不断的用"recv（fd,buf,2048,0）;"将数据从内核的接收缓冲区拷贝至应用层的buf，在使用win=0关闭接收窗口之后，现在接收缓冲区又逐渐恢复了缓存的能力，这个条件下，收端会主动发送携带"win=n（n>0）"这样的ACK包去通告发送端接收窗口已打开；

  1. 发端收到携带"win=n(n>0)"这样的ACK包之后，开始继续在窗口运行的数据量范围内发送数据。发送缓冲区的数据被发出；
  2. 收端继续接收数据，并用ACK确认这些数据；
  3. 发端收到ACK，可以清理出一些发送缓冲区空间，应用层send（）的剩余数据又可以被不断的拷贝进内核的发送缓冲区；
  4. 不断重复以上发送过程；
  5. send（）的70k数据全部进入内核，send（）成功返回。
  • 场景2，我们继续图4这个例子，不过这儿开始我们就跳出图4所示的过程了
  1. 收端进程或者socket出现问题，给发端发送一个RST；
  2. 内核收到RST，send返回-1。
  • 场景3，和以上例子没关系
    连接上之后，马上send（1k），这样，发送的数据肯定可以一次拷贝进入发送缓冲区，send（）拷贝完数据立即成功返回。

send()发送结论

send（）只是负责拷贝，拷贝完立即返回，不会等待发送和发送之后的ACK。如果socket出现问题，RST包被反馈回来。在RST包返回之时，如果send（）还没有把数据全部放入内核或者发送出去，那么send（）返回-1，errno被置错误值；如果RST包返回之时，send（）已经返回，那么RST导致的错误会在下一次send（）或者recv（）调用的时候被立即返回。

概念上容易疑惑的地方

  1. TCP协议本身是为了保证可靠传输,并不等于应用程序用tcp发送数据就一定是可靠的，必须要容错；
  2. send（）和recv（）没有固定的对应关系，不定数目的send()可以触发不定数目的recv（），这话不专业，但是还是必须说一下，初学者容易疑惑；
  3. 关键点，send（）只负责拷贝，拷贝到内核就返回，我通篇在说拷贝完返回，很多文章中说send（）在成功发送数据后返回，成功发送是说发出去的东西被ACK确认过，send（）只拷贝，不会等ACK；
  4. 此次send（）调用所触发的程序错误，可能会在本次返回，也可能在下次调用网络IO函数的时候被返回。

实际上理解了阻塞式的，就能理解非阻塞的。

参考linux下非阻塞的tcp研究

在阻塞模式下，send函数的过程是将应用程序请求发送的数据拷贝到内核发送缓存中，待发送数据完全被拷贝到内核发送缓存区中才返回，当然如果内核发送缓存区一直没有空间能容纳待发送的数据,则一直阻塞;

在非阻塞模式下，send函数的过程也是将应用程序请求发送的数据拷贝内核发送缓存中，区别在于非堵塞模式下，send函数不需要等到待发送数据完全被拷贝到内核发送区中才返回。
如果内核缓存区可用空间不够容纳所有待发送数据，则尽能力的拷贝，返回成功拷贝的大小；
如果缓存区可用空间为0,则返回-1,同时设置errno为EAGAIN.

-------------------------------------------------以下部分为个人思考总结所得

send函数

参考linux下非阻塞的tcp研究

注意并不是send把s的发送缓冲中的数据传到连接的另一端的，而是底层TCP/IP协议栈传的，send仅仅是把用户buf中的数据copy到s的发送缓冲区的剩余空间里

在阻塞模式下，send函数的过程是将应用程序请求发送的数据拷贝到内核发送缓存中，待发送数据完全被拷贝到内核发送缓存区中才返回，当然如果内核发送缓存区一直没有空间能容纳待发送的数据,则一直阻塞;

在非阻塞模式下，send函数的过程也是将应用程序请求发送的数据拷贝内核发送缓存中，区别在于非堵塞模式下，send函数不需要等到待发送数据完全被拷贝到内核发送区中才返回。
如果内核缓存区可用空间不够容纳所有待发送数据，则尽能力的拷贝，返回成功拷贝的大小；
如果缓存区可用空间为0,则返回-1,同时设置errno为EAGAIN.

看看官方手册中的描述https://linux.die.net/man/2/send，摘抄如下

If the message is too long to pass atomically through the underlying protocol, the error EMSGSIZE is returned, and the message is not transmitted.

No indication of failure to deliver is implicit in a send(). Locally detected errors are indicated by a >return value of -1.

When the message does not fit into the send buffer of the socket, send() normally blocks, unless the socket has been placed in nonblocking I/O mode. In nonblocking mode it would fail with the error EAGAIN or EWOULDBLOCK in this case. The select(2) call may be used to determine when it is possible to send more data.

在看看《UNIX网络编程卷1》第 16 章 非阻塞式 I/O中的描述，如下
在这里插入图片描述

int send( SOCKET s, const char FAR *buf, int len, int flags );

该函数的：
第一个参数指定发送端套接字描述符；
第二个参数指明一个存放应用程序要发送数据的缓冲区；
第三个参数指明实际要发送的数据的字节数；
第四个参数一般置0。

堵塞模式下socket的send函数的执行流程：
1.如果内核发送缓冲区可用大小为0，send（）直接堵塞。。。，直到内核发送缓冲区里的数据被系统发送后，腾出空间后，send（）再将剩余的待发送数据拷贝到内核发送缓冲区中去；

2.如果内核发送缓冲区可用空间小于待发送的数据长度len，则send（）函数会先把部分数据拷贝到内核发送缓冲区中，然后会阻塞。。。，直到内核发送缓冲区里的数据被系统发送后，腾出空间后，send（）再将剩余的待发送数据拷贝到内核发送缓冲区中去；

不知道为啥百度百科上send()是 “send先比较待发送数据的长度len和套接字s的发送缓冲的长度， 如果len大于s的发送缓冲区的长度，该函数返回SOCKET_ERROR；”
明显感觉描述不对,按这样说，那不就无法发送大于socket内核发送缓冲区的长度的数据了，可以看看socket内核发送缓冲区的默认大小
cat /proc/sys/net/ipv4/tcp_wmem
4096 16384 4161536
表明socket内核发送缓冲区默认大小为16kB，那发送大于16kB的数据怎么办呢？所以这里明显有问题
官方手册的原话是
If the message is too long to pass atomically through the underlying protocol, the error EMSGSIZE is returned, and the message is not transmitted.

可以看看TCP之深入浅出send和recv中的抓包实验，可知待发送数据大于socket的内核缓冲区大小时，也是可以发送的，没有返回SOCKET_ERROR。
也可以看看这里socket之send与发送缓冲区大小的关系

可知，待发送数据的长度大于s的内核发送缓冲区的长度时，会先将s（发送端）的内核发送缓冲区填满，然后发送端会将内核发送缓冲区的数据发送到接收端socket的内核接收缓冲区，所以s（发送端）的内核发送缓冲区又会慢慢腾出空间，send又会将待发送数据往s（发送端）的内核发送缓冲区中copy，

极端情况就是s（发送端）的内核发送缓冲区填满，接收端socket的内核接收缓冲区也被填满，但是send待发送的数据还是没发完，此时会堵塞。。。，等待s（发送端）的内核发送缓冲区产生空闲内存，

3.如果内核发送缓冲区可用空间大于待发送的数据长度len，send()函数直接将待发送数据完全拷贝到内核的发送缓冲区，然后成功返回。

要注意send（）函数把待发送数据完全拷贝到s的内核发送缓冲区中之后，它就返回了，但是此时这些数据并不一定马上被传到连接的另一端。

注意：在Unix系统下，如果send在等待协议传送数据时网络断开的话，调用send的进程会接收到一个SIGPIPE信号，进程对该信号的默认处理是进程终止。

Send函数的返回值有三类：
（1）返回值=0：
（2）返回值<0：发送失败，错误原因存于全局变量errno中
（3）返回值>0：表示发送的字节数（实际上是拷贝到发送缓冲中的字节数）

错误代码：
EBADF 参数s 非合法的socket处理代码。
EFAULT 参数中有一指针指向无法存取的内存空间
ENOTSOCK 参数s为一文件描述词，非socket。
EINTR 被信号所中断。
EAGAIN 此操作会令进程阻断，但参数s的socket为不可阻断。
ENOBUFS 系统的缓冲内存不足
ENOMEM 核心内存不足
EINVAL 传给系统调用的参数不正确。

recv函数

recv函数把内核接收缓冲中的数据copy到buf

int recv( SOCKET s,char FAR *buf,int len, int flags);

具体的看看https://linux.die.net/man/2/recv
有一段话摘录在此

If no messages are available at the socket, the receive calls wait for a message to arrive, unless the socket is nonblocking (see fcntl(2)), in which case the value -1 is returned and the external variable errno is set to EAGAIN or EWOULDBLOCK.
如果内核接收缓冲区内没有数据可读，则recv会堵塞，直到有数据到达，然后返回；
如果内核接收缓冲区内没有数据可读，但是recv设置为非堵塞，那么recv会返回-1，同时将errno置为EAGAIN or EWOULDBLOCK.
The receive calls normally return any data available, up to the requested amount, rather than waiting for receipt of the full amount requested.
recv返回值为读取到的字节数（这个数是内核接收缓冲区中可读取的字节数，可能是1个字节或者某个字节），最大可为buf区的大小len。recv并不是要等到读取完len个字节才返回。

posix 系统上，
在阻塞模式下
如果内核缓冲区没有数据可读， recv ()会阻塞，直到有一些数据存在可以读取为止。然后，它将返回读取到的数据(可能少于请求的数量len) ，返回的数最大为len。

在非阻塞模式下
如果内核缓冲区没有数据可读，recv 将立即返回 -1，设置 errno 为 EAGAIN 或 ewoudblock。
所以，通常在循环中调用 recv，直到得到所需的量，同时检查返回码是0(另一端断开)还是 -1(一些错误)。

在看看《UNIX网络编程卷1》第 16 章 非阻塞式 I/O中的描述，如下
在这里插入图片描述

int recv( SOCKET s,char FAR *buf,int len, int flags);

该函数的：
第一个参数指定接收端套接字描述符；
第二个参数指明一个缓冲区，该缓冲区用来存放recv函数接收到的数据；
第三个参数指明buf的长度；
第四个参数一般置0。

堵塞socket的recv函数的执行流程：
来自https://baike.baidu.com/item/recv%28%29

下面的描述正确性还不确定，反正网上都是这么说的，暂且看看吧

当应用程序调用recv函数时，recv先等待s的发送缓冲 中的数据被协议传送完毕，如果协议在传送s的发送缓冲中的数据时出现网络错误，那么recv函数返回SOCKET_ERROR，

如果s的发送缓冲中没有数 据或者数据被协议成功发送完毕后，**recv先检查套接字s的接收缓冲区，如果s接收缓冲区中没有数据或者协议正在接收数据，那么recv就一直等待，直到协议把数据接收完毕。 **

个人质疑：直到协议把数据接收完毕是什么意思？TCP是数据流，那什么叫做完毕呢？
假如，接收端套接字的接收缓冲区为16kB大小，发送端套接字一次发送8kB数据过来，肯定需要一点时间后，这8KB的数据才能完全到达接收端套接字的接收缓冲区，那接收端recv是一看到接收缓冲区有一点数据就返回？还是等接收缓冲区有8KB数据之后才返回？那如果发送端套接字发送完8kB数据后，立马又发送8kB数据呢？
所以接收端套接字的recv根本不知道发送端什么时候才把数据发送完毕，因为发送端可以想发多少发多少
看看《UNIX网络编程卷1》第 16 章 非阻塞式 I/O中的描述中的原话
在这里插入图片描述
可以知道正确的描述应该是：调用recv时，若该套接字的内核接收缓冲区没有数据可读，recv会堵塞（注意，这里前提是在堵塞模式下），直到有一些数据到达，这一些数据可能是单个字节，也可能是一个完整的TCP分节中的数据，recv就会被唤醒，然后返回copy到的字节数。

（注意协议接收到的数据可能大于buf的长度，所以 在这种情况下要调用几次recv函数才能把s的接收缓冲中的数据copy完。recv函数仅仅是copy数据，真正的接收数据是协议来完成的）

recv函数返回其实际copy的字节数。如果recv在copy时出错，那么它返回SOCKET_ERROR；如果recv函数在等待协议接收数据时网络中断了，那么它返回0。

注意：在Unix系统下，如果recv函数在等待协议接收数据时网络断开了，那么调用recv的进程会接收到一个SIGPIPE信号，进程对该信号的默认处理是进程终止。

  • 默认情况下socket是阻塞的。
    阻塞与非阻塞recv返回值没有区别，都是：
    <0 出错
    =0 对方调用了close API来关闭连接
    > 0 接收到的数据大小，

特别地：返回值<0时并且(errno == EINTR || errno == EWOULDBLOCK || errno == EAGAIN)的情况下认为连接是正常的，继续接收。

只是阻塞模式下recv会一直阻塞直到接收到数据，非阻塞模式下如果没有数据就会返回，不会阻塞着读，因此需要循环读取）。

返回说明：
（1）成功执行时，返回接收到的字节数。
（2）若另一端已关闭连接则返回0，这种关闭是对方主动且正常的关闭
（3）失败返回-1，errno被设为以下的某个值

EAGAIN：套接字已标记为非阻塞，而接收操作被阻塞或者接收超时
EBADF：sock不是有效的描述词
ECONNREFUSE：远程主机阻绝网络连接
EFAULT：内存空间访问出错
EINTR：操作被信号中断
EINVAL：参数无效
ENOMEM：内存不足
ENOTCONN：与面向连接关联的套接字尚未被连接上
ENOTSOCK：sock索引的不是套接字

selfsongs
关注
  • 18
    点赞
  • 踩
  • 67
    收藏
    觉得还不错? 一键收藏
  • 5
    评论
专栏目录
关于socket阻塞与非阻塞情况下的recv、send、read、write返回值.zip
01-17
Socket分为阻塞（Blocking）和非阻塞（Non-blocking）两种工作模式，这两种模式在处理`recv`、`send`、`read`、`write`函数返回值时有显著的差异。本篇文章将深入探讨这两种模式下的返回值特性。 ### 阻塞模式...
【Socket网络编程】17. recv() 函数详解
u011754972的博客
06-29 2万+
recv函数 int recv( SOCKET s, char *buf, int len, int flags); 参数说明 第一个参数指定接收端套接字描述符； 第二个参数指明一个缓冲区，该缓冲区用来存放recv函数接收到的数据； 第三个参数指明buf的长度；第四个参数一般置0。 同步Socket的recv函数的执行流程 当应用程序调用recv函数时： recv先等待 SOCKE...
recv() 阻塞&非阻塞
无线互联&网络介绍
03-07 9881
server.c #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <errno.h> #include <string.h> #include <sys/types.h> #include <sys/socket.h> #include <sys/time.h> #include <netinet/in.h> .
Linux C recv函数阻塞问题
流云落尘
11-06 4692
问题描述： 有个Linux项目用到TCP/IP通讯，但是recv()函数老是阻塞，没有返回；setsockopt()也设置了超时时间，同时在执行recv()之前也增加了select()查看套接字的状态，如果状态异常异常是不会执行recv()函数的 原因分析： 1、recv()是Linux的系统函数，肯定不会卡死，除非Linux内核故障，基本可以排除； 2、客户端向服务器端发送数据，服务器端没有接收，导致缓冲区满，客户端无法接收数据，因此客户端阻塞？等等，我不是加了超时吗？怎么还会阻塞？ 3、读写超时设
【win网络编程】socket中的recv阻塞和select的用法
modi000的博客
06-10 2173
转载请注明出处：作者 kikilizhm在编写ftp客户端程序时，在联通后使用recv函数进行接收欢迎信息时，需要申请内存进行接收数据保存，一次读取成功，但是由于一个随机的ftp服务端在说，欢迎信息的大小是不知道的，所以在尝试使用死循环，在阅读recv的说明时讲到返回值即是接收到的字节数，那么返回0的时候就代表结束了，实践发现recv是个阻塞函数，在连接不断开的情况下，会一直处于阻塞状态，也不会返回0.也就是说程序不能这么一直读，如果对端连接没有关闭，则在没有数据的情况下，调用recv会阻塞，如果对端关闭连
C++ Socket编程（二） send与recv 缓冲区与阻塞
yangkunqiankun的博客
07-23 1万+
socket缓冲区每一个socket在被创建之后，系统都会给它分配两个缓冲区，即输入缓冲区和输出缓冲区。 send函数并不是直接将数据传输到网络中，而是负责将数据写入输出缓冲区，数据从输出缓冲区发送到目标主机是由TCP协议完成的。数据写入到输出缓冲区之后，send函数就可以返回了，数据是否发送出去，是否发送成功，何时到达目标主机，都不由它负责了，而是由协议负责。recv函数也是一样的，它并不是直
java 中同步、异步、阻塞和非阻塞区别详解
08-30
在Java编程中，同步、异步、阻塞和非阻塞是四个重要的概念，它们涉及到多线程和并发处理，特别是在网络编程中尤为关键。理解这些概念有助于优化程序性能和提高资源利用率。 1. **同步**： 同步是编程中一种控制机制...
linux 非堵塞tcp/server tcp/client
05-19
非堵塞模式下，当一个socket无法立即完成读写操作时，系统调用不会阻塞，而是立刻返回，使得程序能够继续执行其他任务，从而提高了系统的整体效率和响应性。 首先，我们来详细了解一下非堵塞TCP服务器（TCP Server...
send-recv-init
12-09
在`www.pudn.com.txt`和`send_recv_int`这两个文件中，可能包含了更具体的示例代码或者对`send`和`recv`的进一步讲解，如错误处理、套接字选项、非阻塞模式下的使用等。对于学习和理解网络编程，熟悉并正确使用`send...
wxPloiter:开源轻量级多行数据包编辑器，具有用于 MapleStory 的 sendrecv 阻塞和 recv 注入
06-23
`wxPloiter` 是一个开源且轻量级的数据包编辑工具，专为 MapleStory 玩家设计，支持 sendrecv 阻塞和 recv 注入功能。在 IT 领域，特别是游戏黑客和网络安全社区中，这样的工具被广泛用于分析和操纵网络通信数据，以...
socket recv阻塞与非阻塞error总结
fuhanga123的博客
10-20 2143
socket recv阻塞与非阻塞error总结 recv是socket编程中最常用的函数之一，在阻塞状态的recv有时候会返回不同的值，而对于错误值也有相应的错误码，分别对应不同的状态，下面是我针对常见的几种网络状态的简单总结。       首先阻塞接收的recv有时候会返回0，这仅在对端已经关闭TCP连接时才会发生。       而当拔掉设备网线的时候，recv并不会发生变化
recv函数阻塞_socket缓冲区以及阻塞模式详解
weixin_39618121的博客
11-26 2744
在《socket 数据的接受和发送》一节中讲到，可以使用 write()/send() 函数发送数据，使用 read()/recv() 函数接收数据，本节就来看看数据是如何传递的。 socket 缓冲区每个 socket 被创建后，都会分配两个缓冲区，输入缓冲区和输出缓冲区。write()/send() 并不立即向网络中传输数据，而是先将数据写入缓冲区中，再由TCP协议将数据从缓冲区发送到目标机器...
socket的阻塞模式和非阻塞模式(send和recv函数在阻塞和非阻塞模式下的表现)
qq_42896106的博客
07-06 1万+
socket的阻塞模式和非阻塞模式 无论是Windows还是Linux,默认创建socket都是阻塞模式的 在Linux中,可以再创建socket是直接将它设置为非阻塞模式 int socket (int __domain, int __type, int __protocol) 将__type增加SOCK_NOBLOCK 不仅如此,在Linux上直接利用accept函数返回的代表与客户端通信的socket也提供了一个拓展函数accept4,直接将accept4返回的socket设置为非阻塞的 send和
recv 和 send 阻塞和非阻塞的区别
布袋和尚
02-25 1829
目录 答案 深入说明 在 epoll 中的应用 答案 阻塞，事情干不完就不要回来了！ 非阻塞，能干多少就是多少，赶紧回来！ 深入说明 // 将内核接收缓冲区中的数据 copy 到应用层中用户的 buffer 中。 int recv(int sockfd, void *buf, size_t len, int flag); // 将应用层中用户的 buffer 中的数据 copy...
recv函数设置非阻塞的两种方式及实验
最新发布
Roy111111111的博客
08-05 2604
经过我的实验，两种方式只要设定一个就能让这里的recv变成非阻塞，但是两种方式肯定在别的用处会有所不同，但是在此处，效果一样。采取其一即可，也就是所谓的一个设置为阻塞一个为非阻塞，最后的结果都是非阻塞。非阻塞了可能读到的东西就有问题，所以做了错误号的判断。
关于send函数在阻塞模式和非阻塞模式下的区别
Utopia2018的博客
07-31 1458
在阻塞模式下,send函数的过程是将应用程序请求发送的数据拷贝到发送缓存中发送并得到确认后再返回.但由于发送缓存的存在,表现为:如果发送缓存大小比请求发送的大小要大,那么send函数立即返回,同时向网络中发送数据;否则,send向网络发送缓存中不能容纳的那部分数据,并等待对端确认后再返回(接收端只要将数据收到接收缓存中,就会确认,并不一定要等待应用程序调用recv); 在...
TCP send 阻塞与非阻塞
03-18 2万+
原文连接: http://blog.chinaunix.net/uid-8489474-id-2031025.html tcp协议本身是可靠的,并不等于应用程序用tcp发送数据就一定是可靠的.不管是否阻塞,send发送的大小,并不代表对端recv到多少的数据. 在阻塞模式下, send函数的过程是将应用程序请求发送的数据拷贝到发送缓存中发送就返回.但由于发送缓存的存在,表现为
socket编程中send recv阻塞和非阻塞详解
热门推荐
shanzhizi的专栏
06-13 4万+
int send( SOCKET s, const char FAR *buf, int len, int flags ); 不论是客户还是服务器应用程序都用send函数来向TCP连接的另一端发送数据。客户程序一般用send函数向服务器发送请求，而服务器则通常用send函数来向客户程序发送应答。   该函数的第一个参数指定发送端套接字描述符；   第二个参数指明一个存放应用程序要发送数据
c++实现recv，send非堵塞
07-09
要实现非阻塞的recv和send，你可以使用以下方法： 1. 设置套接字为非阻塞模式：使用fcntl函数将套接字的文件描述符设置为非阻塞模式。例如： ```cpp #include <fcntl.h> int setNonBlocking(int sockfd) { int flags = fcntl(sockfd, F_GETFL, 0); if (flags == -1) { return -1; } if (fcntl(sockfd, F_SETFL, flags | O_NONBLOCK) == -1) { return -1; } return 0; } ``` 你可以在创建套接字后立即调用`setNonBlocking(sockfd)`将其设置为非阻塞模式。 2. 使用select或poll函数进行IO多路复用：使用select或poll函数可以同时监视多个套接字的可读或可写状态，以避免阻塞。例如，在非阻塞模式下使用select函数： ```cpp #include <sys/select.h> int nonBlockingRecv(int sockfd, char* buffer, int bufferSize) { fd_set readfds; FD_ZERO(&readfds); FD_SET(sockfd, &readfds); struct timeval timeout; timeout.tv_sec = 0; timeout.tv_usec = 0; int selectResult = select(sockfd + 1, &readfds, NULL, NULL, &timeout); if (selectResult == -1) { return -1; } if (selectResult == 0) { // 没有数据可读 return 0; } if (FD_ISSET(sockfd, &readfds)) { // 有数据可读 int recvResult = recv(sockfd, buffer, bufferSize, 0); if (recvResult == -1) { // 接收错误 return -1; } return recvResult; } return 0; } ``` 类似地，你可以实现非阻塞的send函数。 这些方法可以在C++中实现非阻塞的recv和send操作。请注意，非阻塞IO需要适当的处理，因为它们可能不会立即返回所需的数据量。你需要根据实际情况调整代码以处理部分读取/写入的情况。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 5
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值