> > 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.

Mmmm I always thought the socket API was broken :-)
(FWIW most of the protocol stack code I've written used the Streams
XTI/TLI/TPI interface).

> 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.

Ah the other TCP implementations I've seen don't do that.
(Or at least I don't remember seeing the push flag set in TCP packet
traces.)

> > 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".

So clearly the application itself needs a way to set it!

> > 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?

No - try a different protocol!  Eg LAPB or LLC2.

	David

-- 
David Laight: david@l8s.co.uk