>> 12:36:17.991144 10.0.1.186.514 > 10.0.1.1.704: P 193:195(2) ack 419 win 32850 <nop,nop,timestamp 143 143> (DF)
>> 12:36:17.991395 10.0.1.1.704 > 10.0.1.186.514: P 419:422(3) ack 195 win 32850 <nop,nop,timestamp 143 143> (DF)
>> 12:36:17.991500 10.0.1.186.514 > 10.0.1.1.704: P 195:197(2) ack 422 win 32850 <nop,nop,timestamp 143 143> (DF)
>> 12:36:18.183591 10.0.1.1.704 > 10.0.1.186.514: . ack 197 win 32850 <nop,nop,timestamp 143 143> (DF)
>> 12:36:18.183644 10.0.1.186.514 > 10.0.1.1.704: P 197:199(2) ack 422 win 32850 <nop,nop,timestamp 144 143> (DF)
>> 12:36:18.183874 10.0.1.1.704 > 10.0.1.186.514: P 422:424(2) ack 199 win 32850 <nop,nop,timestamp 143 144> (DF)
>> 12:36:18.380045 10.0.1.186.514 > 10.0.1.1.704: . ack 424 win 32850 <nop,nop,timestamp 144 143> (DF)

> If I read that trace correctly it looks as though the sending end is
> doing a 'wait for more data' is spite of the 'push' flag being set.

This depends.  The socket API does not provide a way for applications
to control the push flag, so (assuming the sender is using sockets) a
more accurate phrasing would end the sentence after "'wait for more
data'" - the push flag on the wire is set by the stack, not the
application.

What I assume is going on here is that the application is write()ing
data and the stack is holding onto it for a short time in the hope the
application will write() more, which is a win if the application is
sending bulk data.  The application doesn't send anything more, so the
TCP stack times out and sends what it has anyway.  Because of the lack
of an application-level push bit, it always set PSH when it has no more
data to send, in case there is an application-level "conceptual push"
at that point in the data stream.

> IIRC about the only thing the push flag mans is 'send this now and
> don't wait for any more data because there won't be any'.

Well, "might not", not "won't", but yes; PSH means "deliver this to the
application promptly, rather than buffering it in the hope I'll send
you more soon".

> Of course the 'send me an ack for this packet' is a very useful
> protocol feature - but is completly orthoginal to the tcp push flag.

Yes - it's also nonexistent, as far as I know; I don't know of any way
for a sending TCP to tell the receiving TCP "ack this data ASAP if you
can".  The closest thing I know of is an out-of-window packet such as
are used by connection keepalives, but that's a separate packet, not a
way to mark an otherwise ordinary packet.

Or have I missed something recently?

/~\ 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