Add Extended MPTCP (Multipath TCP) Socket Option Support to OpenJDK

Geliang Tang geliang at kernel.org
Thu Oct 9 02:44:17 UTC 2025


Hi Jaikiran, Alan,

Thank you for your reply, and I'm sorry for my delayed response.

On Tue, 2025-09-23 at 21:33 +0530, Jaikiran Pai wrote:
> Hello Geliang,
> 
> Just a few initial observations:
> 
> On 23/09/25 3:04 pm, Geliang Tang wrote:
> > Dear OpenJDK Maintainers,
> > 
> > We are writing to propose the integration of Multipath TCP (MPTCP)
> > support into OpenJDK. In response to Alan's feedback in earlier
> > discussions [1], we have developed a Java-based implementation that
> > utilizes the setOption method to enable MPTCP before binding or
> > connecting a socket, as illustrated below:
> > 
> >    Socket c = new Socket();
> >    c.setOption(ExtendedSocketOptions.TCP_MPTCPIFY, true);
> >    c.connect(new InetSocketAddress(loop.getHostAddress(), port));
> > 
> > The name 'TCP_MPTCPIFY' was chosen to align with 'mptcpize' tool in
> > mptcpd and 'mptcpify' in BCC. The complete implementation can be
> > found
> > in [2].
> I realize it's still a bit early to discuss naming of this option,
> but 
> if we do go ahead with this approach of introducing an 
> ExtendedSocketOption, then maybe calling it TCP_MULTIPATH might be
> more 
> suitable.

Thank you for your suggestion. I agree that TCP_MULTIPATH is a better
name, and I will adopt it in future versions.

> > This email outlines the technical background and aims to facilitate
> > further discussion on the proposed approach.
> 
> Looking at the linked github diff in your mail, the biggest
> difference 
> between existing (Extended)SocketOptions and this new proposed one is
> that, as far as I can tell, this new one isn't a socket option and 
> instead is a protocol value that is used when constructing the
> socket():
> 
>  > fdm = socket(domain, type, IPPROTO_MPTCP);
> 
> I don't yet know if fitting this into the existing
> ExtendedSocketOptions 
> may end up being tricky for long term maintenance of this (internal) 

I apologize for forgetting to provide some historical version
information here. The initial version of OpenJDK MPTCP was indeed
implemented by extending Java_sun_nio_ch_Net_socket0. The complete
modifications can be viewed here:

https://patchwork.kernel.org/project/mptcp/cover/cover.1756369940.git.tanggeliang@kylinos.cn

The drawback is that it modified the standard API of
Socket/ServerSocket.

Therefore, following Alan's suggestion, we referenced
Java_sun_net_sdp_SdpSupport_convert0 and implemented this version that
supports MPTCP through Socket Options.

> API. The other question this raises is, are applications allowed to
> call 
> Socket.getOption(...) for this option and then expect it to return 
> true/false depending on whether multicast TCP was set for that
> socket? I 
> briefly glanced at the proposed diff and I couldn't spot any changes
> in 
> the ExtendedSocketOptions.getOption(...) code to deal with this
> option. 
> But that too I think is a trivial thing for later.

Thank you for the reminder. I will consider implementing getOption in
future versions.

> 
> The bigger question, I think, is whether constructing a "socket()"
> with 
> a specific "protocol" value in this manner by trying to adjust the 
> implementation in the code which deals with socket options is the
> right 
> thing to do. I realize that this proposal of prototyping it as a
> socket 
> option was suggested in response to your first email, so I am not
> saying 
> this direction should be abandoned, I just haven't fully grasped if
> this 
> can cause us problems with this approach.

By comparing the previous version that extended socket() with this
Socket Option-based version, we believe the latter is superior as it
involves minimal changes to the API and is easier to maintain.

> 
> I have several other questions, both implementation details as well
> as 
> the basics of multipath TCP, but I haven't yet read up on all the 
> material that's been linked in your email. So I'll catch up on that
> first.

Looking forward to more of your suggestions. Thank you very much.

-Geliang

> 
> -Jaikiran
> 



More information about the net-dev mailing list