Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!UMDD.UMD.EDU!BRUCE
From: BRUCE@UMDD.UMD.EDU (Bruce Crabill)
Newsgroups: comp.protocols.tcp-ip
Subject: PUSH bit
Message-ID: <8903130939.AA05138@ucbvax.Berkeley.EDU>
Date: 13 Mar 89 04:48:27 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 34

I've noticed a quirk with a TCP/IP implementation that I'm working with.  It
has to do with how it handles the PUSH bit on TCP segments that it receives.
What is happening is that when a segment is received with the PUSH bit set,
it is placed in the client buffer and the client is notified as he should be.
However, if another segment comes in before the client picks up the data,
the new segment is also appended to the buffer.  When the client picks up
the buffer, it is marked as having been PUSHed.

The problems are that in some cases the second packet won't completely fit
in the buffer and will have to be split (or the second packet didn't have
the PUSH bit on it).  The client is seeing data that is marked as being
PUSHed, but in fact it was data earlier in the buffer.  I see three
possible solutions, do it as RFC 793 implied and don't allow anymore data
to be placed in the buffer.  This has the drawbacks of wasting buffer
space and causes more overhead in that the client needs to be notified
more times.  Second, don't set the PUSH flag for the buffer if the buffer
ends up with the final byte not being the last byte of a PUSHed segment
(but still give the buffer to the client ASAP).  Third, only allow data
to be appended to the buffer if they are also PUSHed and will fit within
the buffer.

What I guess I'm really asking is what is the exact purpose of the PUSH
bit.  You could interpret the PUSH bit as a end of logical record marker.
Or you could interpret is as simply a mechanism to make sure all the data
that is currently in the pipe is pushed out to the client.  Since TCP is
a stream oriented protocol, it would appear that the latter is the correct
interpretation.  In which case, any of the above 3 solutions will work.
However, the thing that is throwing me is the fact that PUSH data indications
are to be given to the client.  Why was this done?  Does this imply that
for every PUSH done on the sending side, their must be a corresponding
PUSH indication on the receiver's side?  If not, why bother with PUSH
indications at all?

                                       Bruce