sendto的调用导致recvfrom返回

最新推荐文章于 2022-12-10 12:15:56 发布
原创 最新推荐文章于 2022-12-10 12:15:56 发布 · 1.6k 阅读 · 1 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

本文探讨了在使用UDP套接字时遇到的一个问题：当一个线程在recvfrom函数上等待接收数据时，如果另一个线程通过同一套接字发送数据，则recvfrom会返回-1。文章记录了这一现象并提出疑问。

创建一个UDP套接字，在套接字上调用recvfrom，线程等待在该函数上。

如果在另一个线程中，在同一套接字上调用sendto将导致recvfrom返回，返回值为-1。

具体原因不明，先记录一下。

 

【socket】recvfrom/sendto、recv/send、read/write问答
数字人生
08-14 1451
【代码】【socket】recvfrom/sendto、recv/send、read/write问答。
UDP socket--sendto and recvfrom
RT的博客
03-02 2089
sendto 系统调用原型 sendto( int fd, void * buff, size_t len,unsigned int flags, struct sockaddr *addr,int addr_len) 内核中处理流程： sendto( int fd, void * buff, size_t len,unsigned int flags, struct sockaddr *addr,int addr_len) __sys_sendto(fd, buff, len, flags, NU
send recv详解
zjf82031913的专栏
03-15 773
nd函数和recv函数详解 Published on 十一月 4, 2009 2,053 send函数 int send( SOCKET s,    const char FAR *buf,    int len,    int flags );  不论是客户还是服务器应用程序都用send函数来向TCP连接的另一端发送数据。 客户程序一般用send函数向
ios UDP sendto方法返回值一直是-1
sun island的博客
11-15 4769
CocoaAsyncSocket 发送广播失败 sendto 返回值是-1
sendto函数返回-1_基本socket函数的解读--Berkeley socket的重点的翻译
weixin_32511509的博客
01-20 4872
看了unix网络编程是否有点感觉到它讲API讲的很杂，更像一本字典而不是一个可以快速学习的书。这里总结了基础的socket API并附带一些例子应该能帮助你更快的学习。GitHub:helintongh/Web-Server欢迎点赞什么是socket？套接字是网络通信路径的本地端点的抽象表示(句柄)。Berkeley sockets API将其表示为Unix中的一个文件描述符(文件句柄)，它为数据...
sendto函数返回-1_Python Socket函数详解
weixin_36356002的博客
01-25 2869
关于socket函数，每个的意义和基本功能都知道，但每次使用都会去百度，参数到底是什么，返回值代表什么意义，就是说用的少，也记得不够精确。每次都查半天，经常烦恼于此。索性都弄得清楚、通透，并记录下来，一来便于自己记忆，再者以防日后查阅、回顾。主要介绍：socket、bind、listen、connect、accept、send、sendto、recv、recvfrom、close、shutdown...
recvfrom()和sendto()函数
06-06
- 当调用 `recvfrom()` 时，如果缓冲区 `buf` 的大小不足以容纳整个数据包，那么只有部分数据会被接收。 - 在无连接的数据报socket方式下，即使使用了 `connect()` 函数绑定到特定的远程地址，仍然可以使用 `...
socket c语言 AF_TIPC,socket编程 send() recv() sendto() recvfrom()
weixin_39753791的博客
05-19 625
socket编程 send() recv() sendto() recvfrom()int socket( int af, int type, int protocol);af：指定一个协议簇(协议域)，常见有AF_INET──指定为IPv4协议，AF_INET6──指定为IPv6，AF_LOCAL──指定为UNIX 协议域等。它值都是系统预先定义的宏，系统支持哪些协议我们才可以使用，否则会调用失...
UDP 套接字 recvfrom & sendto
Hulk
12-16 1170
UDP编程中，服务器不接受来自客户端的连接，只管调用recvfrom函数，阻塞等待客户端的连接。 UDP都是以数据报的形式进行发送和接收的: 它一定是整包到达接收方. 而TCP是以数据流的形式进行发送和接收的: 发包是不会整包到达的，而是源源不断的到，那接收方就必须组包. 客户服务流程结构如下： recvfrom和sendto函数 函数定义： int send...
sendto 返回-1，errno为22，invalid argument的解决办法，mark一下
热门推荐
cjf764555750的博客
10-26 2万+
在给sockaddr_in6或者sockaddr_in赋值之前，先memset一下，保证所有成员为0，以免后面赋值不完整导致参数无效。
sendto 返回errnor 1,错误码1 Operation not permitted
fuyuande的博客
11-22 6326
使用udp套接字发送失败，返回-1，错误码为1，ping操作显示Operation not permitted 这个是防火墙导致的，使用iptables关掉防火墙去就没问题。 iptables -F  
send返回值
ang639
11-05 1万+
int ret = this->peer().send_n(ack_msg, len, &time_zero_);     switch (ret)     {         case 0:             // peer closed             return -1;         case -1:             if (errno == EWOULDBLOCK || errno == EAGAIN || errno == EINPROGRESS)   
recvfrom sendto的解释 多线程编程需要注意的地方 全局变量的设置 自定义消息 大杂烩inet_
hnust_xiehonghao的专栏
07-06 4205
if(-1 != sendto(app->sockClient, (char*)app->lpmsgHead, sizeof(MsgHead), 0, (SOCKADDR*)&addrSrv, sizeof(SOCKADDR))) 参数依次为：  发送端so
【send/sendto/sendmsg系统调用】
Luohsh1的专栏
09-17 1221
功能描述： 发送消息。send只可用于基于连接的套接字，send 和 write唯一的不同点是标志的存在，当标志为0时，send等同于write。sendto 和 sendmsg既可用于无连接的套接字，也可用于基于连接的套接字。除了套接字设置为非阻塞模式，调用将会阻塞直到数据被发送完。   用法：  #include #include ssize_t send(int sock
08_原始套接字
buhuidage的博客
11-20 1305
08_原始套接字
socket 网络编程------详细！！！（send/sendto和recv/recvfrom用法详解+代码演示讲解）
weixin_47573556的博客
12-10 1万+
网络编程socket详解！！函数详解！！内附完整代码和代码的理解与改进！！
recvfrom返回11，模式是阻塞
最新发布
04-25
<think>好的，我现在遇到了一个问题：recvfrom返回11，而模式是阻塞的。我需要弄清楚这是什么意思，以及如何解决它。让我先回忆一下recvfrom函数的相关知识。 首先，recvfrom是一个用于从套接字接收数据的系统调用，通常用于UDP套接字，因为它可以获取发送方的地址信息。当在阻塞模式下使用recvfrom时，如果没有数据到达，调用会一直阻塞，直到有数据可读。返回值大于0通常表示接收到的字节数。这里返回11，说明成功接收到了11字节的数据。那用户为什么会觉得有问题呢？可能他期望更多的数据或者数据内容有问题？ 接下来，我需要考虑可能的情况。比如，发送方确实只发送了11个字节的数据，或者接收缓冲区被限制只能接收这么多。另外，检查套接字是否正确设置为阻塞模式，是否有可能被其他操作修改了标志位？比如是否在某个地方调用了fcntl设置了非阻塞标志？另外，数据截断的问题。如果接收缓冲区的大小小于发送的数据包大小，那么recvfrom会截断数据，多余的部分可能会被丢弃。这时候返回值会是缓冲区的大小，而用户可能需要扩大接收缓冲区。但这里返回的是11，可能用户设置的缓冲区足够大，所以实际接收了11字节。 也可能发送方发送的数据确实只有11字节，而用户误以为应该更多。这时候需要检查发送方的代码，确认发送的数据长度是否正确。比如，发送时是否正确地计算了数据长度，是否有数据被意外截断。 此外，还要考虑网络问题。比如，数据包在传输过程中是否被分片，或者中间设备限制了数据包的大小。不过对于UDP来说，如果数据包超过MTU，会在IP层分片，但接收端会重组装，只要所有分片都到达。不过如果分片丢失，可能导致整个UDP包被丢弃，但这里recvfrom返回了11，说明至少有一个数据包到达了，所以可能不是这个问题。 再考虑代码层面。用户是否正确处理了recvfrom的返回值？比如，是否将接收到的数据正确拷贝到缓冲区，并处理了返回的长度。比如，如果用户分配了一个足够大的缓冲区，但实际接收到的数据只有11字节，那么应该只处理这11字节的数据，后面的数据可能是无效的。如果用户错误地处理了长度，比如当作固定长度处理，可能会引发问题。 举个例子，假设发送方发送了一个12字节的消息，但接收方只收到11字节，这可能吗？对于UDP来说，数据包是不可分割的，要么整个收到，要么丢失。所以如果recvfrom返回11，说明发送方确实发送了11字节的数据。因此，问题可能出在发送方没有发送足够的数据，或者接收方错误地处理了接收到的数据长度。 那么，解决方案可能包括：检查发送方的数据发送是否正确，确认发送的数据长度是否为11字节；检查接收方的缓冲区是否足够大，确保没有截断；确认套接字确实处于阻塞模式，没有意外地被设置为非阻塞；检查是否有其他错误发生，比如通过errno来判断recvfrom是否返回错误，但这里返回值是11，说明没有错误，因为错误时返回-1。 另外，用户可能需要打印接收到的数据内容，确认是否符合预期。比如，在接收后打印缓冲区的内容，或者记录日志，看看是否数据被正确接收。总结可能的解决步骤： 1.检查发送方代码，确认发送的数据长度是否正确。 2. 检查接收方缓冲区大小，确保足够容纳预期数据。 3.确认套接字处于阻塞模式，没有被设置为非阻塞。 4.打印接收到的数据内容，确认是否与发送的一致。 5.使用工具如Wireshark抓包，确认实际发送的数据包大小。 如果经过这些检查，发现发送的数据确实正确，那么recvfrom返回11是正常现象，可能用户的预期有误。否则，需要根据检查结果调整代码。 例如，接收方的代码可能如下： ```cchar buffer[1024]; ssize_t recv_len= recvfrom(sockfd,buffer, sizeof(buffer), 0,(struct sockaddr*)&src_addr, &addrlen); if (recv_len >0) {printf("Received %zd bytes: %.*s\n",recv_len,(int)recv_len, buffer); } ``` 这里要确保recv_len被正确处理，比如打印出来，或者处理数据时只使用前11字节。如果用户期望更多的数据，但发送方只发送了11字节，那么问题出在发送方。另外，套接字是否为阻塞模式可以通过检查是否设置了O_NONBLOCK标志。例如，在Linux下，可以使用fcntl检查： ```c int flags= fcntl(sockfd,F_GETFL, 0);if (flags &O_NONBLOCK) {printf("Socket isnon-blocking.\n"); } else{ printf("Socket is blocking.\n"); } ```如果发现套接字被设置为非阻塞，可能需要将其改回阻塞模式： ```cfcntl(sockfd, F_SETFL, flags& ~O_NONBLOCK);``` 但这种情况在用户明确设置阻塞模式的情况下应该不存在，除非其他地方修改了标志。 所以，用户应该检查这些方面，确认问题所在。</think>当`recvfrom`在阻塞模式下返回11时，表示成功接收了11字节的数据。以下是详细分析和解决方案： ### 原因分析 1. **正常数据接收**：返回值`11`表示从套接字缓冲区读取了11字节的数据，这是正常现象。 2. **UDP协议特性**：UDP是面向数据报的协议，每个`recvfrom`调用会读取一个完整的数据包。若返回值为11，说明发送方发送的数据包长度就是11字节。 3. **阻塞模式特性**：在阻塞模式下，`recvfrom`会一直等待直到数据到达，因此返回值不会因超时返回0（这是TCP的行为，UDP没有连接概念）。 ### 验证步骤 #### 1. 检查接收端代码 确认是否正确处理了返回值： ```c ssize_t recv_len = recvfrom(sockfd, buf, sizeof(buf), 0, (struct sockaddr*)&addr, &addrlen); if (recv_len == -1) { perror("recvfrom failed"); } else { printf("Received %zd bytes: %.*s\n", recv_len, (int)recv_len, buf); } ``` #### 2. 检查发送端代码 确认发送方实际发送的数据长度： ```c const char *msg = "hello world"; ssize_t send_len = sendto(sockfd, msg, strlen(msg), 0, (struct sockaddr*)&dest_addr, sizeof(dest_addr)); printf("Sent %zd bytes\n", send_len); // 应输出11 ``` #### 3. 检查套接字模式 验证套接字是否确实是阻塞模式（默认模式）： ```c int flags = fcntl(sockfd, F_GETFL, 0); if (flags & O_NONBLOCK) { printf("非阻塞模式！需修改为阻塞模式\n"); fcntl(sockfd, F_SETFL, flags & ~O_NONBLOCK); } ``` ### 解决方案 1. **发送端修正**：若发送方数据不足11字节，修正发送逻辑。 2. **接收端验证**：在接收端打印数据内容，确认是否符合预期。 3. **网络抓包分析**：使用`tcpdump`或Wireshark抓包，直接观察UDP数据包长度。 ### 完整代码示例 接收端诊断代码： ```c #include <stdio.h> #include <unistd.h> #include <sys/socket.h> #include <netinet/in.h> int main() { int sockfd = socket(AF_INET, SOCK_DGRAM, 0); struct sockaddr_in addr = { .sin_family = AF_INET, .sin_port = htons(6000), .sin_addr.s_addr = INADDR_ANY }; bind(sockfd, (struct sockaddr*)&addr, sizeof(addr)); char buf[1024]; struct sockaddr_in src_addr; socklen_t addrlen = sizeof(src_addr); ssize_t recv_len = recvfrom(sockfd, buf, sizeof(buf), 0, (struct sockaddr*)&src_addr, &addrlen); if (recv_len == -1) { perror("recvfrom error"); } else { printf("Received %zd bytes: [%.*s]\n", recv_len, (int)recv_len, buf); printf("Hex dump:"); for (int i = 0; i < recv_len; i++) { printf(" %02X", buf[i]); } printf("\n"); } close(sockfd); return 0; } ``` ### 典型问题场景 - 发送方使用`sizeof(buf)`发送固定长度数据，但buf内容未初始化。 - 接收端缓冲区足够大，但发送方实际发送数据小于缓冲区大小。 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值