This is the second patch. Some of your comments in it were useful to raise some concerns about issues that could be difficult to address, namely about the hard-coded use of IPPROTO_TCP at some places where you'd have preferred to use protocol->sock_prot, but this one is not correct since we're still hijacking the tcpv4 entry.
This also means we won't be able to pass such sockets across reloads, by the way. So that led me to think about a possible variant of the approach that could further simplify the patch. What if we duplicate protocol_tcpv4 and protocol_tcpv6 to protocol_mptcpv4 and protocol_mptcpv6, and just change the sock_prot there ? We'll need a new discriminant. We can either create a new dummy sock_domain like we did for sockpair, so we could have AF_MPTCP4 and AF_MPTCP6 and make sure the families are properly set where used. Or cleaner, we'd add an extra dimension to the protocols array to take care of the proto_type variant. We could consider that all regular protocols use 0 and that mptcp uses 1, so that we don't inflate the array that much (and that's not much different from what was done in the kernel where IPPROTO_MPTCP=262 is just IPPROTO_TCP with an extra bit set that's easy to mask). The benefit with this is that you drop the rx/listener option, you don't need to parse another keyword that comes too late in the process, you just have to recognize two new address family prefixes "mptcp4" and "mptcp6" to be used on bind lines like this: bind [email protected]:443 ... and that's all. The change is to be operated in str2sa_range() to take into account this new ipproto_type dimension. By the way I think that in order to avoid any difficulty in the future, instead of thinking in terms of ipproto_type we could think in terms of "protocol variant". That would be the last dimension of the protocols[] array, and we'd add this "variant" in the protocol struct so that when you have your protocol, you can easily look up other info from there. This "variant" would then always be zero except for mptcp4/6 which would have 1, and would likely be sufficient for a few more decades. Another nice benefit is that doing so will instantly provide whatever is needed to: - pass FDs from one process to the new one - support mptcp on the backend I'm seeing that you had to disable the error on TCP_NODELAY, mentioning that it's not yet supported by MPTCP. Does this just mean that it's always on by default ? I'm asking because being forced to support nagle is a no-go for any low-latency protocol: you can't afford to wait 200ms after sending a request that the stack decides to finally send it. Be careful with the doc: + Is an optional keyword which enables Multicast TCP (RFC 8584). Multicast TCP As you know it's "multipath" not "multicast" :-) And the RFC is 8684. Thanks! Willy
