Add Multipath TCP (MPTCP) Support to the Java Networking API

[Geliang Tang]

Hi Alan,

On Fri, 2025-09-05 at 18:11 +0800, Geliang Tang wrote:
> Hi Alan,
> 
> Thanks for your reply.
> 
> On Fri, 2025-09-05 at 10:28 +0100, Alan Bateman wrote:
> >  
> > On 05/09/2025 09:43, Geliang Tang wrote:
> >  
> >  
> > >  
> > > :
> > > 
> > > 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.
> > >  
> >  
> >  (moving the discussion to nio-dev and net-dev).
> >  
> >  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.
> >  
> >  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
> 
> I was initially concerned that calling setOption() after Socket()
> creation to convert TCP to MPTCP was too late. Creating an MPTCP
> socket
> must be done during the socket() system call.
> 
> > 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
> 
> Until I saw here, it should be feasible if the socket can be created
> again and dup when calling setOption().
> 
> I will try to reimplement MPTCP support using
> jdk.net.ExtendingSocketOptions soon and give you feedback.

I have completed the implementation. Thanks to Xiang Gao and Gang Yan
for their help. I added a new option named TCP_MPTCPIFY in
jdk.net.ExtendedSocketOptions (the name was chosen to align with
'mptcpize' tool in mptcpd and 'mptcpify' in BCC). When this option is
set, it calls the JNI function mptcpify0.

Following your suggestion, mptcpify0 is implemented by referencing
Java_sun_net_sdp_SdpSupport_convert0. It creates a new MPTCP socket,
uses dup2 to duplicate it, and then closes the redundant socket.

I have added your tag in the patch:

Suggested-by: Alan Bateman <alan.bateman at oracle.com>

I also included a test example for this option. All modifications can
be found here:

https://github.com/openjdk/jdk/compare/master...geliangtang:jdk:master

Please provide any feedback or suggestions. As for the next steps,
should I create a new issue for this feature and submit a proper pull
request?

Thanks,
-Geliang

> 
> Thanks,
> -Geliang
> 
> > 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.
> >  
> >  -Alan
> >  
> >