It would appear that ECONNRESET means that the other side has closed the connection without reading outstanding data that has been sent to it, and can be triggered on both read() and write(). But the exact behavior depends on the operating system.
EPIPE
Seems to be triggered when one write()s to a socket that has already been closed, and there is no outstanding outgoing data. Applicable to both PF_LOCAL and TCP sockets. Example (Ruby):
a, b = UNIXSocket.pair
b.close
a.write("foo") # => EPIPE, on all OSes
read() returning 0
Triggered when the other side has closed the connection, and there is no outstanding outgoing data. Applicable to both PF_LOCAL and TCP sockets.
a, b = UNIXSocket.pair
b.close
a.read # => 0 bytes, on all OSes
ECONNRESET
On Linux it behaves like this:
Triggered when there's outstanding outgoing data that has not yet been written to the other side. read() triggers it for both PF_LOCAL and TCP sockets, but write() triggers it only for TCP sockets; PF_LOCAL sockets trigger EPIPE.
See examples for specific OS behavior. Please contribute if you know how other OSes behave.
Example 1: read() on PF_LOCAL socket
a, b = UNIXSocket.pair
a.write("hello")
b.close
a.read
# Linux: ECONNRESET
# OS X : returns 0 bytes
Example 2: read() on TCP socket
# Side A # Side B
s = TCPServer.new('127.0.0.1', 3001)
c = s.accept
c = TCPSocket.new('127.0.0.1', 3001)
c.write("hello")
c.close
c.read
# Linux: ECONNRESET
# OS X : returns 0 bytes
Example 3: write() on PF_LOCAL socket
a, b = UNIXSocket.pair
a.write("hello")
b.close
a.write("world")
# Linux: EPIPE and not ECONNRESET
# OS X : EPIPE and not ECONNRESET
Example 4: write() on TCP socket
# Side A # Side B
s = TCPServer.new('127.0.0.1', 3001)
c = s.accept
c = TCPSocket.new('127.0.0.1', 3001)
c.write("hello")
c.close
c.write("world")
# Linux: ECONNRESET
# OS X : no error