[hybi] Intermediaries and idle connections (was Re: Technical feedback.)

Maciej Stachowiak <mjs@apple.com> Sat, 30 January 2010 06:28 UTC

Return-Path: <mjs@apple.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 272963A67B1 for <hybi@core3.amsl.com>; Fri, 29 Jan 2010 22:28:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.993
X-Spam-Level:
X-Spam-Status: No, score=-105.993 tagged_above=-999 required=5 tests=[AWL=0.475, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_RMML_Stock10=0.13, USER_IN_WHITELIST=-100]
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 ftWqLc+OLRU9 for <hybi@core3.amsl.com>; Fri, 29 Jan 2010 22:28:30 -0800 (PST)
Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 069E13A6405 for <hybi@ietf.org>; Fri, 29 Jan 2010 22:28:30 -0800 (PST)
Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out4.apple.com (Postfix) with ESMTP id 4F35D89448FB for <hybi@ietf.org>; Fri, 29 Jan 2010 22:28:55 -0800 (PST)
X-AuditID: 11807134-b7cd9ae000001002-7d-4b63d1a7466c
Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay14.apple.com (Apple SCV relay) with SMTP id 64.10.04098.7A1D36B4; Fri, 29 Jan 2010 22:28:55 -0800 (PST)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_1HxQaVpvce/p23FWkam+0w)"
Received: from [17.151.93.115] by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0KX1005A4RC63R90@et.apple.com> for hybi@ietf.org; Fri, 29 Jan 2010 22:28:55 -0800 (PST)
From: Maciej Stachowiak <mjs@apple.com>
In-reply-to: <4B636757.3040307@webtide.com>
Date: Fri, 29 Jan 2010 22:28:54 -0800
Message-id: <E379EA13-D58A-4BFB-A62D-2B931A54E276@apple.com>
References: <de17d48e1001280012i2657b587i83cda30f50013e6b@mail.gmail.com> <4B620B8F.6030706@gmx.de> <Pine.LNX.4.64.1001282217320.22053@ps20323.dreamhostps.com> <bbeaa26f1001281449q1a6e1813q3f537fe15a5a9d60@mail.gmail.com> <4B625733.2020907@webtide.com> <6.2.5.6.2.20100128225542.06fa8d68@resistor.net> <Pine.LNX.4.64.1001290817520.22020@ps20323.dreamhostps.com> <4B62C5FE.8090904@it.aoyama.ac.jp> <Pine.LNX.4.64.1001291134350.22020@ps20323.dreamhostps.com> <4B62E516.2010003@webtide.com> <5c902b9e1001290756r3f585204h32cacd6e64fbebaa@mail.gmail.com> <4B636757.3040307@webtide.com>
To: Greg Wilkins <gregw@webtide.com>
X-Mailer: Apple Mail (2.1077)
X-Brightmail-Tracker: AAAAAQAAAZE=
Cc: Hybi <hybi@ietf.org>
Subject: [hybi] Intermediaries and idle connections (was Re: Technical feedback.)
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: Sat, 30 Jan 2010 06:28:31 -0000

Feedback from server-side implementors is awesome! I'm going to reply to some of these topics separately to put them in separate threads. Let's start with intermediaries and expectation of holding open an idle connection:

On Jan 29, 2010, at 2:55 PM, Greg Wilkins wrote:
> 
> Because there is no "buy-in" from intermediaries, we have no
> way of knowing how long they will keep open an idle connection.
> Because there is no meta-data, we have no idea how long a browser
> will keep an idle connection.
> 
> So we have to send keep alive messages over the websocket
> to make sure it is not closed.  For this we are just using
> the /meta/connect message we use for long polling over XHR

That is a valid concern. I think it would be a problem to design a protocol where buy-in from intermediaries is required to deploy at all, because that would greatly delay the deployment timeline. However, you have pointed out a real problem with not knowing how intermediaries will react, namely that you don't know if you need to take special measures to hold the connection open.

I think the right way to approach this, and issues of intermediary participation, is to have optional opt-in from intermediaries. I would like to see a design where at least the SSL version of the WebSocket protocol can operate with no need to change proxies or other intermediaries, but where if proxies or other intermediaries are updated to opt in, there's a way for both the client and server to know that, and to be able to make certain default assumptions, for instance how long the connection is held open even if completely idle. Do you have a concrete proposal?

Regards,
Maciej