Fixed incorrectly interpreted error from WSARecvFrom on Windows #124
Conversation
srtcore/channel.cpp
Outdated
| @@ -441,6 +441,45 @@ EReadStatus CChannel::recvfrom(sockaddr* addr, CPacket& packet) const | |||
|
|
|||
| int res = ::recvmsg(m_iSocket, &mh, 0); | |||
| int msg_flags = mh.msg_flags; | |||
|
|
|||
|
|
|||
| // Note that there are exactly four groups of possible errors | |||
There was a problem hiding this comment.
idents for the entire block below
srtcore/channel.cpp
Outdated
| int res = ::WSARecvFrom(m_iSocket, (LPWSABUF)packet.m_PacketVector, 2, &size, &flag, addr, &addrsize, NULL, NULL); | ||
| res = (0 == res) ? size : -1; | ||
| int sockerror = ::WSARecvFrom(m_iSocket, (LPWSABUF)packet.m_PacketVector, 2, &size, &flag, addr, &addrsize, NULL, NULL); | ||
| int res = (0 == sockerror) ? size : -1; |
There was a problem hiding this comment.
Reindented whole function
srtcore/channel.cpp
Outdated
| // WSAETIMEDOUT, which isn't mentioned in the documentation of WSARecvFrom at all. | ||
| int err = NET_ERROR; | ||
| LOGC(mglog.Debug) << CONID() << "(sys)WSARecvFrom: " << SysStrError(err) << " [" << err << "]"; | ||
| status = RST_AGAIN; |
There was a problem hiding this comment.
What will happen if network goes away, ex. cable gets unplugged?
Why not put a switch here that checks for relevant error codes reported by WSAGetLastError() in case an error?
There was a problem hiding this comment.
This is completely explained in the initial description. In case when the network goes down, the reader will retry reading indefinitely - which is how the older version were behaving (with the difference that stransmit on Windows also doesn't implement the data passing timeout feature correctly due to nonexistent alarm()). Of course, this should be fixed, but the fix that is needed for Windows here is much bigger and deserves a more effort consuming activity (everything is explained in comments around it).
|
Thank you @ethouris ! |
There was a change added to error interpretation from
recvmsgsystem call, but this was unfortunately added the same way for the Windows system call ofWSARecvFrom. It uses completely different set of error codes (this should be further studied, but the Windows implementation also needs strong refactoring, so this is temporarily put aside). Just to clear the problem, the "old way" is used on windows, that is, every error reported byWSARecvFromis treated as a "potential AGAIN" situation.