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/[email protected] 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 >
