> On 21. May 2018, at 13:39, Neil Horman wrote: > > On Sun, May 20, 2018 at 10:54:04PM -0300, Marcelo Ricardo Leitner wrote: >> On Sun, May 20, 2018 at 08:50:59PM -0400, Neil Horman wrote: >>> On Sat, May 19, 2018 at 03:44:40PM +0800, Xin Long wrote: >>>> This feature is actually already supported by sk->sk_reuse which can be >>>> set by SO_REUSEADDR. But it's not working exactly as RFC6458 demands in >>>> section 8.1.27, like: >>>> >>>> - This option only supports one-to-one style SCTP sockets >>>> - This socket option must not be used after calling bind() >>>> or sctp_bindx(). >>>> >>>> Besides, SCTP_REUSE_PORT sockopt should be provided for user's programs. >>>> Otherwise, the programs with SCTP_REUSE_PORT from other systems will not >>>> work in linux. >>>> >>>> This patch reuses sk->sk_reuse and works pretty much as SO_REUSEADDR, >>>> just with some extra setup limitations that are neeeded when it is being >>>> enabled. >>>> >>>> "It should be noted that the behavior of the socket-level socket option >>>> to reuse ports and/or addresses for SCTP sockets is unspecified", so it >>>> leaves SO_REUSEADDR as is for the compatibility. >>>> >>>> Signed-off-by: Xin Long >>>> --- >>>> include/uapi/linux/sctp.h | 1 + >>>> net/sctp/socket.c | 48 +++++++++++++++++++++++++++++++++++++++++++++++ >>>> 2 files changed, 49 insertions(+) >>>> >>> A few things: >>> >>> 1) I agree with Tom, this feature is a complete duplication of the SK_REUSEPORT >>> socket option. I understand that this is an implementation of the option in the >>> RFC, but its definately a duplication of a feature, which makes several things >>> really messy. >>> >>> 2) The overloading of the sk_reuse opeion is a bad idea, for several reasons. >>> Chief among them is the behavioral interference between this patch and the >>> SO_REUSEADDR socket level option, that also sets this feature. If you set >>> sk_reuse via SO_REUSEADDR, you will set the SCTP port reuse feature regardless >>> of the bind or 1:1/1:m state of the socket. Vice versa, if you set this socket >>> option via the SCTP_PORT_REUSE option you will inadvertently turn on address >>> reuse for the socket. We can't do that. >> >> Given your comments, going a bit further here, one other big >> implication is that a port would never be able to be considered to >> fully meet SCTP standards regarding reuse because a rogue application >> may always abuse of the socket level opt to gain access to the port. >> >> IOW, the patch allows the application to use such restrictions against >> itself and nothing else, which undermines the patch idea. >> > Agreed. > >> I lack the knowledge on why the SCTP option was proposed in the RFC. I >> guess they had a good reason to add the restriction on 1:1/1:m style. >> Does the usage of the current imply in any risk to SCTP sockets? If >> yes, that would give some grounds for going forward with the SCTP >> option. >> > I'm also not privy to why the sctp option was proposed, though I expect that the > lack of standardization of SO_REUSEPORT probably had something to do with it. > As for the reasoning behind restriction to only 1:1 sockets, if I had to guess, > I would say it likely because it creates ordering difficulty at the application > level. > > CC-ing Michael Tuxen, who I believe had some input on this RFC. Hopefully he > can shed some light on this. Dear all, the reason this was added is to have a specified way to allow a system to behave like a client and server making use of the INIT collision. For 1-to-many style sockets you can do this by creating a socket, binding it, calling listen on it and trying to connect to the peer. For 1-to-1 style sockets you need two sockets for it. One listener and one you use to connect (and close it in case of failure, open a new one...). It was not clear if one can achieve this with SO_REUSEPORT and/or SO_REUSEADDR on all platforms. We left that unspecified. I hope this makes the intention clearer. Best regards Michael > > Neil > >>> >>> Its a bit frustrating, since SO_REUSEPORT is widely available on multiple >>> operating systems, but isn't standard (AFAIK). I would say however, given the >>> prevalence of the socket level option, we should likely advocate for the removal >>> of the sctp specific option, or at the least implement and document it as being >> >> Is it possible, to remove/deprecate an option once it is published on a RFC? >> >>> an alias for SO_REUSEPORT >>> >>> >>> As this stands however, its a NACK from me. >>> >>> Neil >>> >> > -- > To unsubscribe from this list: send the line "unsubscribe linux-sctp" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html