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