Re: [hybi] New port and Tunneling?

"Shelby Moore" <shelby@coolpage.com> Mon, 16 August 2010 00:50 UTC

Return-Path: <shelby@coolpage.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 1C1E63A68DE for <hybi@core3.amsl.com>; Sun, 15 Aug 2010 17:50:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[AWL=0.899, 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 XYPpYwtchtWf for <hybi@core3.amsl.com>; Sun, 15 Aug 2010 17:50:50 -0700 (PDT)
Received: from www5.webmail.pair.com (www5.webmail.pair.com [66.39.3.83]) by core3.amsl.com (Postfix) with SMTP id 14EE23A6876 for <hybi@ietf.org>; Sun, 15 Aug 2010 17:50:50 -0700 (PDT)
Received: (qmail 43764 invoked by uid 65534); 16 Aug 2010 00:51:25 -0000
Received: from 121.97.54.174 ([121.97.54.174]) (SquirrelMail authenticated user shelby@coolpage.com) by sm.webmail.pair.com with HTTP; Sun, 15 Aug 2010 20:51:25 -0400
Message-ID: <28d4e6c08e65e43899d59478e332a8aa.squirrel@sm.webmail.pair.com>
In-Reply-To: <AANLkTi==qsBWRDhxten+fV91bYiBhJ_vhSoqPNpsp3Pb@mail.gmail.com>
References: <7ffabb591b2292c9b81abecfaec3cdb6.squirrel@sm.webmail.pair.com> <20100815210332.GH27614@1wt.eu> <a8358c0239c686dfd4753b55c6c34385.squirrel@sm.webmail.pair.com> <20100815221922.GJ27614@1wt.eu> <b13c89a75303a5d97edcb78926b385be.squirrel@sm.webmail.pair.com> <20100815234010.GM27614@1wt.eu> <52530df7491f03990cbfffd3eb49bcb6.squirrel@sm.webmail.pair.com> <AANLkTi==qsBWRDhxten+fV91bYiBhJ_vhSoqPNpsp3Pb@mail.gmail.com>
Date: Sun, 15 Aug 2010 20:51:25 -0400
From: Shelby Moore <shelby@coolpage.com>
To: Greg Wilkins <gregw@webtide.com>
User-Agent: SquirrelMail/1.4.20
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: hybi@ietf.org
Subject: Re: [hybi] New port and Tunneling?
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: shelby@coolpage.com
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: Mon, 16 Aug 2010 00:50:51 -0000

> On 16 August 2010 10:24, Shelby Moore <shelby@coolpage.com> wrote:
>>> On Sun, Aug 15, 2010 at 07:03:05PM -0400, Shelby Moore wrote:
>> We must have that fallback no matter what we do.  All options forward
>> have
>> failure cases.
>>
>>> If I had the choice, I'd rather go for
>>> WS/TLS with a quick fail to WS/HTTP.
>>
>>
>> WS/HTTP can fail at random times after that quick fail, you still need
>> Comet/BOSH.
>
> and Comet/BOSH can fail at random times.
> All solutions need to handle the fact that the internet can fail silently.
>
> I do not think it is possible to design a system that will always fast
> fail, other than an explicit declaration by a participant that a
> protocol is not supported.   It is impossible to design a handshake,
> whose success will guarantee the delivery of a subsequent websocket
> message .
>
> The only real evidence of a protocol working is the protocol working.
> The level of confidence in the protocol will be determined only by
> mechanisms built into the protocol: messages, keep-alives, ping/pongs
> and any extensions for acknowledgements etc.
>
> There is no silver bullet.

Strong point, but won't the WS/port+tunnel (over TCP or equivalent) only
fail-to-deliver and never corrupt, whereas WS/HTTP could corrupt the data
(and will not support some data types at all, need encryption)?

Also WS/HTTP is likely to fail more often during data transfer (after
initial handshake) given reasonable robust networks.

So they are not equivalent failure costs.