Re: two-phase send concerns

>>>>> Dave Kristol writes:

dmk> Larry Masinter <masinter@parc.xerox.com> wrote:
>> should send abort messages as soon as they can, and NOT CLOSE THE
>> CONNECTION if they care whether the sender actually gets the abort.

dmk> So, to return to Larry's question, I think the timeout could
dmk> indeed be reduced to zero.  However, apart from closing a
dmk> connection correctly, I don't think there's anything special a
dmk> receiver (to be clear: a server) needs to do to ensure the sender
dmk> (client) gets an abort message's bytes.  But the sender (client)
dmk> does have to look for them!

I'd be interested in talking to anyone who has actually implemented
PUT.  My Unix implementation works fine via SIGPIPE signal handling
with no delay, but the port of the client to Windows (Winsock TCP
stack) has lots of problems with this.

>From my experience, it seems like Larry is correct; the server -does-
need to hold the connection open.  Otherwise, (and I'm guessing this
is due to a poor TCP implementation) as soon as the client sends a
single byte on a closed connection, a TCP reset occurs, and the abort
data is -lost- to the client, even though it physically went out on
the wire.  I've watched this happen with a sniffer.

The big problem from my perspective is that the abort data is often
quite important.  In particular, the place where I see this happen is
in a PUT to a location that is unauthorized.  The -only- way I've
gotten this to work is for the server to hold the connection open
until the client notices the data to read and closes.

-Roger

Roger Gonzalez                    NetCentric Corporation
rg@server.net                     56 Rogers Street
home   (617) 646-0028             Cambridge, MA 02142
mobile (617) 755-0635             work (617) 868-8600



60 09 3A EE FE 6A 1E CC   -pgp-   B7 F7 6B 0F 00 1D 01 C7

Received on Tuesday, 5 December 1995 16:22:06 UTC