> From: Felipe Gasper <fel...@felipegasper.com>
> Sent: Wednesday, 2 November, 2022 12:46
> I wouldn’t normally expect EPIPE from a read operation. I get why it happens;
> it just seems odd. Given that it’s legitimate for a TLS peer to send the
> close_notify and then immediately do TCP close, it also seems like EPIPE is a
> “fact of life” here.

Yeah. That's because an OpenSSL "read" operation can do sends under the covers, 
and an OpenSSL "send" can do receives, in order to satisfy the requirements of 
TLS. Depending on the TLS version and cipher suite being used, it might need to 
do that for renegotiation or the like. Or if the socket is non-blocking you can 
get WANT_READ from a send and WANT_WRITE from a receive.

In your example it was actually a sendmsg that produced the EPIPE, but within 
the logical "read" operation.

The original idea of SSL was "just be a duplex bytestream service for the 
application", i.e. be socket-like; but that abstraction proved to be rather 
leaky. Much as sockets themselves are a leaky abstraction once you try to do 
anything non-trivial.

Michael Wojcik

Reply via email to