>The distinction I intended to address is between a connection setup timeout >and a confirmed loss of contact with the peer. A short timeout also expires >when the peer is reachable but acceptance is delayed, That can be addressed by "retry" as I suggested.
> whereas this change >reports EHOSTUNREACH once the node-loss path has determined that no >usable link remains. I do not think it is needed. User applications can subscribe for node-loss event. When no link is up, subscribed process will receive the loss event. This process can close the waiting/blocking socket. > >Also, from the current code, a connection-wait timeout leaves the socket in >TIPC_CONNECTING. Calling blocking connect() again on that socket continues >waiting for the pending handshake rather than starting a fresh attempt This behavior is expected and we will not allow a fresh connection from a waiting/blocking socket to avoid buffer-overload at listening socket/server. >To confirm the test scale, did you mean 4,000 concurrent connection attempts? Yes.
