JDK-8221487 : Socket.setTrafficClass hides errors setting IP_TOS on a connected Socket, setOption does not
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 13
  • Priority: P4
  • Status: Closed
  • Resolution: Not an Issue
  • Submitted: 2019-03-26
  • Updated: 2024-04-07
  • Resolved: 2024-04-07
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.
Other
tbdResolved
Related Reports
Relates :  
JDK-8072384 - Setting IP_TOS on java.net sockets not working on unix
Relates :  
JDK-8221481 - Reimplement the Legacy Socket API
Description
Changing the value of the IP_TOS or IPV6_TCLASS socket options on a TCP socket that is already connected is implementation specific, and in many cases doesn't really make sense. However, if attempted and the setting the options fails (it fails on Solaris) then the error is swallowed by Socket setTrafficClass(value) but is not swallowed by setOption(IP_TOS, value). This inconsistency surfaces when when PlainSocketImpl is replaced with an alternative implementation. The issue has been patched in the niosocketimpl-branch, and tracked here so that it can be examined on its own.
Comments
The Solaris port was removed in JDK 15. The exception swallowing code was removed as part of re-work in JDK-8278326 so I think this issue can be closed.
07-04-2024
The exception swallowing behaviour mentioned in the description was introduced by JDK-8072384.
28-03-2019
Relevant section from Socket::setTrafficClass * As RFC 1122 section 4.2.4.2 indicates, a compliant TCP * implementation should, but is not required to, let application * change the TOS field during the lifetime of a connection. * So whether the type-of-service field can be changed after the * TCP connection has been established depends on the implementation * in the underlying platform. Applications should not assume that * they can change the TOS field after the connection. RFC 1122 section 4.2.4.2: 4.2.4.2 Type-of-Service The application layer MUST be able to specify the Type-of- Service (TOS) for segments that are sent on a connection. It not required, but the application SHOULD be able to change the TOS during the connection lifetime. TCP SHOULD pass the current TOS value without change to the IP layer, when it sends segments on the connection. The TOS will be specified independently in each direction on the connection, so that the receiver application will specify the TOS used for ACK segments. TCP MAY pass the most recently received TOS up to the application. DISCUSSION Some applications (e.g., SMTP) change the nature of their communication during the lifetime of a connection, and therefore would like to change the TOS specification. Note also that the OPEN call specified in RFC-793 includes a parameter ("options") in which the caller can specify IP options such as source route, record route, or timestamp.
28-03-2019