Re: [hybi] Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard

Willy Tarreau <w@1wt.eu> Sun, 24 July 2011 19:29 UTC

Return-Path: <w@1wt.eu>
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 5B33D21F8A91; Sun, 24 Jul 2011 12:29:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.36
X-Spam-Level:
X-Spam-Status: No, score=-4.36 tagged_above=-999 required=5 tests=[AWL=-3.217, BAYES_00=-2.599, HELO_IS_SMALL6=0.556, J_CHICKENPOX_64=0.6, MIME_8BIT_HEADER=0.3]
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 e0lbL5uoOA1A; Sun, 24 Jul 2011 12:29:53 -0700 (PDT)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 7C73221F8891; Sun, 24 Jul 2011 12:29:53 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p6OJTm8F027308; Sun, 24 Jul 2011 21:29:48 +0200
Date: Sun, 24 Jul 2011 21:29:48 +0200
From: Willy Tarreau <w@1wt.eu>
To: =?iso-8859-1?Q?I=F1aki?= Baz Castillo <ibc@aliax.net>
Message-ID: <20110724192948.GD22405@1wt.eu>
References: <CALiegf=pYzybvc7WB2QfPg6FKrhLxgzHuP-DpuuMfZYJV6Z7FQ@mail.gmail.com> <CAP992=FJymFPKcPVWrF-LkcEtNUz=Kt9L_ex+kLtjiGjL1T46w@mail.gmail.com> <4E28A51F.4020704@callenish.com> <CALiegf=4K2oWfmZjGMD7J_jyaDtS3i+Mu7R0Wh75Rr+MrQCjtw@mail.gmail.com> <20110722054345.GE18126@1wt.eu> <CALiegfnYm6g63JDHLiSH__r-or3kzK0XCVa3cC7RMP14KWBOSg@mail.gmail.com> <20110724120751.GQ22405@1wt.eu> <CALiegfncavmoMp4YDCeeJ3rsOfHAYQ99itKX2Q2eHB351T3X5A@mail.gmail.com> <20110724184537.GZ22405@1wt.eu> <CALiegfne620wuDMAp235n3mVcXTAnbhhNm8vpiNCy5F7+VD92A@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CALiegfne620wuDMAp235n3mVcXTAnbhhNm8vpiNCy5F7+VD92A@mail.gmail.com>
User-Agent: Mutt/1.4.2.3i
Cc: Server-Initiated HTTP <hybi@ietf.org>, IETF-Discussion <ietf@ietf.org>
Subject: Re: [hybi] Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard
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: Sun, 24 Jul 2011 19:29:54 -0000

On Sun, Jul 24, 2011 at 08:57:45PM +0200, Iñaki Baz Castillo wrote:
> 2011/7/24 Willy Tarreau <w@1wt.eu>eu>:
> >> Also, if the user realizes that the connection takes too much time and
> >> presses F5 to reload the page, why couldn't the webbrowser cache the
> >> SRV results and mark the previous attemp as failed so next server:port
> >> woul be tryed when the user presses F5?
> >
> > Yes but once again, if you have to wait one minute on each new site so
> > that all dead servers can be ignored, the web will look like a terrible
> > experience to you.
> 
> Ok, but what would be the failover solution then? any failover
> solution can take some time until redirects the client's request to a
> working server, it's not just a client problem.

This is already addressed by existing web architectures. DNS provides
geolocation and proposes you the closest working datacenter. BGP ensures
that this datacenter is always reachable via multiple links and multiple
providers. Load balancers on the site ensure that only valid servers are
used. I know some people who configure their load balancers so that a
server is removed from the pool less than 50ms after a failure or slowdown
has been noticed. You will never be able to offer that quality of service
using DNS only, because those 50ms are less than the time it takes for
most visitors to ping the site.

> Anyhow, don't forget that SRV is not just for failover, but also for
> load-balancing (you can state that a more powerful server-01 receives
> 80% of the traffic and server-02 the remaining 20%).

This is already addressed by DNS round robin and used by a lot of sites.
But keep in mind that DNS is used between *sites* and not *servers*. If
you use it for servers, you'll fail because you won't be able to silently
put them in maintenance without disturbing visitors. Load balancers are
used for servers. And between sites, people are not seeking imbalanced
distribution. If they really do, then it's easy using multiple addresses.

Don't take this as an attack (it is not), but you accused Roy of not
knowing SRV, but I think that you're not much experienced with web
infrastructures and that may be why you think that SRV is the *only*
solution to many problems that have been dealt with for ages.

I think your proposal could make sense with SHOULDs instead of MUSTs,
eventhough it's unlikely that it will be used for the latency reasons
that were suggested.

Regards,
Willy