It is the same situation.  Take my example and connect()
to the same address if you like and the behaviour is
the same.  The second connect() (after the ECONREFUSED)
fails with EINVAL.  Once again, the issue is that
the RST handling calls tcp_drop() which calls tcp_close()
which in turn disassociates the socket from the protocol
(in_pcbdetach() etc.).

As an aside. The man pages for connect(2) and also Posix
state that a non blocking connect should be writable on
completion.  The code shows readable and writeable:

-seanb


Index: kern/uipc_socket2.c
===================================================================
RCS file: /cvsroot/src/sys/kern/uipc_socket2.c,v
retrieving revision 1.54
diff -c -r1.54 uipc_socket2.c
*** kern/uipc_socket2.c	2003/08/07 16:31:59	1.54
--- kern/uipc_socket2.c	2003/08/19 13:26:48
***************
*** 110,116 ****
  		wakeup((caddr_t)&head->so_timeo);
  	} else {
  		wakeup((caddr_t)&so->so_timeo);
! 		sorwakeup(so);
  		sowwakeup(so);
  	}
  }
--- 110,116 ----
  		wakeup((caddr_t)&head->so_timeo);
  	} else {
  		wakeup((caddr_t)&so->so_timeo);
! //		sorwakeup(so);
  		sowwakeup(so);
  	}
  }

On Wed, Aug 20, 2003 at 12:32:20PM +0900, Takahiro Kambe wrote:
> In message <20030819134900.GA27340845@qnx.com>
> 	on Tue, 19 Aug 2003 09:49:00 -0400,
> 	Sean Boudreau <seanb@qnx.com> wrote:
> > This ties in with the observation I raised in tech-net
> > on June 17 WRT not being able to call connect() again after
> > ECONREFUSED.  It didn't generate much debate at the time.
> It isn't the same situtation.  I don't want to connect() another
> destination socket address after ECONREFUSED error at all.
> 
> My point is:
> 
> o the case of using non-blocking I/O.
> o repeating connect() to the same destination for checking it
>   completed or not after EINPROGRESS error.
> 
> When using non-blocking I/O, connect() is expected to behave as:
> 
> 1. first connect() results error with EINPROGRESS.
> 2. following connect() results error with:
> 
> 	EALREADY	still operation is in progress
> 	EISCONN		connection is established (connect success)
> 	really error	ECONNREFUSED or other error
> 
>    But currently EINVAL may happen, not described in connect(2).
> 
> Other interpertation, connect() is expected to behave as:
> 
> 1. first connect() results error with EINPROGRESS.
> 2. following connect() results error with:
> 
> 	EALREADY	still operation is in progress
> 	EISCONN		connection is established (connect success)
> 	EINVAL		real error status should be fetch with
> 			getsockopt(2) (SOL_SOKCET/SO_ERROR).
> 
>    Thus current connect(2)'s documentation is wrong?
> 
> -- 
> Takahiro Kambe <taca@back-street.net>
>