Re: [hybi] hum #3: Message

Dave Cridland <dave@cridland.net> Thu, 05 August 2010 21:04 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 9C0DA3A69E5 for <hybi@core3.amsl.com>; Thu, 5 Aug 2010 14:04:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.482
X-Spam-Level:
X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 lxYiAO5bHcSS for <hybi@core3.amsl.com>; Thu, 5 Aug 2010 14:04:36 -0700 (PDT)
Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by core3.amsl.com (Postfix) with ESMTP id 561063A6A08 for <hybi@ietf.org>; Thu, 5 Aug 2010 14:04:35 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 8F4BF116809F; Thu, 5 Aug 2010 22:05:01 +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 G9YjEZ2ZdtGI; Thu, 5 Aug 2010 22:05:00 +0100 (BST)
Received: from puncture (puncture [217.155.137.60]) by peirce.dave.cridland.net (Postfix) with ESMTPA id DD397116809E; Thu, 5 Aug 2010 22:04:59 +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>
In-Reply-To: <AANLkTim1WeCRfcPxXUNQcVhb4+t_TtDQDv2bXaxOQ=bk@mail.gmail.com>
MIME-Version: 1.0
Message-Id: <2286.1281042299.901340@puncture>
Date: Thu, 05 Aug 2010 22:04:59 +0100
From: Dave Cridland <dave@cridland.net>
To: Jack Moffitt <jack@collecta.com>, Server-Initiated HTTP <hybi@ietf.org>, Julian Reschke <julian.reschke@gmx.de>
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:04:39 -0000

On Thu Aug  5 21:43:03 2010, 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.

Right - the only case it'll be faster over a WebSocket is where the  
latency of a new TCP connection (to transport the HTTP) outweighs the  
transfer time. Full-on mega sneakiness could cause even that to go.

I think a key reason why chunking hasn't caught on in the HTTP space  
is actually because - since it didn't exist to begin with - it's  
never gained the momentum. When things are available and supported by  
a protocol as the "norm" from the get-go, you tend to see that  
feature used much more.

Otherwise, you'd be perfectly entitled not all that long ago, to say  
that virtually all binary data was base64 encoded anyway, so we  
didn't need 8-bit capable protocols. But FTP, to an extent, and HTTP  
more so, meant that binary data became expected there. Yet it's still  
a rarity to see it in email, where it was added later (yet still  
years and years ago).

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