RE: [RFC net-next 1/2] tipc: abort pending connects when the peer node is lost

[Tung Quang Nguyen]

>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.