IETF Logo Mail Archive

[hybi] Hello frames?

Greg Wilkins <gregw@intalio.com> Mon, 28 February 2011 21:24 UTC

Return-Path: <gregw@intalio.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 A99963A6C32 for <hybi@core3.amsl.com>; Mon, 28 Feb 2011 13:24:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.677
X-Spam-Level:
X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
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 KFV6iFUlBtEG for <hybi@core3.amsl.com>; Mon, 28 Feb 2011 13:24:37 -0800 (PST)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id BCC3D3A6A25 for <hybi@ietf.org>; Mon, 28 Feb 2011 13:24:37 -0800 (PST)
Received: by vws6 with SMTP id 6so4022688vws.31 for <hybi@ietf.org>; Mon, 28 Feb 2011 13:25:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.97.130 with SMTP id ea2mr3042733vdb.230.1298928328501; Mon, 28 Feb 2011 13:25:28 -0800 (PST)
Received: by 10.52.165.129 with HTTP; Mon, 28 Feb 2011 13:25:28 -0800 (PST)
Date: Tue, 01 Mar 2011 08:25:28 +1100
Message-ID: <AANLkTikb1eShW7yrLpAAv7YrmHon2ZY38fkFw-c8To-T@mail.gmail.com>
From: Greg Wilkins <gregw@intalio.com>
To: Hybi <hybi@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Subject: [hybi] Hello frames?
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: Mon, 28 Feb 2011 21:24:38 -0000

Now the handshake is mostly settled, can we put Hello frames back on
the agenda to discuss. As has been discussed before, Hello frames can
be motivated for reasons other than the handshake or protecting from
attacks.

Specifically hello frames (or even just a mandatory ping/pong) can act
as a rapid test of the established WS channel, so we'd have a
conversation that looks like:

  --- client HTTP handshake -->
  <--- server HTTP handshake ---
  <--- server Hello (or ping) ---
  --- client Hello (or pong) -->

I'm happy with ping/pong if we are not going to have any meaningful
content to the packets.   However, if we want some meaningful content
that is different for client and server then either we need Hello
frames or we need to allow pongs to have different content to pings.

The content I would like to see in a hello is a description of the
timeouts and buffer sizes supported by the client/server.  One of the
big problems with Comet over HTTP is that we don't know what the
network times are, so we don't know what frequency we need to send
long polls.  The equivalent of this in websockets is how frequently
does a ping/pong need to be sent to avoid an idle close.   I
understand that a fair bit of work is needed to know who will send the
ping/pongs etc, but I think the first step in any plan will be
disclosure of timeouts.   Hello frames would look to be a good way
disclose this information.

cheers

v2.23.0 | Report a Bug | By Email