JDK-8239355 : (dc) Initial value of SO_SNDBUF should allow sending large datagrams (macOS)
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.nio
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-02-18
  • Updated: 2021-01-15
  • Resolved: 2020-03-12
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 15
11.0.11Fixed 15 b15Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Description
The default value of net.inet.udp.maxdgram on macOS is 9216 which limits the size of the datagram that can be sent by applications that don't set the SO_SNDBUF option. Legacy DatagramSocket sets the value to 65507 at creation time. Sending large datagrams will clearly require fragmentation so it's not optimal but there may be applications that depend on it (the patch to set the socket option to 65507 seems to come from the original Apple port).

The attached patch updates DatagramChannel so that the SO_SNDBUF is set to a minimum value of 65527 for IPv6 sockets and 65507 for IPv4 sockets.
Comments
On the grounds this is a mac only change and will likely not get noticed I've approved it.
15-01-2021

Thanks, [~alanb], for your comments. [~sgehwolf], after Alan's assesment I'm inclined to think that backporting this change is not a bad idea. Furthermore, since I've already gone through the backport steps including testing, I've added back the jdk11u-fix-request label. However, in case you are not convinced of approving, I won't insist.
15-01-2021

[~clanger] The issue has existed since JDK 1.4 but has not been reported, probably because sending jumbo size datagrams with DatagramChannel is rare and because sysctl can be used to change the default limit. The issue here was important for JDK 15+ due to the change to DatagramSocket to use a DatagramChannel under the covers. So not too interesting for releases prior to JDK 15, not wrong to back-port either as I doubt anyone will notice.
15-01-2021

So, [~alanb], what would be your advice regarding a potential backport to 11u? Is that something that can/should be done vs. modifying the failing test case?
15-01-2021

A CSR is not required for this change. The change is simply to increase the initial size of SO_SNDBUF from its default of 9216 to 64k so that maximal sized datagrams can be sent. The original port to macOS in JDK 7u4 did this for legacy sockets (see PlainDatagramSocketImpl.datagramSocketCreate) but didn't take the differences between IPv4 and IPv6 into account. It also completely missed DatagramChannel.
15-01-2021

[~sgehwolf] Thanks for pointing out the change of behaviour. Initially I thought this just fixes a bug but actually it is a change in behavior. Probably this should even have merited a CSR. So, while this change maybe ok for users, I think we should probably backport it unforced into an LTS, without having further information that it is beneficial for e.g. performance or otherwise in standard use cases. I'll have a look into modifying the test then.
14-01-2021

[~clanger] This would change behaviour of the default initial buffer size for datagram sockets. The reason to backport it is to get a clean test run. Has it been considered to go with Daniel's suggestion and disable the check in the test via a JDK 11-only patch?
14-01-2021

Fix Request (11u): Request backport to fix an issue on Mac, shown by a new test that came in with the backport of JDK-8243488. The original patch needed some modifications. Backport was reviewed/acked by Matthias: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-January/004578.html
14-01-2021

URL: https://hg.openjdk.java.net/jdk/jdk/rev/be3aeb6e766d User: pconcannon Date: 2020-03-12 17:34:26 +0000
12-03-2020