>> In particular the PSH flag isn't exposed to the application itself
>> by any APIs I know of.  So the application cannot use it to pervert
>> the cause of Nagle on a per-send basis.
> I kind of expected that writes without fflush() or equivalent would
> not set the TCP PSH flag.  Apparently I was wrong about that.

fflush() is a stdioism, not visible to the TCP stack.  TCP doesn't find
out about anything until write(2) is called, and I think the BSD stack
always PSHes at the end of each write() (unless, of course, another
write arrives before it gets a chance to push out the last byte of
data, but that's the way PSH always works).

> Nevertheless, could we use fflush() to tell TCP to send buffered data
> without waiting for Nagle-induced delays?

No, because before stdio's buffer is flushed, TCP has no chance to do
anything with the data, Nagle or not; after, it has no way to tell
whether it was a "please don't Nagle" push or not.

The API/ABI simply has no way to represent the difference between "send
this now, Nagle be damned" and "send this but I'm in no particular
hurry" except by turning Nagle on and off.

This could be done by using send() instead of write(), and adding a
flag bit (send's fourth argument) whose meaning maps well onto Nagle.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B