On Thu, 17 Apr 2008 22:49:02 BST Charles Forsyth <[EMAIL PROTECTED]> wrote:
> > Because of this what is likely happening is that on receiving
> > the PSH bit read() completes and returns to the caller app
> > with a count = 0 which the app must think indicates EOF!
>
> that behaviour (by the remote) is correct?
First, I am just speculating -- I have no idea what they are
running -- but if this is what happens, it is about as
sensible as setting PSH on a pure ACK.
In a later email you say:
> in fact, the Plan 9 behaviour is rational for a sluggish or zero window:
> the receiving side might delay delivering data to the application until
> a PSH, but won't open the window if that queue is full.
> (thus rfc1122 mutters about deadlock in the absence of PSH, in 4.2.2.2.)
I think you are referring to
An application program is logically required to set the
PUSH flag in a SEND call whenever it needs to force
delivery of the data to avoid a communication deadlock.
Note the phrase "to force delivery of the data". There is no
data to be sent in the case we are discussing. If you were
to set PSH when you send 1 byte (or more) to probe a closed
window that'd be fine but not with a pure ACK. So I read it
differently.
