IETF Logo Mail Archive

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

Justin Erenkrantz <justin@erenkrantz.com> Sat, 30 January 2010 07:33 UTC

Return-Path: <justin.erenkrantz@gmail.com>
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 69AE63A681F for <hybi@core3.amsl.com>; Fri, 29 Jan 2010 23:33:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.053
X-Spam-Level:
X-Spam-Status: No, score=-2.053 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 8PUaCGqeZjtK for <hybi@core3.amsl.com>; Fri, 29 Jan 2010 23:33:39 -0800 (PST)
Received: from mail-yx0-f194.google.com (mail-yx0-f194.google.com [209.85.210.194]) by core3.amsl.com (Postfix) with ESMTP id 88E1D3A6405 for <hybi@ietf.org>; Fri, 29 Jan 2010 23:33:39 -0800 (PST)
Received: by yxe32 with SMTP id 32so2381082yxe.5 for <hybi@ietf.org>; Fri, 29 Jan 2010 23:34:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=v6RrjcVgZQK8ZdOkjbnlc7dNE9xqugcjU7L1kSjFUFk=; b=gk1f2Qd/0N4pPp2K/OV9yhGmgIY3eYD0kAe6VWztm/i5uxt2ndwEARtt1ZosnXM1u3 T5F74XV8z1WnhX0NnicAILcG3pYlEOc/W28LtBAHc2gpLhnMex/KmW2AN37VCckbXe8o Lc5e7V3tvFrVoJXZQa8urxRhjD1do7sYUOQkA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Y3Vl9t3eupNTvpqrEvfea+x3gb2MFvyAhU1C9H2zD8c5ufrW8DZudXfJl5c53cCEOS mXXbMwbXqYB8udjM/TNdDeqOjODsH9H9pU0e+TGFxk2u719ghhAGxWimOY7ZRVpJcgfq U0qVNuIDFyAOxiWk2I02wLXmfqD1BpaPxGYTg=
MIME-Version: 1.0
Sender: justin.erenkrantz@gmail.com
Received: by 10.91.97.14 with SMTP id z14mr1893471agl.0.1264836836783; Fri, 29 Jan 2010 23:33:56 -0800 (PST)
In-Reply-To: <26D406E7-2319-476E-9ADF-80D84200C270@apple.com>
References: <de17d48e1001280012i2657b587i83cda30f50013e6b@mail.gmail.com> <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> <5c902b9e1001292310l5442d476n8375139f3480671b@mail.gmail.com> <26D406E7-2319-476E-9ADF-80D84200C270@apple.com>
Date: Fri, 29 Jan 2010 23:33:56 -0800
X-Google-Sender-Auth: da33cc2ef3f32fc4
Message-ID: <5c902b9e1001292333k79569316lf371938c9aa766@mail.gmail.com>
From: Justin Erenkrantz <justin@erenkrantz.com>
To: Maciej Stachowiak <mjs@apple.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
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 07:33:40 -0000

On Fri, Jan 29, 2010 at 11:25 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>> It depends upon what level of "reliability" you are looking for.  If
>> you are aiming for the "common" case, the answer to both is "yes".
>>
>> However, edge cases make the answer "no" - it is quite possible to
>> have "lost" responses that a server actually sends, but the client
>> will never see.
>
> So you could lose messages, but can you tell in this case that you are not guaranteed yet that they have been delivered?

No, not really - the client simply thinks the server close()'d the
connection but it has no way of knowing there were other data packets
that the server really meant for the client to see.  Correspondingly,
the server did everything in the right order - it wrote all the data
it expected and then it close()'d the socket.  Yet...oops.

I don't know how much code Jetty has to deal with lingering close, but
httpd has an embarrassingly large amount of code to deal with this
situation.

> It seems like a WebSocket-level close handshake would only solve part of the problem - you also need to be able to deal with an interruption of service that prematurely breaks the connection, and ideally you would have some better guarantee in that case than just assuming all messages are lost. Does that also need provision at the protocol layer, or could it just piggyback on TCP-level acks?

Like Greg, I think orderly close is about as good as you can do.
Interruption of service is always going to be a possibility (power
failure, router outages, etc.) - at least if orderly close is
explicitly part of the protocol, then if it doesn't happen, then the
client knows something went awry and then it can deal with it as best
as it can.  Currently, in HTTP, you can't tell the difference between
an orderly close and a "oh, no, something bad happened".  I think
providing that type of hint would be a big step-forward - especially
when async messages are involved.  -- justin

v2.23.0 | Report a Bug | By Email