How do you treat ECONNRESET (i.e., RST packet)?
How do you want it to be treated?

Specifically, do you consider it roughly equivalent to (or a subset of)
EOF (i.e., FIN packet)?
(In particular, is it true that, once a TCP socket signaled ECONNRESET,
no data can be written there - or, if it can be written, it is
guaranteed that the recipient will not receive it - and nothing will
even be successfully read from it?)

I expect the answers to come in two groups:

1. I don't know and I don't care. This code:
   (with-open-stream (sock (socket-connect 80 "www.google.com"))
     (write-line "GET ...." sock)
     (loop :for line = (read-line sock nil nil) :while line
        :do ...))
   has always worked for me just fine.

Variants:
  A. same as above + "I actually always assumed that condition
     connection-reset was a subclass of end-of-file, that's why the
     above code works reliably"
  B. same as above + "I have to wrap READ-LINE above in IGNORE-ERRORS
     because I know that RST is not treated the same as FIN".

2. nope, ECONNRESET is an _error_ while EOF is a normal element of
   communications, so it should not be routinely ignored (or swept under
   the carpet by the EOF-P argument READ-LINE and friends), so the code
   above should be wrapped in HANDLER-BIND which restarts the connection
   on ECONNRESET (or something).

... but I am sure I missed some options.

There are more details on this here
https://sourceforge.net/tracker/?func=detail&aid=3276560&group_id=135...

http://books.google.com/books?id=ptSC4LpwGA0C&lpg=PA142&ots=Kr0zQmfkT...

Considering ECONNRESET is a possible value of errno, I think a CL
implementation should respond accordingly...

When the CL user makes a call that eventually triggers an errno, that
is the point where an error might be signalled.  This is somewhat
complicated by CL APIs that layer a stream over the file descriptor.
The stream may not have delivered everything that had been buffered...

I wonder how Java libraries handle this.

Should a stream read return all available data and then throw the
error on the next read?  Or should the error be delivered eagerly?  I
think the error should be delayed to the next application-level read,
but that might not be practical.

At the lowest level, it would be nice to have a raw binding to the
POSIX APIs.  At the high-level user API, this seems like a subclass of
file-error or stream-error, depending on the API.

That's my quick response.

ECONNRESET is an *error* when doing net programming in
any other language (e.g., in C). I don't see any reason
that CL should be any different in that regard.

-Rob

The question is whether ECONNRESET should be a subclass of CL:ERROR, or
a subclass of CL:CONDITION.

In the case of ECONNRESET it seems that it should be regarded as a
CL:ERROR, since receiving it indicates that the remote has unexpectedly
closed the connection and you cannot do more I/O.

