UDP 套接字上的 recvfrom() 返回 -1，但 WSAGetLastError() 返回 0
我似乎无法弄清楚为什么会发生这种情况。我没有使用任何可能调用 WSAGetLastError() 的套接字库，因为我只在 Windows 平台上使用 C 套接字函数。我正在使用 select() 来管理多个 UDP 套接字，所以也许这与它有关。事情是这样的：
我有许多 UDP 套接字，我用 fd_set 注册它们，并使用 select() 仅在读操作可用时进行检查。我遍历所有套接字并检查 FD_ISSET() 以确保读取操作可用。然后我调用recvfrom()，它似乎在大多数情况下都能工作，但偶尔当其中一个套接字上有一系列活动时，recvfrom() 将返回-1。当我随后调用 WSAGetLastError() 时，它返回 0（这是我整个应用程序中对 WSAGetLastError 的唯一调用）。如果我忽略该错误，套接字将继续正常运行。它仍然能够接收数据并完成其任务。这很奇怪。
我知道 UDP 套接字有可能返回 0（有效的空 UDP 数据包），而 TCP 则不然（干净关闭），但 -1 也可能是正常的吗？我认为这可能是由某种并发问题引起的，其中一个线程可能在套接字上执行 sendto() 而 receivevfrom() 正在被调用的过程中，所以我添加了一个互斥体来防止这种情况发生（但该行为仍然存在）。
我对整个问题很困惑，所以任何建议或帮助将不胜感激。也许 select() 为实际上不是读操作的读操作添加了套接字？我很确定 TCP 会对侦听套接字上的连接请求执行此操作。
我在 Visual Studio 2010 中使用 C++ 作为我的编译器和 IDE。这是一个控制台应用程序，没有 MFC 或任何垃圾。
谢谢！
I can't seem to figure out why this is happening. I'm not using any socket library that could be calling WSAGetLastError(), because I'm only using the C socket functions on a Windows platform. I am using select() to manage multiple UDP sockets, so perhaps that has something to do with it. Here's what's going on:
I have many UDP sockets that I register with a fd_set and use select() to check only when read operations are available. I iterate through all my sockets and check FD_ISSET() to make sure a read operation is available. I then make the call to recvfrom() which seems to work the majority of the time, but occasionally when there is a flurry of activity on one of the sockets, recvfrom() will return -1. When I make the subsequent call to WSAGetLastError(), it returns 0 (and this is the only call to WSAGetLastError in my entire application). If I ignore the error, the socket continues to function normally. It's able to recv data still and do its thing. It's just very strange.
I know it's possible for a UDP socket to return 0 (a valid empty UDP packet) which is not the case for TCP (clean shutdown), but could -1 also be normal possibly? I thought perhaps this was being caused by some kind of a concurrency issue, where one thread may be performing a sendto() on a socket while recvfrom() is in the process of being called, so I added a mutex to prevent this from occuring (yet the behavior is still present).
I'm quite confused on the whole matter, so any suggestions or help would be greatly appreciated. Perhaps select() adds sockets for read operations that really aren't read operations? I'm pretty sure TCP does that for connection requests on a listening socket.
I'm using C++ in Visual Studio 2010 as my compiler and IDE. This is a console application with no MFC or any of that crap.
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
好吧，-1 是 SOCKET_ERROR，所以不：-1 永远不是一个正常值。我唯一一次看到此错误的情况是，当您在 TCP 套接字上使用
accept，但随后在您调用accept的同一个套接字上调用recv时on，而不是accept调用的返回值。您确定失败的recvfrom是在正确的套接字上调用的吗？Well, -1 is
SOCKET_ERROR, so no: -1 is never a normal value. The only other time I've seen this error is when you useaccepton a TCP socket but then callrecvon same socket you calledaccepton, rather than the return value of theacceptcall. Are you sure yourrecvfromthat fails is being called on the correct socket?