Re: clisp-cvs Digest, Vol 59, Issue 7 - econnreset

[Sam S. <sd...@gn...>]

> * Don Cohen <qba...@vf...> [2011-04-11 10:31:12 -0700]:
>
> My first suggested patch would be to move this statement close to the
> top of the doc.
>   This is the interface to select (on some platforms, poll) ...

we specify the underlying posix call at the _end_ of the docs for each function.

> http://pubs.opengroup.org/onlinepubs/009695399/ is not very helpful
> here.  It says
>
>   If a socket has a pending error, it shall be considered to have an
>   exceptional condition pending. Otherwise, what constitutes an
> What counts as a pending error?  RST?  EOF?

RST is an error; EOF is not.

>   exceptional condition is file type-specific. For a file descriptor for
>   use with a socket, it is protocol-specific except as noted below. For
>   other file types it is implementation-defined.
> And then below:
>   A socket shall be considered to have an exceptional condition
>   pending if [...  out-of-band data is pending]
> (I don't think I've ever even heard of the OOB feature being used.)
>   Other circumstances under which a socket may be considered to have
>   an exceptional condition pending are protocol-specific and
>   implementation-defined.
>
> So I still have no ideas how to cause socket-status to return :error
> other than possibly trying to send OOB data.
> If any are known or discovered, I'd appreciate some mention of them
> in impnotes, and if none are known, it might be worth mentioning that
> as well.

This is best discussed on comp.protocols.tcp-ip
Please _do_ take this discussion there, and report back with your findings.

> Also, it occurs to me to ask about this statement:
>   Additionally, for a SOCKET:SOCKET-STREAM, we define status in the
>   given direction (one of :INPUT, :OUTPUT, and :IO) to be
> Does all this apply as well to other (non-socket) streams?
> If you're just calling select, I'd expect so.  In which case the
> statement should be generalized.

we already say at the end of the doc that this is applicable to any
FD-based stream.

>  Note that SOCKET:SOCKET-STATUS may SIGNAL a STREAM-ERROR. This happens
>  if the SOCKET:SOCKET-STREAM receives an RST packet, see
>  tests/econnreset.lisp. 
> This seems weird.
> After the reset I get:
>  [45]> (socket-status s)
>
>  [../src/stream.d:6196] 
>  *** - UNIX error 104 (ECONNRESET): Connection reset by peer
>  The following restarts are available:
>  ABORT          :R1      Abort main loop
>
> but then 
>  Break 1 [46]> (socket-status s)
>  :APPEND ;
>  1
>  Break 1 [46]> 
>
> I'd have expected that the two successive calls (with no activity on
> the socket in between) would have acted the same.

again, comp.protocols.tcp-ip is your friend.
the translation for them:
- why does select() return -1 and set errno=ECONNRESET instead of
returning the socket in the errorfds set?

>  > Actually, the fact that select() does not set the error bit for the
>  > socket appears to indicate that the socket is not completely and
>  > terminally dead after ECONNRESET.
>
> Is "completely and terminally dead" supposed to be a technical term?

what I mean is that no communication will ever be possible over the
socket.

> It is clear that after a reset you can't get more input or send more
> output on the stream.

It is not obvious to me.
RFC793 describes situations when the recipient of RST goes into LISTEN
and not ABORT states.

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.5 (Final) X
http://dhimmi.com http://ffii.org http://palestinefacts.org
http://pmw.org.il http://iris.org.il http://www.memritv.org
You can have it good, soon or cheap.  Pick two...