internal/socket: handle reordering in TestUDP/Messages #119
Conversation
TestUDP/Messages and TestUDP/Messages-dialed occasionally failed because the expected messages were not received in a single RecvMsgs call, or because the messages were received out of order. Assuming that both messages are returned immediately from a single RecvMsgs call was a flawed expectation. Fixed by repeatedly invoking RecvMsgs until all expected messages have been received. While it certainly seems unusual that packets are reordered on a loopback device, it does appear to happen occasionally (on linux-mips). Fixed by sizing receive buffers such that messages in any order can be received correctly, and by allowing either order for the reassembled message. Combine "Messages" and "Messages-dialed" subtests with a simple table-driven test, to avoid the repetition. The same "Message" and "Message-dialed". Finally, make the test failure messages slightly more useful. Fixes golang/go#49385
|
This PR (HEAD: d9df27b) has been imported to Gerrit for code review. Please visit https://go-review.googlesource.com/c/net/+/368094 to see it. Tip: You can toggle comments from me using the |
|
Message from Bryan C. Mills: Patch Set 1: Run-TryBot+1 Code-Review+1 Trust+1 Please don’t reply on this GitHub thread. Visit golang.org/cl/368094. |
|
Message from Go Bot: Patch Set 1: (1 comment) Please don’t reply on this GitHub thread. Visit golang.org/cl/368094. |
|
Message from Go Bot: Patch Set 1: TryBot-Result+1 (1 comment) Please don’t reply on this GitHub thread. Visit golang.org/cl/368094. |
TestUDP/Messages and TestUDP/Messages-dialed occasionally failed because the expected messages were not received in a single RecvMsgs call, or because the messages were received out of order. Assuming that both messages are returned immediately from a single RecvMsgs call was a flawed expectation. Fixed by repeatedly invoking RecvMsgs until all expected messages have been received. While it certainly seems unusual that packets are reordered on a loopback device, it does appear to happen occasionally (on linux-mips). Fixed by sizing receive buffers such that messages in any order can be received correctly, and by allowing either order for the reassembled message. Combine "Messages" and "Messages-dialed" subtests with a simple table-driven test, to avoid the repetition. The same "Message" and "Message-dialed". Finally, make the test failure messages slightly more useful. Fixes golang/go#49385 Change-Id: I04463c6ffdf4865d2ccfb8662ab4660bda3b3cbf GitHub-Last-Rev: d9df27b GitHub-Pull-Request: #119 Reviewed-on: https://go-review.googlesource.com/c/net/+/368094 Reviewed-by: Bryan C. Mills <[email protected]> Reviewed-by: Damien Neil <[email protected]> Trust: Bryan C. Mills <[email protected]> Run-TryBot: Bryan C. Mills <[email protected]> TryBot-Result: Go Bot <[email protected]>
|
This PR is being closed because golang.org/cl/368094 has been merged. |
TestUDP/Messages and TestUDP/Messages-dialed occasionally failed because
the expected messages were not received in a single RecvMsgs call, or
because the messages were received out of order.
Assuming that both messages are returned immediately from a single
RecvMsgs call was a flawed expectation. Fixed by repeatedly invoking
RecvMsgs until all expected messages have been received.
While it certainly seems unusual that packets are reordered on a
loopback device, it does appear to happen occasionally (on linux-mips).
Fixed by sizing receive buffers such that messages in any order can be
received correctly, and by allowing either order for the reassembled
message.
Combine "Messages" and "Messages-dialed" subtests with a simple
table-driven test, to avoid the repetition. The same "Message" and
"Message-dialed".
Finally, make the test failure messages slightly more useful.
Fixes golang/go#49385