[e2e] The One and Only True Push

[David P. Reed]

Regarding "true push" - that's not what I was concerned about, but Bob's 
right.   TCP isn't the Berkeley sockets API.   If "push" is missing from 
the API, that's not the protocol's fault... it's been there from the start.

In fact, when we split functionality specifically there in NCP only for 
Telnet out (here's another story from my own days designing TCP) we 
implemented the "urgent pointer" (which was pretty much from my DSP 
protocol, so blame me) and that was supposed to be an end-to-end Push, 
meaning to the TCP on the other end precisely that "your app client 
needs to process all the buffered data, including sender, network and 
receiver buffers, in order at high speed up to the sequence number in 
the urgent pointer, because something important to you is contained 
therein".   The urgent pointer was a monotone pointer supposed to be the 
max of all urgent pointer values ever set by the sender, and 
retransmitted packets were supposed to get the latest (maximum).   
That's TRUE PUSH.

Sadly, the Unix implementors, who were typically arrogant OS guys and 
weren't at the meetings where we hashed this out, misunderstood the 
point, and felt that the urgent pointer should not show through in the 
sockets API they supported, so people didn't use it as the general 
end-to-end push it was meant to be.  Instead, people were looking for 
"process interrupt" functionality (which was part of Telnet, not  part 
of TCP) and persisted in misunderstanding the point of the layer 
separation.  They perseverated on "acking" each urgent pointer value, 
even though the point was that the INTERRUPT was encoded in the data 
stream, and thus encumbered the PUSH, at least on Berkeley UNIX systems, 
with app layer semantics that it should never ever have had.