So the page says:

And this does in fact happen - even though some of your data was still waiting to be sent, or had been sent but not acknowledged: the kernel can close the whole connection.

But Stevens says:

By default, close returns immediately, but if there is any data still remaining in the socket send buffer, the system will try to deliver the data to the peer.

The SO_LINGER socket option lets us change this default.

And, referring to the default close behavior:

We assume that when the client’s data arrives, the server is temporarily busy, so the data is added to the socket receive buffer by its TCP. Similarly, the next segment, the client’s FIN, is also added to the socket receive buffer (in whatever manner the implementation records that a FIN has been received on the connection). But by default, the client’s close returns immediately. As we show in this scenario, the client’s close can return before the server reads the remaining data in its socket receive buffer. Therefore, it is possible for the server host to crash before the server application reads this remaining data, and the client application will never know.

Also:

If l_onoff is nonzero and l_linger is zero, TCP aborts the connection when it is closed. That is, TCP discards any data still remaining in the socket send buffer and sends an RST to the peer, not the normal four-packet connection termination sequence.

I’m having trouble reconciling this with the article’s position that data will be discarded by the sender OS with a plain non-SO_LINGER close().

I can see how the sender might be blissfully unaware that the receiver program might have crashed after the data had been sent and the connection had been closed, but before the data had arrived at the receiver program. And that’s where some kind of application ACKing mechanism might be in order.

I can also see that the receiver OS might happily collect the data and shutdown the socket correctly and then the sender app thinks everything is fine, but the receiver app has crashed and will never see the data.

But neither of those conditions result in the receiver app in the example showing less than 1,000,000 bytes received unless there’s an error.

What am I missing?