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

Iñaki Baz Castillo <ibc@aliax.net> Sun, 24 July 2011 18:24 UTC

Return-Path: <ibc@aliax.net>
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 37ABC21F8A7E; Sun, 24 Jul 2011 11:24:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.059
X-Spam-Level:
X-Spam-Status: No, score=-2.059 tagged_above=-999 required=5 tests=[AWL=-0.582, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_24=0.6, J_CHICKENPOX_64=0.6, MIME_8BIT_HEADER=0.3, 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 mnYTupkwiMu3; Sun, 24 Jul 2011 11:24:26 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 59CB121F8A7D; Sun, 24 Jul 2011 11:24:26 -0700 (PDT)
Received: by qyk9 with SMTP id 9so660932qyk.10 for <multiple recipients>; Sun, 24 Jul 2011 11:24:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.44.36 with SMTP id y36mr2766738qce.227.1311531865763; Sun, 24 Jul 2011 11:24:25 -0700 (PDT)
Received: by 10.229.185.195 with HTTP; Sun, 24 Jul 2011 11:24:25 -0700 (PDT)
In-Reply-To: <20110724120751.GQ22405@1wt.eu>
References: <CALiegfmTWMP3GhS1-k2aoHHXkUkB+eWqV=2+BufuWVR1s2Z-EA@mail.gmail.com> <20110721163910.GA16854@1wt.eu> <CAP992=FrX5VxP2o0JLNoJs8nXXba7wbZ6RN9wBUYC0ZSN_wbAg@mail.gmail.com> <9031.1311270000.588511@puncture> <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>
Date: Sun, 24 Jul 2011 20:24:25 +0200
Message-ID: <CALiegfncavmoMp4YDCeeJ3rsOfHAYQ99itKX2Q2eHB351T3X5A@mail.gmail.com>
From: Iñaki Baz Castillo <ibc@aliax.net>
To: Willy Tarreau <w@1wt.eu>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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 18:24:27 -0000

2011/7/24 Willy Tarreau <w@1wt.eu>:
>> Hi. Maybe I'm the only who assumes that, usually, the WS server is not
>> colocated within the initial web server.
>
> Web-based infrastructures make that almost mandatory at the frontend,
> especially in massive hosting where you don't want to multiply IP addresses.
> In general you have one single point which handles the IP:port and which
> dispatches that to many servers based on the Host header, URI, file names,
> cookies, etc...

Ok, right, but that shouldn't be enough to make a specification
assuming it (IMHO).




>> I don't agree with yout point. Doing the "upgrade" does not mean
>> reusing an existing TCP connection (in which HTTP took place) for
>> other purpose.
>
> Huh ?

I just meant that there is no need of first retrieving a page from a
IP:PORT and then making the WS upgrade using the same IP:PORT.


>> Instead, doing the WS upgrade means opening (or
>> reusing) a TCP connection, sending a HTTP GET with special semantics,
>> expect 101 and then start a bidirectional frame-based communication.
>
> I still remember how the handshake works, thank you.

Sure, I didn't mean that you don't know it :)


>> So sending the GET with "upgrade" has nothing to do with any previous
>> HTTP communication with the HTTP server.
>
> Yes it has. Either you open a fresh new connection, or you reuse an
> idle existing one.

If the WS URI points to a different server, it's perfectly possible
that the WS connection has nothing to do (neither cookies usage) with
the previous HTTP/HTML traffic. I just meant it.


> But to know that the connection is idle, you must
> understand the protocol that was spoken on it and this protocol must
> have clearly delimited messages. HTTP supports reuse of connections
> (also called "keep-alive") and since the WS handshake is HTTP, it is
> possible and I'd add even recommended to reuse an existing connection
> to send a WS handshake, if one such connection exists.

Don't take me wrong, but "keep-alive" mechanism in HTTP is just a hack
since paralelism is not possible (well, it's but with too many
constrains, for example the server must send the replies in order). In
other protocols working on top of TCP (as SIP) each request contains
an id (in the case of SIP the Via branch) which allows identifying
which request a response belongs to, so I can send N requests via the
same TCP connection and receive the responses in any order. HTTP is
poor on this topic, and I wouldn't like WS to inherit it.



>> Do you mean WS as a complete separate protocol running on a specific
>> WS port and so? I'd really would like it (rather than the exotic
>> pseudo-HTTP mechanism used right now), but I expect it will never
>> happen.
>
> I'm sure it will happen. We need applications to be developped using
> WS first. But there are places where :
>  - HTTP compatibility won't be needed
>  - masking will be annoying
>  - HTTP overhead will be too much
>  - HTTP round trip will be too much
>
> I think that this will happen as soon as a working proposal for TLS NPN
> appears, because the same requirements will exist (eg: how to specify
> the resource name in a simpler way, etc...). Right now we need WS to be
> able to replace long polling mechanisms which already work over HTTP, so
> if we want it to be adopted, we need to deploy where previous methods
> used to work. You just need to be patient :-)

ok, I like what you say :)
However, imagine that in next 2 years there are a lot of WS servers
speaking HTTP (for the WS handshake, of course). If you suggest that a
different WS protocol could appear, it would require a new URI schema
so the client knows wheter to perform a HTTP WS handshake or use the
new WS protocol.



>> Having multiple A/AAAA records for a single domain does not provide
>> failover (as clients usually take just the first IP). I see your
>> point, but I expect no success at all.
>
> That's not what I'm saying. Right now, people are using A/AAAA with short
> TTLs and are updating the zones when a site fails (when I mean a site, I
> mean a datacenter). This is something which happens rarely enough to be
> acceptable. Using fast DNS updates for server failover does not work
> because caches are everywhere and experience shows that even after one
> month you still receive traffic on a server you've stopped announcing.

And there is where DNS SRV could help a lot :)



> However, please read what I've explained in another mail about the
> limitations of client-based failover in web environments.

Yes, I've read it. But I expect it's even more critical in a phone
call (my SIP phone performs SRV/A, gets the first IP:port and sends
the call request there using UDP, but the server is down, so after
some seconds *without hearing ringing* the phone sends the call to
another server). If it's not critical in SIP, why should it be so
critical in WS?

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?


Regards.



-- 
Iñaki Baz Castillo
<ibc@aliax.net>