sctp: Remove special handling for a listen(2) backlog of 0

[markj]

Summary

This effectively reverts 94f66d603a74 ("Honor the backlog field.").
In particular, we always convert the socket to a listening socket
anyway, so with that change SCTP and the socket layer get out of sync.

I'm not sure why we need special handling for backlog == 0. Other
procotols do not do anything special there. According to POSIX the
meaning of that case is implementation-defined, and it appears that we
handle it by only permitting a single connection in the queue at a time.

[tuexen]

The Posix specification is generic, since, for the TCP case, you have to deal with two queues (at least conceptually).

For SCTP the situation is simpler. For 1-to-1 style sockets you have only single queue for SCTP association in the ESTABLISHED state. Therefore it makes sense that the backlog parameter is the maximum size of this queue. Having a backlog parameter of 0 then means you can't have any entries and therefore you can't accept any SCTP associations. That is the reason why it is specified that way in RFC 6458.

For 1-to-many style sockets, you don't have any queues, therefore the handling of the case of backlog of zero is modelled after the 1-to-1 style sockets, see RFC 6458.

Does this makes things clearer?

[markj]

In D31774#716954, @tuexen wrote:

The Posix specification is generic, since, for the TCP case, you have to deal with two queues (at least conceptually).

For SCTP the situation is simpler. For 1-to-1 style sockets you have only single queue for SCTP association in the ESTABLISHED state. Therefore it makes sense that the backlog parameter is the maximum size of this queue. Having a backlog parameter of 0 then means you can't have any entries and therefore you can't accept any SCTP associations. That is the reason why it is specified that way in RFC 6458.

For 1-to-many style sockets, you don't have any queues, therefore the handling of the case of backlog of zero is modelled after the 1-to-1 style sockets, see RFC 6458.

Does this makes things clearer?

Thanks for the explanation. Doesn't this mean that we only want to toggle PCB_FLAGS_ACCEPTING this way if the inp is UDP-type?

[tuexen]

In D31774#716957, @markj wrote:

In D31774#716954, @tuexen wrote:

The Posix specification is generic, since, for the TCP case, you have to deal with two queues (at least conceptually).

For SCTP the situation is simpler. For 1-to-1 style sockets you have only single queue for SCTP association in the ESTABLISHED state. Therefore it makes sense that the backlog parameter is the maximum size of this queue. Having a backlog parameter of 0 then means you can't have any entries and therefore you can't accept any SCTP associations. That is the reason why it is specified that way in RFC 6458.

For 1-to-many style sockets, you don't have any queues, therefore the handling of the case of backlog of zero is modelled after the 1-to-1 style sockets, see RFC 6458.

Does this makes things clearer?

Thanks for the explanation. Doesn't this mean that we only want to toggle PCB_FLAGS_ACCEPTING this way if the inp is UDP-type?

Wouldn't that mean that we would never handle incoming packets for a listening 1-to-1 style socket, since we use this flag in SCTP_IS_LISTENING() (see sctp_os_bsd.h:479)?

[markj]

In D31774#716978, @tuexen wrote:

In D31774#716957, @markj wrote:

In D31774#716954, @tuexen wrote:

The Posix specification is generic, since, for the TCP case, you have to deal with two queues (at least conceptually).

For SCTP the situation is simpler. For 1-to-1 style sockets you have only single queue for SCTP association in the ESTABLISHED state. Therefore it makes sense that the backlog parameter is the maximum size of this queue. Having a backlog parameter of 0 then means you can't have any entries and therefore you can't accept any SCTP associations. That is the reason why it is specified that way in RFC 6458.

For 1-to-many style sockets, you don't have any queues, therefore the handling of the case of backlog of zero is modelled after the 1-to-1 style sockets, see RFC 6458.

Does this makes things clearer?

Thanks for the explanation. Doesn't this mean that we only want to toggle PCB_FLAGS_ACCEPTING this way if the inp is UDP-type?

Wouldn't that mean that we would never handle incoming packets for a listening 1-to-1 style socket, since we use this flag in SCTP_IS_LISTENING() (see sctp_os_bsd.h:479)?

To be clear, I'm suggesting the following:

• For one-to-one sockets, always set SCTP_PCB_FLAGS_ACCEPTING in sctp_listen(). If listen(sd, 0) is called, rely on the queue length check to disallow new connections.
• For one-to-many sockets, let sctp_listen() toggle SCTP_PCB_FLAGS_ACCEPTING as it does today.

[tuexen]

In D31774#716990, @markj wrote:

In D31774#716978, @tuexen wrote:

In D31774#716957, @markj wrote:

In D31774#716954, @tuexen wrote:

The Posix specification is generic, since, for the TCP case, you have to deal with two queues (at least conceptually).

For SCTP the situation is simpler. For 1-to-1 style sockets you have only single queue for SCTP association in the ESTABLISHED state. Therefore it makes sense that the backlog parameter is the maximum size of this queue. Having a backlog parameter of 0 then means you can't have any entries and therefore you can't accept any SCTP associations. That is the reason why it is specified that way in RFC 6458.

For 1-to-many style sockets, you don't have any queues, therefore the handling of the case of backlog of zero is modelled after the 1-to-1 style sockets, see RFC 6458.

Does this makes things clearer?

Thanks for the explanation. Doesn't this mean that we only want to toggle PCB_FLAGS_ACCEPTING this way if the inp is UDP-type?

Wouldn't that mean that we would never handle incoming packets for a listening 1-to-1 style socket, since we use this flag in SCTP_IS_LISTENING() (see sctp_os_bsd.h:479)?

To be clear, I'm suggesting the following:

• For one-to-one sockets, always set SCTP_PCB_FLAGS_ACCEPTING in sctp_listen(). If listen(sd, 0) is called, rely on the queue length check to disallow new connections.
• For one-to-many sockets, let sctp_listen() toggle SCTP_PCB_FLAGS_ACCEPTING as it does today.

Ahh, OK. Now I see what you mean. Yepp, that should work. It might change the behaviour on the wire, but it is still compliant.

[markj]

Revert the change for one-to-many-style sockets.