> 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
