服务器有没有收到数据，抓个包看看就行了。recvfrom和sendto都是阻塞的。通常来说，由于网络连接具有缓冲区，sendto函数直接将数据复制至缓冲区后即可认为操作完成，因此很少阻塞（除非缓冲区已满，它才会等待缓冲区足够写入后才能操作）；而recvfrom是从缓冲区读数据，如果没有数据则会一直阻塞。解决阻塞的方法一般有两种：使用setsockopt函数设置超时时长；在主线程中关闭socket，阻塞函数会报错并退出。

热门频道首页博客研修院VIPAPP问答下载社区推荐频道活动招聘专题打开CSDN APPCopyright © 1999-2020, CSDN.NET, All Rights Reserved打开APPHilaph关注Windows UDP recvfrom 不能阻塞 及 bind 报错的解决办法 原创2020-07-09 18:44:15Hilaph 码龄6年关注1、正常来说，UDP的recvfrom默认是阻塞的。可以手动设置是否为阻塞u_long iMODE = 0;//1为非阻塞，0为阻塞ioctlsocket(udp_cliSocket, FIONBIO, &iMODE);//设置recvfrom是否为阻塞ioctlsocket的第一个参数为socket套接字。此处我设置为0，依然会不阻塞。2、如果bind失败了，也会导致recvfrom不阻塞。if (bind(udp_cliSocket, (SOCKADDR*)&locAddr, sizeof(locAddr)) == SOCKET_ERROR){ printf(“UDP bind ERROR :%d\n“, WSAGetLastError());

}如果bind=SOCKET_ERROR时，说明bind失败，通过WSAGetLastError获取报错信息为10049——不能分配请求的地址。再次检查前面的代码，发现添加本地ip时给错了地址。。。文章知识点与官方知识档案匹配网络技能树首页概览21461 人正在系统学习中打开CSDN，阅读体验更佳UDP服务recvfrom函数设置非阻塞_leon_zeng0的博客_recvfrom...所以,接收情况的判断需要利用recvfrom 的返回值。 新的补充: 不用上面那样复杂,也可以直接用不阻塞标志,如下: ret=recvfrom(sockfd,recvbuff,recvbufflen,MSG_DONTWAIT,( struct sockaddr *) &cliaddr, &clientlen); 就是flags标志...继续访问recvfrom函数 非阻塞_IO - 同步、异步、阻塞、非阻塞2 同步非阻塞IO process在NonBlocking IO读recvfrom操作的第一个阶段是不会block等待的,如果kernel数据还没准备好,那么recvfrom会立刻返回一个EWOULDBLOCK错误。当kernel准备好数据后,进入处理的第二阶段的时候,process会等待kernel将数据copy...继续访问最新发布 UDP socket 设置为的非阻塞模式非阻塞写的情况下，是采用可以写多少就写多少的策略．与读不一样的地方在于，有多少读多少是由网络发送的那一端是否有数据传输到为标准，但是对于可以写多少是由本地的网络堵塞情况为标准的，在网络阻塞严重的时候，网络层没有足够的内存来进行写操作，这时候就会出现写不成功的情况，阻塞情况下会尽可能(有可能被中断)等待到数据全部发送完毕， 对于非阻塞的情况就是一次写多少算多少,没有中断的情况下也还是会出现write 到一部分的情况.对于一个TCP套接口，内核将从应用进程的缓冲区到该套接口的发送缓冲区拷贝数据。继续访问【网络协议】转载：关于TCP与UDP的接收recv和recvfrom关于TCP与UDP的接收recv和recvfrom 技术标签： 网络协议 计算机网络 1.UDP发包的问题 问：udp 发送(sendto)两次数据，第一次 100字节 ，第二次200字节， 接包方一次recvfrom( 1000 ), 收到是 100，还是200，还是300？ 答：UDP是数据报文协议，是以数据包方式，所以每次可以接收100，200，在理想情况下，第一次是无论recvfrom多少都是接收到100。当然，可能由于网络原因，第二个包先到的话，有可能是200了。对可能会由于网络原因乱序，所继续访问【提供可能的解决思路】本地编写UDP通信，recvfrom不阻塞，并一直返回-1【提供可能的解决思路】本地编写UDP通信，recvfrom不阻塞，并一直返回-1 记录一个使用socket库中遇到的问题，最近项目中遇到使用本地udp通信的情况，在编写程序过程中，发现调用recvfrom一直失败，返回-1，错误码10022。 排查了半个下午，终于发现原来是bind函数的问题。 由于在文件开头使用了 using namespace std 导致默认的bind变成了 functional.h中的那个，而不是socket的bind，导致绑定一直没有成功。 解决方案： 1.不要在文件中用 usi继续访问socket学习:windows平台用udp模式接收数据，recvfrom函数返回值为-1，但是接收缓冲区中中却有数据现象:windows平台用udp模式接收数据，recvfrom函数返回值为-1，但是接收缓冲区中中却有数据 方法:用GetLastError()，errno为10040， 错误含义： 一个在数据报套接字上发送的消息大于内部消息缓冲器或其他一些网络限制，或该用户用于接收数据报的缓冲器比数据报小 最后发现原因:接收缓冲buf设置较小，发送方发送的数据超出了接收位置的长度 ...继续访问热门推荐 UDP服务recvfrom函数设置非阻塞基本概念： 方法一：通过fcntl函数将套接字设置为非阻塞模式。 方法二：通过套接字选项SO_RECVTIMEO设置超时。 方法一源码，编译：g++ udp_server.cpp -o server #include #include #include #include #include #include #include #include #include #i继续访问关于send和recv在UDP的使用在socket编程中，包括有连接和无连接两种方式，其流程如下： 有连接： TCP客户端的流程一般是 socket-【bind】-connect-send/recv 无连接： UDP客户端的流程一般是 socket-【bind】-sendto/recvfrom send与sento相比，没有提供对方的地址，在有连接模式中， 连接已经事先建立好，当然不需要每次都提供对方地址。但是，即使在无连接模式中，...继续访问C++ UDP通信，recvfrom函数一直堵塞对于UDP通信中，recvfrom函数一直阻塞的问题，首先要检查发送端……继续访问recvfrom不阻塞_一文带你区分阻塞、非阻塞、同步、异步IO前言：在之前的Redis面试套路拆解的文章中有提到过IO模型，并且IO模型本身也是一个比较容易混淆的高频面试考点，小黑板将在本篇文章帮你理清思路，区分各种IO模型~其实网络上已经有很多博客讲了这个问题，但是总是觉得看完之后还是迷迷糊糊的，感觉大家有点太执着于把这个问题讲的通俗易懂了，经常会举各种各样的例子，比如烧水、去银行办理业务之类的，然而看完之后反倒会产生更多的...继续访问SOCKET编程UDP，bind失败佛了竟然是因为端口号 一直bind失败，找不到原因，没想到端口号的问题，可能是因为端口号已绑定，换个端口号； ret = bind(sServer, (SOCKADDR *)&ServerAddr, sizeof(ServerAddr)); std::cout 《《 ret; if ( ret== SOCKET_ERROR) { printf(“BIND失败！\n“); return; } ...继续访问linux select read阻塞_阻塞&非阻塞&同步&异步之间的关系一：阻塞与非阻塞阻塞和非阻塞关注的是程序在等待调用结果（消息，返回值）时的状态.阻塞和非阻塞关注的是程序在等待调用结果（消息，返回值）时的状态.阻塞调用是指调用结果返回之前，当前线程会被挂起。调用线程只有在得到结果之后才会返回。非阻塞调用指在不能立刻得到结果之前，该调用不会阻塞当前线程。1.blockingIO（阻塞）：1.1：阻塞调用是指调用结果返回之前，当前线程会被挂起。函数只有在得到结果之后...继续访问TCP、UDP 通信常用函数send,sendto,recv,recvfrom详解send函数 int send( SOCKET s, const char FAR *buf, int len, int flags ); 不论是客户还是服务器应用程序都用send函数来向TCP连接的另一端发送数据。 客户程序一般用send函数向服务器发送请求，而服务器则通常用send函数来向客户程序发送应答。 该函数的第一个参数指定发送端套接字描述符； 第二个参数指...继续访问非阻塞recvfrom的设置 我想用UDP阻塞模式给硬件设备发包，然后收包。因为网络的问题，经常丢包，也就是发了之后没有响应。这样的话，recvfrom会一直停在那里，死机了一样。 能不能设成超时自动返回，或者其它什么解决办法，谢谢！ 我不想用非阻塞模式，据说比较耗资源。 //连接超时 //----------------继续访问udp_recv(UDP服务器端)#include 《stdio.h》 #include 《string.h》 #include 《strings.h》 #include 《stdlib.h》 #include 《sys/types.h》 #include 《sys/socket.h》 #include 《arpa/inet.h》 #define BUFSIZE 64 #define PORT 8888 #define IP “0.0.0.0” int ma继续访问linux socket read 阻塞read函数只是一个通用的读文件设备的接口。是否阻塞需要由设备的属性和设定所决定。一般来说，读字符终端、网络的socket描述字，管道文件等，这些文件的缺省read都是阻塞的方式。如果是读磁盘上的文件，一般不会是阻塞方式的。但使用锁和fcntl设置取消文件O_NOBLOCK状态，也会产生阻塞的read效果。 怎么样以非阻塞的方式从管道中读取数据？因为我用rea ...继续访问recvfrom不阻塞经验分享写评论评论4点赞踩分享打开CSDN APP阅读体验更佳

