From mboxrd@z Thu Jan  1 00:00:00 1970
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
In-reply-to: Your message of "Thu, 17 Apr 2008 22:49:02 BST."
	<6c8ee780b952386da41071b68f378018@terzarima.net>
From: Bakul Shah <bakul+plan9@bitblocks.com>
Date: Thu, 17 Apr 2008 15:14:40 -0700
Message-Id: <20080417221440.4922C5B4A@mail.bitblocks.com>
Subject: Re: [9fans] telnet vs. godaddy whois
Topicbox-Message-UUID: 936cdc9c-ead3-11e9-9d60-3106f5b1d025

On Thu, 17 Apr 2008 22:49:02 BST Charles Forsyth <forsyth@terzarima.net>  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.