<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div class="moz-cite-prefix">On 05/09/2025 09:43, Geliang Tang
wrote:<br>
</div>
<blockquote type="cite" cite="mid:da3912a3e0b03974305513219621856d33f82219.camel@kernel.org">
<pre wrap="" class="moz-quote-pre">:
3. Proposed Java API Changes
The goal is to allow Java applications to opt-in to using MPTCP when
creating sockets, without breaking existing code. The proposed changes
are additive and backward-compatible.
The core idea is to add a boolean mptcp parameter through the API
layers, from the public Socket class down to the native system call.
</pre>
</blockquote>
<br>
(moving the discussion to nio-dev and net-dev).<br>
<br>
Adding new constructors to legacy Socket/ServerSocket may work for
your initial prototype but would be problematic to propose as it
would bake non-standard features into the standard API. Also many
high performance servers use SocketChannel rather than Socket.<br>
<br>
One suggestion for a next prototype is to model the enablement of
MultiPath TCP as as a JDK-specific socket option (see
jdk.net.ExtendingSocketOptions). All of the standard APIs for
networking sockets define a setOption method for setting socket
options. If modeled as a socket option then enabling can create a
new AF_INET6/SOCK_STREAM/IPPROTO_MPTCP socket and then dup2 it into
place so that the original AF_INET6/SOCK_STREAM/0 socket is closed.
Enabling can be made to fail if the socket is already bound. It
could copy over existing socket options if needed. Look at the
built-in (and no longer used) SDP support for an example that does
similar with AF_INET_SDP/SOCK_STREAM/0. The only API surface would
be a socket option defined in jdk.net.ExtendingSocketOptions.<br>
<br>
-Alan<br>
<br>
</body>
</html>