Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!GATEWAY.MITRE.ORG!barns
From: barns@GATEWAY.MITRE.ORG (Bill Barns)
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  PUSH bit
Message-ID: <8903131422.AA24345@gateway.mitre.org>
Date: 13 Mar 89 14:22:18 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 49

OK, I'll bite, since I babbled about this in the Host Requirements WG.

The PSH bit is definitely NOT a record marker.  It is the sending
application's means of demanding that the data not be allowed to linger
in buffers somewhere between the sending and receiving application.

It is fine to deliver some 'non-PSHed' data in the same buffer as the
PUSHed data, if there is some of both kinds available for delivery.  It
is always permitted to deliver any (in-sequence) data that is on hand,
regardless of Push.  The ABSENCE of Push gives all the intermediate
processes permission to buffer the data until there is a Push (or until
some other event implying a Push occurs, such as a FIN arriving).

It is not required that PSH be transferred one-to-one.  Either the
sending or receiving TCP may 'collapse' them.  The HR RFC (coming
soon...) will clarify that providing notification of a Push to a
receiving application is optional rather than required.  Kindly note,
tiny minority of careless readers, that sending a PSH bit at
appropriate times is still mandatory.  This is important!!  Anyhow, the
service definition in RFC 793 is somewhat exemplary and contains a few
optional features.  It is hoped that the text in the HR RFC will
clarify all this.  (Draft available from venera.isi.edu by anonymous
ftp using filename /pub/ietf-hosts.rfc.txt)

All of your three solutions are legal, but somewhat distasteful to me,
especially #2, which probably "ought" to be illegal.  For the case you
describe, I think the preferred solution is to fill the buffer as full
as possible with any available data, and set the Push indication.

Why should a Push indication be passed from the destination TCP to the
client application?  True, it is often not very useful, and it should
never be NECESSARY (if it seems to be necessary to the application, the
application/TCP service mapping is flawed, given the facts described
above).  However, it has a little value once in a while.  Here is an
example.  A few years ago I was working with some timesharing host
software which used windows on a 24x80 display terminal and could have
connections to various other hosts whose output might be sent to
various windows.  This was originally designed for a different protocol
stack and I added support for TCP connections driving windows.  Since
bandwidth to the terminal and CPU usage (context switches..) were of
some concern, I contrived code such that window repaints were only
scheduled when a Push came in for that window.  This resulted in fewer
process wakeups, better efficiency on the terminal-host interface, and
yet allowed a window to be updated pretty promptly when a remote host
felt the need to do that.  Also, it saved me the nuisance of
timer-driven connection polling or some other algorithm which would
have taken more effort to code.  I thought it worked out pretty well.

Bill Barns / MITRE-Washington / barns@gateway.mitre.org