Re: [hybi] max frame size, was: frame length encoding

"Shelby Moore" <> Mon, 23 August 2010 11:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9B6A83A69F5 for <>; Mon, 23 Aug 2010 04:37:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.235
X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xgyN4YfiZUhY for <>; Mon, 23 Aug 2010 04:37:27 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id BB7C13A69EE for <>; Mon, 23 Aug 2010 04:36:24 -0700 (PDT)
Received: (qmail 25766 invoked by uid 65534); 23 Aug 2010 11:36:47 -0000
Received: from ([]) (SquirrelMail authenticated user by with HTTP; Mon, 23 Aug 2010 07:36:47 -0400
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <> <1282423311.2014.6.camel@tng> <> <1282435214.2014.14.camel@tng> <> <> <> <>
Date: Mon, 23 Aug 2010 07:36:47 -0400
From: "Shelby Moore" <>
To: "Pieter Hintjens" <>
User-Agent: SquirrelMail/1.4.20
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: Hybi <>
Subject: Re: [hybi] max frame size, was: frame length encoding
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 23 Aug 2010 11:37:31 -0000

> On Sun, Aug 22, 2010 at 6:50 PM, Julian Reschke <>
> wrote:
>> 32 bits has the advantage that it's big enough for almost all use case
>> we
>> can currently think of.
> At least one person has cited a case where a 31-bit length caused a
> failure.  It's also naive to design for today's use cases and ignore
> the basic rule that data volumes and sizes double every 24 months.
> 640K is enough for anyone, right?
> The only cases that really matter here are:
> - very short frames, where every byte is significant
> - very long frames, where any ceiling is significant
> Medium length frames can be treated as long frames with zero
> significant cost.  You could stick a 100-byte header on a 100K frame
> and it would not be significant.
> There is no point optimizing any case except the two: very short (trim
> space), very long (trim complexity).

On complexity of large frames:

"Tangentially, the limit can be if avg is too high, requiring intra-frame
(splitting) parallelization, which depends on the intra-core signalling
cost due to complexity of the state-machine for the frame data processing
(extension protocols, any application on top, etc)."

Btw, I appreciated Pieter's point very much.  WebSockets is at least TCP
over HTTP, not just Javascript push.

And I also think WebSockets should be TCP for WebApps, not just HTTP,
since WebApps was the main point of the original WhatG.

And that is why I proposed that we should not be ignoring the opportunity
to do P2P:
(whole thread)

I had a private discussion yesterday that went like this slam-dunk:

> You can't be the economy-of-scale of server farms (client-server)

What is the cost barrier that makes uneconomic the harvesting billions of
wasted CPU and network cycles?

> Centralized enables things that can't be done without, e.g. improved

There are distributed models to deal with spam.  The social network is one
model, which could be distributed.

But more importantly, there are probably very important apps that can only
be done distributed.  For example video chat.  It makes no sense for my
packets to go back to your server farm, when they can travel directly to
the person who is in my same island.  And downloading is another one.  No
sense that my packets can't come from someone else who is downloading at
same time.

But nobody can do P2P in a browser now.  Our hands are tied, so we don't
know what apps would be created.

> Windoze users won't switch to Linux, because they are too lazy to
> appreciate the freedom of rolling your own configuation.

Linsucks will never succeed in mass-market because it violates the
economic law of economy-of-scale, otherwise known as the maximum

People prefer a plethoria of diverse applications that are pre-programmed
to be close to what they want.  People prefer 0 complexity and one-click
use (no learning curve, nothing to memorize!). People don't want to waste
a single second of their life programming their TV remote control. Webapps
are the only way to converge users away from Windoze.
What you have now is mashups, not deep apps that are needed.

Turn on your Wake up on LAN folks.  Get the big picture.

> It's also naive to claim that WebSockets is only for JavaScript, only
> for dumb browsers, only for medium size data.  We're designing "TCP
> over HTTP" in a real sense and there are generations of applications
> that will use this, way beyond today's use cases.  Please, think of
> the children!
> -
> Pieter Hintjens
> iMatix -
> _______________________________________________
> hybi mailing list