On the other hand, if it was something you might need to know, but that
wouldn't make you stop normal processing, then SIGNALing a simple
condition would do (eg. receiving out-of-band data could be handled
signaling a non-ERROR, or even a non-SERIOUS-CONDITION condition.  But
this doesn't seem to apply to ECONNRESET.

I concur.

+---------------
| On the other hand, if it was something you might need to know, but that
| wouldn't make you stop normal processing, then SIGNALing a simple
| condition would do (eg. receiving out-of-band data could be handled
| signaling a non-ERROR, or even a non-SERIOUS-CONDITION condition.  But
| this doesn't seem to apply to ECONNRESET.
+---------------

Nope. ECONNRESET is a fatal error (at least w.r.t. that connection).

-Rob

http://www.lispworks.com/documentation/HyperSpec/Body/e_end_of.htm
Class Precedence List:
end-of-file, stream-error, error, serious-condition, condition, t

It is beyond any doubt that ECONNRESET is a STREAM-ERROR.
The _question_ is: is ECONNRESET a subclass of END-OF-FILE also?
Don Cohen argues that it is.  I think it is not.
Our respective arguments are expounded upon in the clisp RFE I referenced
and summarized in my original message.
I am sorry it was not clear.

So, I'd say, CONNECTION-RESET should be a subclass of STREAM-ERROR.

I concur with you, Tim, & Pascal. A STREAM-ERROR for sure,
but *not* a subclass of END-OF-FILE. The semantics are wrong.

-Rob

Pascal J. Bourguignon <p...@informatimago.com> wrote:
+---------------
| It is not an END-OF-FILE, because END-OF-FILE occurs when you are
| reading, but ECONNRESET occurs when you are writing.  It would be more
| like a OUT-OF-SPACE-IN-FILESYSTEM error, if there was one such.
+---------------

AFAIK, ECONNRESET doesn't *only* occur when you are writing.
It should be equally possible while reading as well.

IME, the most frequent error while *writing* to the net is EPIPE[1],
which is *very* commonly seen by web servers when the client browser
closes the connection before the full response has been sent. [This
happens *very* often on slow or high-delay connections when users
hit "Stop" or click on another link before the first page finishes
downloading.]

Finally, OUT-OF-SPACE-IN-FILESYSTEM errors generally give ENOSPC
(Linux, BSDs, other Unixes) or, if due to administrative limits,
EFBIG (Linux/BSD/Unix) or EDQUOT(FreeBSD).

The semantics of ECONNRESET feel more like plain ol' EIO to me.

[By the way, note that FreeBSD distinguishes ENETRESET, ECONNABORTED,
and ECONNRESET, as well as several other errors than can happen
mid-connection, e.g., ENETDOWN, ENETUNREACH, EHOSTDOWN, EHOSTUNREACH,
ETIMEDOUT, etc.]

-Rob

[1] Which, on Unix/Linux systems, if not ignored/caught, causes SIGPIPE! ;-}
    Thanks again to Dan Barlow, who once suggested simply *ignoring*
    SIGPIPE in CL-based web servers, and instead catching STREAM-ERROR
    on writes and silently ignoring it if caused by EPIPE [but logging
    other STREAM-ERRORs, of course].

Actually, it depends on what you mean by "the writer" here. If you
mean the user process [and "crash" as in core dump or unhandled signal],
in a Unix/Linux context that will just result in all its file descriptors
being closed [albeit w/o user-mode buffers being flushed first!], which
will look to the reader as a normal EOf.

But if by "the writer crashed" you mean the whole system containing the
sending process, then the reader would get *no* notification until either
the protocol stack in the receiving system gets a timeout [which might
cause an ECONNRESET?] or until the [former] writing system reboots and
later sends a RST to the receiving system when the latter sends probes
or ACKs for the "stale" connection which the newly-rebooted [former]
writing system doesn't think is open [which should, I think, cause an
ECONNRESET on the receiving side].

+---------------
| Though I'm actually confused about how this is discovered: the reader
| will presumably be sitting in ESTABLISHED, passively waiting for
| segments to arrive from the writer: what's the mechanism for the writer
| to discover that the reader is still there?  Is it just keepalives?
+---------------

I'm confused: Did you mean to ask "what's the mechanism for the *reader*
to discover that the *writer* is [or is not] still there?"? If the latter,
then, yes, keepalives, timeouts, etc.

-Rob

So now b is sitting there, thinking the connection is open, but a knows
nothing of it.  But because b is passively waiting, it's not sending
anything to a to prompt a to send it a RST.  Now my understanding gets
a bit vague, but I *think* the only two mechanisms that cause the
connection to get reset are:
- if TCP keepalives are in use, then b will at some point send a
keepalive to a which will then send an RST back;
- if there is an application-level timeout then at some point b will
give up, try and close the connection, and get a RST.

I think those are basically the choices. Oh, plus this one:

- If "a" [after rebooting] tries to initiate a new connection to "b"
  that happens to re-use the same port numbers as the "stale" connection
  on "b", then *b* might send a RST to "a" in reply to the initial SYN.
  Or "b" might just send an ACK, which probably won't match the SYN's
  sequence number, which could cause "a" to send a RST. Or something
  like that. [I'm not sure. It's been a while since I've walked through
  the TCP state diagram.]

-Rob

If it's in the window, b will send a RST, and the application on b
should be given an ECONNRESET error.

If it's outside the window, b will send an ACK containing the sequence
number of the beginning of the window.  When a receives this, it should
send a RST to b (it was expecting a SYN-ACK, not a plain ACK).  This
should then cause the application on b to get an ECONNRESET error.

So while the underlying details are different, the end result in either
case should be that the application gets ECONNRESET.