On Mon, Jul 09, 2018 at 08:15:12AM -0400, Neil Horman wrote: > You can't restart a connect() system call because there may be packets on the > wire that are implementing the state transitions needed to establish the > connection you requested. Theres no way for the local system to determine if > that state transition has completed properly yet or not. Terminating the > connection as you are doing here leads to significant traffic overhead for what > might otherwise be in most cases a successfull connection. This is questionable as the reason for sending the signal can be a request to terminate the connection attempt. > Thats why Linux deviates from the > standard and return EINPROGRESS, and requires that you check the SO_ERROR value > to determine if the connection is successfull (SO_ERROR == 0), or if its still > pending (note in the connect man page that you can select/poll a in-progress > socket for writeability to determine completion of the connection operation). It's not a generic Linux problem as TCP doesn't suffer from this discrepancy, it exists only in linux-sctp. Also, this behavior is not documented anywhere. Current manual page in lksctp git explicitly says EINPROGRESS and EALREADY can be returned on non-blocking sockets only: EINPROGRESS The socket is non-blocking and the connection cannot be completed immediately. If you think this behavior is desired, then the manual page should be updated and say that EINPROGRESS and EALREADY can be also returned on a blocking socket if a signal was handled in the mean time. > Sorry, but this doesn't seem like its actually fixing anything. It's actually fixing several usecases: 1) SOCK_STREAM application uses alarm() to set a connection timeout (use of SO_SNDTIMEO is not portable) and expects the connection attempt to be terminated after the alarm is delivered. This applies mainly on ported TCP programs. These applications expect EINTR in a case of timeout, not EINPROGRESS. 2) SOCK_SEQPACKET application uses signals to implement different connect timeouts for different peers as usage of SO_SNDTIMEO is not thread safe. 3) Developer or administrator attaches gdb/strace to a process blocked in connect(), the application aborts as it doesn't expect to get EINPROGRESS on a blocking socket. To sum it up, the current documention and code are not aligned and one of them needs to be fixed. BR, Petr @Neil: Sorry for the double post, I forgot to include CC addresses. -- To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html