Re: [hybi] WebSocket connection throttling clarification requested

Simone Bordet <simone.bordet@gmail.com> Thu, 24 January 2013 09:48 UTC

Return-Path: <simone.bordet@gmail.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 3DA2E21F8503 for <hybi@ietfa.amsl.com>; Thu, 24 Jan 2013 01:48:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzyZvekerJUt for <hybi@ietfa.amsl.com>; Thu, 24 Jan 2013 01:48:32 -0800 (PST)
Received: from mail-da0-f53.google.com (mail-da0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id BA68D21F84F0 for <hybi@ietf.org>; Thu, 24 Jan 2013 01:48:32 -0800 (PST)
Received: by mail-da0-f53.google.com with SMTP id x6so4160429dac.26 for <hybi@ietf.org>; Thu, 24 Jan 2013 01:48:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=uK/9bTQtAqp62n8BcrXZq0QgW5C9yN5WI4pafFbGIsU=; b=CgZnbiSVUe5Kg3V8JehvnBuy2VNbGB4pBQO6mzkvQnUIYkLZdF+tDPljq3ssLKhTzZ rw84phltKW7Iv43dx8Fg9WpNO1lfPUEqOas/OLVmnY/DBDMvu/81ONsOGbg8yqGcEWko 9EbwSmvpKynlcYkXnGbvc9Ojfru0bbc3AtRRQXI/PK4CLuczaxPc3Wtzs0I232a0QIJA ig8RhYVEkrPX/vuz6stC3pMW7cY0vdFn/Osh+SMruULMRn9jfkrLELUdnFZY5sXPhj+e AvvEFC2sZAyo/kPMmZs1+iGua2D2cEgFRHFJmU3UsIVnyjogbcvuglyiQVd+75ETA2Vr YFZw==
MIME-Version: 1.0
X-Received: by 10.66.87.67 with SMTP id v3mr3062357paz.63.1359020912469; Thu, 24 Jan 2013 01:48:32 -0800 (PST)
Received: by 10.68.209.228 with HTTP; Thu, 24 Jan 2013 01:48:32 -0800 (PST)
In-Reply-To: <CAHixhFp_eNG84RjbyM_9RAVR3dub3gWs6xbQH6DgJ5wA7qV0Ew@mail.gmail.com>
References: <CAHixhFp_eNG84RjbyM_9RAVR3dub3gWs6xbQH6DgJ5wA7qV0Ew@mail.gmail.com>
Date: Thu, 24 Jan 2013 10:48:32 +0100
Message-ID: <CAFWmRJ1iGfq4JtDxdR7x1VTwiiMGsjGGqGFs_e7XNWWJch2TYw@mail.gmail.com>
From: Simone Bordet <simone.bordet@gmail.com>
To: Adam Rice <ricea@chromium.org>
Content-Type: text/plain; charset="UTF-8"
Cc: Hybi <hybi@ietf.org>
Subject: Re: [hybi] WebSocket connection throttling clarification requested
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: Thu, 24 Jan 2013 09:48:33 -0000

Hi,

On Wed, Jan 23, 2013 at 10:30 AM, Adam Rice <ricea@chromium.org> wrote:
> Hi,
>
> I would like to ask for clarification on section 4.1 item 2 of WebSocket RFC
> 6455. It reads (emphasis mine):
>
> 2. If the client already has a WebSocket connection to the remote host (IP
> address) identified by /host/ and port /port/ pair, even if the remote host
> is known by another name, the client MUST wait until that connection has
> been established or for that connection to have failed. There MUST be no
> more than one connection in a CONNECTING state. If multiple connections to
> the same IP address are attempted simultaneously, the client MUST serialize
> them so that there is no more than one connection at a time running through
> the following steps.

May I ask the reason for this requirement ?

It seems to me that a protocol should not limit in this way concurrent
connects to a host.
This look more like a recommendation for implementers, but not
something that should be mandated in a protocol.

For example, this would be sub-optimal for client WebSocket libraries
that can be used to perform load testing, or server-to-server
communication, etc.
Not all clients or use cases are browsers.

I'd like to propose to remove this requirement and changing it a
non-normative section as a suggestion for browser implementations.

Thanks !

--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz