recvfromrecvfrom为什么一直被阻塞

使用recvfrom接收UDP包在Windows和Linux平台的不同表现

操作系统的UDP接收流程如下：收到一个UDP包后，验证没有错误后，放入一个包队列中，队列中的每一个元素就是一个完整的UDP包。

当应用程序通过recvfrom()读取时，OS把相应的一个完整UDP包取出，然后拷贝到用户提供的内存中，物理用户提供的内存大小是多少，OS都会完整取出一个UDP包。

如果用户提供的内存小于这个UDP包的大小，那么在填充慢内存后，UDP包剩余的部分就会被丢弃，以后再也无法取回。

这与TCP接收完全不同，TCP没有完整包的概念，也没有边界，OS只会取出用户要求的大小，剩余的仍然保留在OS中，下次还可以继续取出。

socket编程虽然是事实上的标准，而且不同平台提供的接口函数也非常类似，但毕竟它不存在严格的标准。

所以各个平台的实现也不完全兼容。

下面就从recvfrom()这个函数看看Window平台和Linux平台的不同。

Windows平台的表现 int WSAAPI recvfrom( _In_ SOCKET s, _Out_writes_bytes_to_(len, return) __out_data_source(NETWORK) char FAR * buf, _In_ int len, _In_ int flags, _Out_writes_bytes_to_opt_(*fromlen, *fromlen) struct sockaddr FAR * from, _Inout_opt_ int FAR * fromlen ); 再看MSDN说明: If the datagram or message is larger than the buffer specified, the buffer is filled with the first part of the datagram, and recvfrom generates the error WSAEMSGSIZE. For unreliable protocols (for example, UDP) the excess data is lost. 可以看出，buf大小小于UDP包大小的时候，recvfrom()会返回-1，并设置错误WSAEMSGSIZE。

实际编程测试验证确实是这样的表现。

Linux平台的表现 __extern_always_inline ssize_t recvfrom (int __fd, void *__restrict __buf, size_t __n, int __flags, __SOCKADDR_ARG __addr, socklen_t *__restrict __addr_len) 可以看出与Windows平台的函数原型相同。

但是在其man手册里，没有看到UDP包大于接收缓冲区情况的特殊说明。

写代码测试表明，buf小于UDP包大小的时候，recvfrom()仍然返回复制到缓冲区的字节数，调用者无法得知UDP包被截断的情况。

调用方式标志位什么意思 recvfrom

recv的recvfrom是可以替换使用的，只是recvfrom多了两个参数，可以用来接收对端的地址信息，这个对于udp这种无连接的，可以很方便地进行回复。

而换过来如果你在udp当中也使用recv，那么就不知道该回复给谁了，如果你不需要回复的话，也是可以使...

recvfrom为什么一直被阻塞

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

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