Re: [hybi] Reliable message delivery (was Re: Technical feedback.)

Jamie Lokier <jamie@shareable.org> Sat, 30 January 2010 15:12 UTC

Return-Path: <jamie@shareable.org>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EBE83A67CF for <hybi@core3.amsl.com>; Sat, 30 Jan 2010 07:12:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.25
X-Spam-Level:
X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEVB0yP3AxYY for <hybi@core3.amsl.com>; Sat, 30 Jan 2010 07:11:53 -0800 (PST)
Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id CDA423A6810 for <hybi@ietf.org>; Sat, 30 Jan 2010 07:11:47 -0800 (PST)
Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from <jamie@shareable.org>) id 1NbEzb-0003Lp-Bn; Sat, 30 Jan 2010 15:12:11 +0000
Date: Sat, 30 Jan 2010 15:12:11 +0000
From: Jamie Lokier <jamie@shareable.org>
To: Maciej Stachowiak <mjs@apple.com>
Message-ID: <20100130151211.GE19124@shareable.org>
References: <4B625733.2020907@webtide.com> <6.2.5.6.2.20100128225542.06fa8d68@resistor.net> <Pine.LNX.4.64.1001290817520.22020@ps20323.dreamhostps.com> <4B62C5FE.8090904@it.aoyama.ac.jp> <Pine.LNX.4.64.1001291134350.22020@ps20323.dreamhostps.com> <4B62E516.2010003@webtide.com> <5c902b9e1001290756r3f585204h32cacd6e64fbebaa@mail.gmail.com> <4B636757.3040307@webtide.com> <8449BE19-3061-4512-B563-02973FBB707B@apple.com> <20100130141020.GC19124@shareable.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20100130141020.GC19124@shareable.org>
User-Agent: Mutt/1.5.13 (2006-08-11)
Cc: Hybi <hybi@ietf.org>
Subject: Re: [hybi] Reliable message delivery (was Re: Technical feedback.)
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Jan 2010 15:12:06 -0000

Jamie Lokier wrote:
> That is: It's not safe to close 

Edit fart there... That issue has been addressed elsewhere in this
thread - under "lingering close".

> > 2) Is a TCP-level ack sufficient for this purpose? (Or would clients
> > for reliable message delivery want a full end-to-end ack from the
> > receiving application?)
> 
> No, and yes.  The reasons are numerous:

In a nutshell, don't try to make reliable things depend on TCP
behaviour.  Treat TCP as a transport layer only.

Nowadays, on the "web user" Internet anyway, you can't depend on a
connection remaining open if the endpoints continue working; not even
with keepalives.  NATs occasionally lose state; route changes break
connections when NATs are involved; mobile connections drop every few
minutes in some areas; IP address may even change every few minutes.

In many ways, TCP was more dependable for things like long-lived
connections in ye olde days.

Optimisation heuristics like splitting messages at probable MSS
boundaries, and timing keepalives to piggyback on ACKs, are ok, because
nothing fails when they are wrong.

-- Jamie