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.
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)
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.
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.
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.
-Jaikiran
