Fix epoll bug when receiving zero-sized datagrams #12644
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Motivation: Datagrams are allowed to be empty when sent over UNIX or INET sockets. In such cases, we cannot use "received zero bytes" as a signal that no packets were received. Modification: When we receive a zero-sized datagram, tell the EpollRecvByteAllocatorHandle that we really received one byte, because the allocation handles use zero as an end-of-data signal. Such signals will put the event loop to rest, which is wrong because we don't know at this point if there are more packets to process. Use the absence of a sender-point as signal that no packets were read from recvmsg(2), and then continue to use -1 as the end-of-data signal to allocation handle. Add a DatagramUnicastTest to verify that we can receive multiple empty datagrams in a row without the eventloop mistakenly going to sleep. Result: Robust handling of zero-sized datagrams in the epoll transport.
…does not support domain sockets
chrisvest
force-pushed
the
41-empty-dgram
branch
from
cf45a6e
to
a443211
Compare
…mPacket does not support domain sockets" This reverts commit a443211.
… the JDK DatagramPacket class As of JDK 20, it still does not support UNIX addresses, but some day it might.
…er, and not a mix
chrisvest
added a commit
to chrisvest/netty
that referenced
this pull request
Jul 29, 2022
This is a forward port of netty#12644. Motivation: Datagrams are allowed to be empty when sent over UNIX or INET sockets. In such cases, we cannot use "received zero bytes" as a signal that no packets were received. Modification: When we receive a zero-sized datagram, tell the EpollRecvByteAllocatorHandle that we really received one byte, because the allocation handles use zero as an end-of-data signal. Such signals will put the event loop to rest, which is wrong because we don't know at this point if there are more packets to process. Use the absence of a sender-point as signal that no packets were read from recvmsg(2), and then continue to use -1 as the end-of-data signal to allocation handle. Add a DatagramUnicastTest to verify that we can receive multiple empty datagrams in a row without the eventloop mistakenly going to sleep. The JDK DatagramSocket and DatagramPacket do not currently support UNIX sockets, so the test catches those specific exceptions and bails out in those cases. Result: Robust handling of zero-sized datagrams in the epoll transport.
chrisvest
added a commit
that referenced
this pull request
Jul 29, 2022
This is a forward port of #12644. Motivation: Datagrams are allowed to be empty when sent over UNIX or INET sockets. In such cases, we cannot use "received zero bytes" as a signal that no packets were received. Modification: When we receive a zero-sized datagram, tell the EpollRecvByteAllocatorHandle that we really received one byte, because the allocation handles use zero as an end-of-data signal. Such signals will put the event loop to rest, which is wrong because we don't know at this point if there are more packets to process. Use the absence of a sender-point as signal that no packets were read from recvmsg(2), and then continue to use -1 as the end-of-data signal to allocation handle. Add a DatagramUnicastTest to verify that we can receive multiple empty datagrams in a row without the eventloop mistakenly going to sleep. The JDK DatagramSocket and DatagramPacket do not currently support UNIX sockets, so the test catches those specific exceptions and bails out in those cases. Result: Robust handling of zero-sized datagrams in the epoll transport.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation:
Datagrams are allowed to be empty when sent over UNIX or INET sockets.
In such cases, we cannot use "received zero bytes" as a signal that no packets were received.
Modification:
When we receive a zero-sized datagram, tell the EpollRecvByteAllocatorHandle that we really received one byte, because the allocation handles use zero as an end-of-data signal.
Such signals will put the event loop to rest, which is wrong because we don't know at this point if there are more packets to process.
Use the absence of a sender-point as signal that no packets were read from recvmsg(2), and then continue to use -1 as the end-of-data signal to allocation handle.
Add a DatagramUnicastTest to verify that we can receive multiple empty datagrams in a row without the eventloop mistakenly going to sleep.
Result:
Robust handling of zero-sized datagrams in the epoll transport.