没开服务器执行客户端recvfrom确实返回SOCKET_ERROR。WSAGetLastError返回值10054（WSAECONNRESET ）A existing connection was forcibly closed by the remote host. 看来sendto函数发送失败（IP地址无接收端口），导致recvfrom的失败。（对方机器强行关闭）请采纳。

你的UDP服务器的代码写的是对的。recvfrom()也应该是会阻塞的。你可以在printf(“daole“);前加一句printf(“%s\n“,Buf);来看recvfrom()不阻塞，是不是收到了什么。

方法1. 用setsockopt设置阻塞超时时间，recvfrom阻塞一段超时后，退出响应其他线程的消息。

方法2. 主线程直接把recvfrom的socket close掉，recvfrom会报错退出。

如果服务端启动udptest_server，客户端启动udptest_client，客户端正常接收

如果服务端不启动udptest_server，客户端启动udptest_client后，客户端阻塞在recvfrom调用，虽然内核收到了ICMP端口不可达报文，但是用户态完全无感知

recvfrom调用会阻塞，即使收到ICMP端口不可达报文，也会阻塞，但是经过第一种方法或第二种方法后，recvfrom会返回-1，通过判断errno是否是 ECONNREFUSED 来判断是否收到ICMP端口不可达报文

没开服务器执行客户端recvfrom确实返回SOCKET_ERROR。WSAGetLastError返回值10054（WSAECONNRESET ）A existing connection was forcibly closed by the remote host. 看来sendto函数发送失败（IP地址无接收端口），导致recvfrom的失败。

方法1. 用setsockopt设置阻塞超时时间，recvfrom阻塞一段超时后，退出响应其他线程的消息。 方法2. 主线程直接把recvfrom的socket close掉，recvfrom会报错退出。

方法1. 用setsockopt设置阻塞超时时间，recvfrom阻塞一段超时后，退出响应其他线程的消息。

方法2. 主线程直接把recvfrom的socket close掉，recvfrom会报错退出。

推荐用非阻塞的的方式。如果非要用阻塞的方式，可以把recvfrom放在一个子线程里，recvfrom完成后子线程即退出，主线程中在启动子线程后使用WaitForSingleObject(子线程句柄，等待时间)，来等待子线程退出。若等待超时子线程还没有退出，在主线程中调用closesocket，这样子线程中阻塞的recvfrom会立即返回，这样主线程就可以进行下一步的流程。