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

[<don...@is...>]

Sam Steingold writes:
 > > * 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.

The meaning of :error is hard to describe without referring to select.
Are forward references allowed?

 > > 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.
In that case, rst should cause socket-status to return :error, right?

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

I don't think this is a tcp question.  I think it's more like posix.
Or perhaps even more specific, linux, windows, etc.

 > > 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.
That's not a good excuse for the text above to be misleadingly over
specific. 

 > >  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?
Again, this is not related to tcp (or ip), but to the OS interface.
BTW, is windows supposed to be posix compliant?  (I assume linux is?)

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

Perhaps we should not use the term "socket" here but "connection".
When you go into listen state you're looking for requests to start
new connections.  Another request to start a connection on the same
socket may succeed, even from the same port on the same peer ip
address, but it will be a new connection.  You're supposed to send a
reset for a connection when that connection, as far as you are
concerned, is already dead, or never existed to begin with.