std.posix.AcceptError.ConnectionAborted vs ConnectionResetByPeer

Help
1

Hi, I wonder what’s the difference between std.posix.AcceptError.ConnectionAborted and ConnectionResetByPeer.

Documentation says:

ConnectionResetByPeer
An incoming connection was indicated, but was subsequently terminated by the remote peer prior to accepting the call.

And no further documentation for ConnectionAborted.

But I would expect ConnectionAborted to be that error. From the manpage of FreeBSD for accept():

[ECONNABORTED]
A connection arrived, but it was closed while waiting on the listen queue.

So what are the differences between those two? When writing a server, should I do something like this?

const conn = server.accept() catch |err| {
    switch (err) {
        std.posix.AcceptError.ConnectionResetByPeer => continue,
        std.posix.AcceptError.ConnectionAborted => continue,
        else => return err,
    }
};

I.e. ignore both errors in a listening loop? Or just one of those?

2

All descriptions of the aborted error I can find are extremely vague.
It seems to be a catch-all for unrecoverable issues, that aren’t described by another error code.
I think it’s safe to assume aborted indicates a local issue in most cases.

Whereas reset by peer is quite specific, it means the connection was deliberately closed from the other end before the connection was established.

3

The best documentation is the source code. Here’s the error handling code within std.posix.accept.

  • error.ConnectionResetByPeer is only returned on Windows (translated from WSAECONNRESET
  • error.ConnectionAborted is only returned on non-Windows (translated from ECONNABORTED)

As for why they are named differently per-platform, I don’t have an answer. Error sets in the standard library haven’t gotten much attention yet, so they are pretty haphazard at the moment.

1 Like
4

I assume it wouldn’t be unreasonable if I opened an issue in that matter, right?

1 Like
5

Totally reasonable, go right ahead

6
1 Like