Re: [hybi] Subprotocol and Control Frames

Greg Wilkins <gregw@intalio.com> Wed, 05 October 2011 03:42 UTC

Return-Path: <gregw@intalio.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3322521F848E for <hybi@ietfa.amsl.com>; Tue, 4 Oct 2011 20:42:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.92
X-Spam-Level:
X-Spam-Status: No, score=-2.92 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4+IxihUuQ9NJ for <hybi@ietfa.amsl.com>; Tue, 4 Oct 2011 20:42:11 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A332021F8498 for <hybi@ietf.org>; Tue, 4 Oct 2011 20:42:10 -0700 (PDT)
Received: by vcbfo11 with SMTP id fo11so1234657vcb.31 for <hybi@ietf.org>; Tue, 04 Oct 2011 20:45:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.97.200 with SMTP id ec8mr2022455vdb.203.1317786316988; Tue, 04 Oct 2011 20:45:16 -0700 (PDT)
Received: by 10.52.186.134 with HTTP; Tue, 4 Oct 2011 20:45:16 -0700 (PDT)
In-Reply-To: <92457F4F764A5C4785FCDBDDDD76477A123C6EA7@dfweml506-mbx>
References: <92457F4F764A5C4785FCDBDDDD76477A123C6E12@dfweml506-mbx> <CAH_y2NG+1TcQP6TVNbuwt6bjtCpQLaXtZvRjzBTefCrhb22+vA@mail.gmail.com> <92457F4F764A5C4785FCDBDDDD76477A123C6EA7@dfweml506-mbx>
Date: Wed, 05 Oct 2011 14:45:16 +1100
Message-ID: <CAH_y2NFGz1pNxS6h2CX8DtCY5sTQJqE=3iEF526QeN6kwO0s1Q@mail.gmail.com>
From: Greg Wilkins <gregw@intalio.com>
To: Hapner mark <hapner.mark@huawei.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] Subprotocol and Control Frames
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 05 Oct 2011 03:42:12 -0000

Mark,

I think MBWS could be considered either as a subprotocol or as an
extension, depending somewhat on what your requirements for reliable
delivery are.

If it was done as a subprotocol without additional layer of framing,
the major issue I see from lacking control frame semantics is that the
timeliness of an ack may be poor if there is a large message being
sent over the channel in the same direction as the ack.   Your
protocol would still be reliable and able to recover from connection
loss, but it may have some undue latency when informing the
application of a successful delivery.

Conversely, reliable messaging with timely acknowledgement is a good
candidate for a websocket extension, that could be of use to MBWS and
other protocols.  So it may be that the MBWS concept of a connection
spanning multiple WS connections is something that should be
implemented in a subprotocol, while the message sequencing and
acknowledgement part could be implemented in an extension.

cheers