Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix epoll bug when receiving zero-sized datagrams #12656

Merged
merged 1 commit into from Jul 29, 2022

Conversation

chrisvest
Copy link
Contributor

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.

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 chrisvest added this to the 5.0.0.Alpha5 milestone Jul 29, 2022
@chrisvest chrisvest marked this pull request as ready for review July 29, 2022 15:58
@chrisvest chrisvest merged commit 8cd73cf into netty:main Jul 29, 2022
@chrisvest chrisvest deleted the 5x-epoll-dgram branch July 29, 2022 16:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant