
Why is my tcp not reliable? (2009) - CarolineW
https://blog.netherlabs.nl/articles/2009/01/18/the-ultimate-so_linger-page-or-why-is-my-tcp-not-reliable
======
Animats
It's a Berkeleyism. It's not TCP, it's old Berkeley Sockets semantics. The TCP
protocol supports half-close. When you're done writing you're supposed to
close your write side, then read until you get an EOF. But the Berkeley people
didn't support that.

Linux does support it, with the "shutdown(2)" call.[1] When you're done
writing, you shut down the write side. The other end sees an EOF, and they
close. You read to EOF, and you close. If shutdown and close return normally,
all data was delivered. Assuming this was implemented right.

[1] [http://man7.org/linux/man-
pages/man2/shutdown.2.html](http://man7.org/linux/man-
pages/man2/shutdown.2.html)

~~~
cperciva
_It 's a Berkeleyism. It's not TCP, it's old Berkeley Sockets semantics. [...]
Linux does support it, with the "shutdown(2)" call._

The shutdown(2) system call was added to BSD on January 8th, 1983:
[https://svnweb.freebsd.org/csrg?view=revision&revision=10208](https://svnweb.freebsd.org/csrg?view=revision&revision=10208)

So... Berkeley Sockets supported this a bit more than 8 years before Linux
even existed. This is totally not a Berkeley Sockets problem.

------
TwoBit
So if we could go back in time, could we create an interface that is less
ridden with pitfalls?

~~~
lkrubner
Do we need to go back in time? Can't we just start now, in 2017, to build
something better than what they finalized on back in the spring of 1978? Don't
we know more now than we did then? What are the forces that hold us back? If
those forces are political, can we fight them?

~~~
Chai-T-Rex
There are already things like SCTP.

------
benchaney
I've always thought that this is ridiculous. Once a TCP socket reports that
data has been sent, it should continue working to send it until every bytes
has been acked (with the exception of an unrecoverable failure case). Also, I
wish there were an API to detect how much data still hasn't been acked.

~~~
gmazza
> I wish there were an API to detect how much data still hasn't been acked.

From example code attached to the original article (Linux only):

    
    
      int outstanding;
      ioctl(fd, SIOCOUTQ, &outstanding);

~~~
wyldfire
You have to be pretty careful about what conclusions you draw from this info.
It means relatively little about what your actual peer has seen. It tells you
a some info about the channel between you and your peer, though.

If you need detailed feedback, you need to implement a feature that closes the
loop.

------
p4bl0
Very interesting read. Thanks for sharing.

