1/ So for today's lesson on TCP/IP I want to talk about the SIGPIPE problem. It's why your code occasionally crashes in the field for no particular reason, and why we cannot masscan/nmap industrial control networks.
2/ I mention this because looking at the libSSH fixes (for reasons) I noticed that it recently had to fix the SIGPIPE issue. No matter how many decades experience we have with this problem, it keeps rearing its ugly head. 
3/ The source of this problem goes back to 1982 when the first TCP/IP programing API, known as "Sockets", was developed. They modeled it after files: a socket handle to a network connection is the same as a file handle for read/write on files.
4/ File handles were used for other things as well, such as "pipes", a stream of data between two processes. If the process on the other end of the pipe dies while you are trying to write it, it takes you with it by generating a SIGPIPE signal.
5/ Signals, when not caught with a handler, by default crash the program. This is probably what you want for pipe errors, such as when stringing together programs using the pipe | operator on the shell.
6/ But for network sockets, this behavior is extraordinarily bad and the opposite of what you want. Servers should never, ever crash just because one of the clients remotely on the network crashed. This is 100% the wrong behavior, not question.
7/ But most of the time, this isn't a problem. Even buggy stuff on the network rarely causes this ugly problem to rear its head. Clients rarely crash, and when they do, it's when the server is waiting for data with recv(), not trying to send data with send(), so no SIGPIPE.
8/ Pick up any text on TCP/IP or Sockets programming and while they usually mention SIGPIPE, but as some rare thing that programmers probably don't have to worry about. Yes, it's rare on any particular connection, but pretty much guaranteed to impact your code eventually.
9/ I can't find a single test on TCP/IP or Sockets programming that tells programmers the correct thing: that you must, 100% without fail, deal with the SIGPIPE problem. So this problem continues infest code three decades after it was identified as wrong.
10/ The solution is to configure a handler that ignores it. This should be part of all the Sockets code you write, including software that uses libraries without doing its own Sockets:
signal(SIGPIPE, SIG_IGN);
signal(SIGPIPE, SIG_IGN);
