Path: utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!CS.ALBANY.EDU!narten
From: narten@CS.ALBANY.EDU (Thomas Narten)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Proper handling of PUSH & small window by sender?
Message-ID: <9002201217.AA05832@percival.albany.edu>
Date: 20 Feb 90 12:17:47 GMT
References: <12566669004.20.BILLW@MATHOM.CISCO.COM>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 19

>PUSH is currently considered rather a bad idea.  It is more of a
>user->tcp level thing, as opposed to something that belongs in the
>protocol layer.

I'm not sure that PUSH can be swept under the rug as a "bad idea".  It
is a necessary compromise between deadlock avoidance and inefficiency.
For efficiency reasons, the transport layer wants to delay sending
data in order to coalesce several application write operations into a
single outgoing datagram.  (Likewise, the receiving TCP module might
delay handing data to the application layer until more data arrives.)
If the application sends one byte and then waits for a response,
however, delaying the sending of the data byte may produce a deadlock.
Applications use the PUSH operation to prevent the latter case.  It
directs TCP "flush its buffers" and hand any buffered data (up to the
PUSH mark) to the remote application.  In addition, PUSH does belong
in the protocol layer because it is the only way that the sending TCP
module can direct the receiving TCP module to flush its buffers.

Thomas Narten