On 23/09/2025 17:03, Jaikiran Pai wrote:
:
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.
Just to point that using dup2 to "convert" the socket to IPPROTO_MPTCP
is the same trick that the JDK did for SDP. I think the main question is
whether it is compelling enough for the JDK to include, and if so, how
would it be tested and maintained.
I'm not too concerned about the API docs right now. As with all "socket
options", there are many details, esp. around state, that would need to
be specified. The JDK has several examples of options that don't support
both "set" and "get".
Another direction that would allow the existing APIs to be used if to
expose a restricted method to get at the raw file descriptor, something
we've toyed with several times. That approach would allow MPTCP to be
implemented as its own library, wouldn't need anything in the JDK, but
would require users to run with a CLI option to enable native access
(the current way to allow restricted methods).
-Alan.
