Linux C多线程UDP通信recvfrom阻塞死锁问题解决

1、现有代码的核心逻辑错误 #

• socket生命周期完全错误：两侧代码均为每次检测到PDU输入变化就新建socket，收发完成后立即关闭socket。UDP虽为无连接协议，但高频创建销毁socket会触发临时端口耗尽、内核socket残留TIME_WAIT状态、报文被投递到已关闭socket的缓冲区等问题，你观察到的「仅能交换4次数据就阻塞」，本质就是前序socket未被内核完全释放，新socket收发报文异常导致的。
• bind逻辑完全错误：客户端侧代码将bind的目标地址设为对端PC4的IP10.100.20.54，bind的作用是绑定本机的网卡IP和监听端口，而非指定对端地址。错误的bind参数要么直接调用失败（你代码中未对bind失败做日志打印和错误处理，会直接跳过异常逻辑），要么导致socket无法正常监听网卡报文。
• 收发时序强耦合形成类死锁：当前逻辑为「必须先收到对端消息，才能向对端发送消息」，UDP无连接建立/保活机制，只要出现一次时序错位——比如A发完消息立刻关闭socket，B的回包到达时A的socket已销毁，B就会一直阻塞等待A的消息，A下一轮循环新建socket后也会阻塞等待B的消息，双向阻塞死锁就会出现。
• 基础编码错误：
  • 调用sendto时传入的长度参数为sizeof(PDU_UDP_IN)，这是指针类型长度（64位系统下为8字节），不是实际PDU数据的长度，会导致发送截断或附带垃圾数据。
  • 客户端代码在sendto调用前重复定义client_struct_length变量，造成变量遮蔽，传入内核的地址长度参数不可靠，可能触发发送失败。
  • 服务端注释掉recvfrom后，直接打印清零的缓冲区内容，此时打印的「接收成功」和消息值是无效的，并非真的完成了双向收发，只是没有触发阻塞而已。

2、阻塞问题的最简解决方案 #

select机制完全适用于跨PC多线程通信场景，它仅监听本机socket缓冲区状态，和部署位置、线程模型无关，但你当前的问题不需要引入复杂的IO多路复用，修正基础逻辑即可解决：

• 第一步：将socket创建、参数配置、对端地址初始化全部移到while循环外侧，线程启动时仅创建一次socket，整个线程生命周期复用同一个socket，绝对不要在循环内反复创建/销毁socket。
• 第二步：修正bind逻辑：固定监听端口的一侧（比如PC4）绑定自身网卡IP+2000端口，另一侧（PC3）不需要手动bind固定端口，由内核自动分配临时端口即可。同时打开端口快速复用选项，避免程序重启时端口占用：

int opt = 1;
setsockopt(socket_desc, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt));

• 第三步：给socket设置和EtherCAT周期匹配的接收超时，禁止无限阻塞recvfrom，比如设置20ms超时：

struct timeval rcv_timeout;
rcv_timeout.tv_sec = 0;
rcv_timeout.tv_usec = 20000; // 超时时间根据你的业务周期调整即可
setsockopt(socket_desc, SOL_SOCKET, SO_RCVTIMEO, &rcv_timeout, sizeof(rcv_timeout));

超时后recvfrom会直接返回，不会卡死线程，直接进入下一轮循环读取串口、发送新数据即可。

• 后续如果需要更高的收发效率，可以再引入select/poll做IO多路复用，但是必须先修正socket生命周期问题，否则任何IO模型都会出现异常。

3、MSG_DONTWAIT/setsockopt方案无效的原因 #

你之前尝试非阻塞模式、socket配置不生效的核心原因是：所有socket配置都是和单个socket句柄绑定的，你在循环内每次新建socket，刚给新socket设置完参数，收发完成就立刻关闭，下一轮新建的socket又会回到默认阻塞模式。同时非阻塞模式只能解决「线程不卡死」的问题，解决不了端口占用、报文投递到已关闭socket的根因，就算开了非阻塞，你还是收不到有效数据，只会反复返回EAGAIN错误。

4、这类阻塞死锁场景的可靠调试方法 #

• 网卡抓包：两侧机器同时用tcpdump抓取2000端口的UDP报文，命令为tcpdump -i 对应网卡名 udp port 2000 -n，阻塞时直接看报文有没有发出去、源/目的端口是否正确、有没有回包，1分钟就能定位是发送侧问题还是接收侧问题。
• 全链路错误日志：所有系统调用（socket/bind/sendto/recvfrom）的返回值必须做判断，失败时打印errno和对应的错误描述（用strerror(errno)转成可读字符串），不要静默跳过错误或者直接exit进程，比如bind失败时打日志马上就能发现是IP配置错误还是端口被占用。
• socket状态排查：阻塞时用ss -anp | grep 2000命令查看socket状态，如果看到大量TIME_WAIT/CLOSE状态的残留socket，就说明socket生命周期逻辑写的有问题。
• 最小逻辑验证：先把串口、EtherCAT相关逻辑全部旁路掉，写一个最小的UDP双向收发demo，确认网络连通、收发逻辑正常后，再把业务逻辑加回去，避免业务逻辑和网络逻辑的问题混在一起排查。

内容的提问来源于stack exchange，提问作者Hilal Abu-Saleh