Re: [hybi] hum #3: Message

Dave Cridland <dave@cridland.net> Thu, 05 August 2010 21:24 UTC

Return-Path: <dave@cridland.net>
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 BEB133A68D5 for <hybi@core3.amsl.com>; Thu, 5 Aug 2010 14:24:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.486
X-Spam-Level:
X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599]
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 KHQN115o+kAR for <hybi@core3.amsl.com>; Thu, 5 Aug 2010 14:24:32 -0700 (PDT)
Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by core3.amsl.com (Postfix) with ESMTP id 2A6FA3A688D for <hybi@ietf.org>; Thu, 5 Aug 2010 14:24:32 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 4DF2D116809F; Thu, 5 Aug 2010 22:25:02 +0100 (BST)
X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net
Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (localhost.localdomain [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SKabJTrZxbw; Thu, 5 Aug 2010 22:25:00 +0100 (BST)
Received: from puncture (puncture [217.155.137.60]) by peirce.dave.cridland.net (Postfix) with ESMTPA id BB280116809E; Thu, 5 Aug 2010 22:25:00 +0100 (BST)
References: <4C5AE93D.4040803@ericsson.com> <Pine.LNX.4.64.1008051758290.5947@ps20323.dreamhostps.com> <AANLkTik0kbh14s2JZARY2MFh0iNGV7H+B4Px4yG+wX44@mail.gmail.com> <71BCE4BF-D3F6-4F94-BE76-306BDF6A2E67@apple.com> <Pine.LNX.4.64.1008051930160.5947@ps20323.dreamhostps.com> <4C5B1695.6070704@gmx.de> <F8E2F702-9F74-4316-B3B2-D5A731409ABF@apple.com> <4C5B2029.90403@gmx.de> <AANLkTim1WeCRfcPxXUNQcVhb4+t_TtDQDv2bXaxOQ=bk@mail.gmail.com> <01098AD0-FBF4-4A61-B565-947C95722BAA@apple.com> <C1A941B9-058C-4E1D-811A-92C94E18CBDE@apple.com>
In-Reply-To: <C1A941B9-058C-4E1D-811A-92C94E18CBDE@apple.com>
MIME-Version: 1.0
Message-Id: <2286.1281043500.752860@puncture>
Date: Thu, 05 Aug 2010 22:25:00 +0100
From: Dave Cridland <dave@cridland.net>
To: Maciej Stachowiak <mjs@apple.com>, Server-Initiated HTTP <hybi@ietf.org>
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
Subject: Re: [hybi] hum #3: Message
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: Thu, 05 Aug 2010 21:24:33 -0000

On Thu Aug  5 22:18:01 2010, Maciej Stachowiak wrote:
> 
> On Aug 5, 2010, at 2:09 PM, Maciej Stachowiak wrote:
> 
> >
> > On Aug 5, 2010, at 1:43 PM, Jack Moffitt wrote:
> >
> >>>> Sending a file from disk to the network without processing it  
> in any way
> >>>> is more efficient than cutting it into slices and interleaving  
> with headers.
> >>>> The IP layer is already going to cut it into slices, in a way  
> that almost
> >>>> certainly won't line up with WebSocket-level fragment  
> boundaries.
> >>>
> >>> There's no way to "send a file over the network without  
> processing". You
> >>> need to read it into memory, and then write it to the network.  
> Of course
> >>> adding frame headers *is* overhead, but it's really identical  
> or close to
> >>> the overhead on the wire, nothing more.
> >>
> >> The kernel's sendfile() is responsible for a lot of the HTTP  
> server
> >> optimization for static resources, and for this case, I think it  
> is
> >> true that doing any framing that shows up in the middle of the  
> file
> >> would lead to a big inefficiency.
> >>
> >> I'm not sure how useful this pattern is with dynamic data  
> though. I
> >> think people will continue to send most static resources via  
> regular
> >> HTTP because it is very, very good at it.
> >
> > I think there's definitely use cases for transferring large  
> static resources over WebSocket. Consider syncing a media library  
> where items may have been added on either end.  Sync seems like a  
> pretty likely target for WebSocket. You will want to do large  
> static transfers in both directions, and it seems better to use the  
> existing warmed-up WebSocket TCP connection than to make fresh HTTP  
> connections.
> 
> If it's an optional extension that intermediaries could ignore,  
> that makes it unlikely that there will be a default expectation  
> that it should be sent and have a correct value.

I'm fine withdefining the extension in the core spec, and making this  
a SHOULD. I can see cases meaning it cannot be a MUST. Would this  
satisfy?

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade