Re: [hybi] Max frame size

Francis Brosnan Blázquez <francis@aspl.es> Thu, 23 June 2011 11:01 UTC

Return-Path: <francis@aspl.es>
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 A055D11E807F for <hybi@ietfa.amsl.com>; Thu, 23 Jun 2011 04:01:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.584
X-Spam-Level: **
X-Spam-Status: No, score=2.584 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_ALMOST_IP=1.889, HOST_EQ_STATIC=1.172, HOST_EQ_STATICIP=1.511, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3]
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 k4fk2s29VAmh for <hybi@ietfa.amsl.com>; Thu, 23 Jun 2011 04:01:06 -0700 (PDT)
Received: from mail.aspl.es (196.Red-212-170-101.staticIP.rima-tde.net [212.170.101.196]) by ietfa.amsl.com (Postfix) with ESMTP id C120F9E8012 for <hybi@ietf.org>; Thu, 23 Jun 2011 04:01:04 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.aspl.es (Postfix) with ESMTP id 9D2761170003; Thu, 23 Jun 2011 13:01:01 +0200 (CEST)
X-Virus-Scanned: amavisd-new at aspl.es
Received: from mail.aspl.es ([127.0.0.1]) by localhost (dolphin.aspl.es [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RWeVjFTOkKT; Thu, 23 Jun 2011 13:01:00 +0200 (CEST)
Received: from [192.168.0.153] (unknown [89.7.176.101]) (Authenticated sender: acinom) by mail.aspl.es (Postfix) with ESMTPA id 1EBF51170001; Thu, 23 Jun 2011 13:01:00 +0200 (CEST)
From: Francis Brosnan =?ISO-8859-1?Q?Bl=E1zquez?= <francis@aspl.es>
To: Scott Ferguson <ferg@caucho.com>
In-Reply-To: <4E021121.5050409@caucho.com>
References: <1308720860.5393.18.camel@tot.local> <20110622060514.GF18843@1wt.eu> <1308738811.11941.704.camel@vulcan.aspl.local> <20110622122521.GA22198@1wt.eu> <1308756913.11941.823.camel@vulcan.aspl.local> <4E021121.5050409@caucho.com>
Content-Type: text/plain
Date: Thu, 23 Jun 2011 13:01:01 +0200
Message-Id: <1308826861.11268.47.camel@tot.local>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1
Content-Transfer-Encoding: 7bit
Cc: hybi@ietf.org
Subject: Re: [hybi] Max frame size
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: Thu, 23 Jun 2011 11:01:06 -0000

Hi Scott,

> >> I don't see the difference with frames. You can call the application saying
> >> "hey, here come 5 GB of data, please read them from this connection handle".
> > Ok, the way it should be done, assuming we have a message/frame oriented
> > protocol, is that the app level register a handler which is called every
> > time a single frame is received.
> 
> No. It's like a HTTP chunked POST, where the application receives a 
> stream of data, not the underlying HTTP chunks.
> 
> A server (or client) which exposes the frames as its primary API is 
> doing it wrong.

I think you are getting my wrong maybe because I mentioned "...which is
called every single frame is received", but obviously my point is
focused on the concept of having a handler called when a frame "with
useful app level data (message)", not control frames directed to the
engine.

>From websocket draft we can read:

   The WebSocket protocol uses this framing so that specifications that
   use the WebSocket protocol can expose such connections using an
   event-based mechanism instead of requiring users of those
   specifications to implement buffering and piecing together of
   messages manually.

This definition matches the handler concept I'm exposing and...current
websocket javascript API (on message event).

> > This way, the handler is called, for example, each 4k, so the handler
> > can receive those 5GB with minimum memory allocation and with the
> > security it handles messages not raw access to a file descriptor (with
> > the security and code complexity implications it has).
> 
> See stdio.h, specifically the FILE methods like fdopen, fread, fgets, 
> etc. That's the level of abstraction the application needs to see.

..and you really think this API is suitable for a message oriented
protocol? (I assuming your fread concept will return bytes as it comes
not complete messages)

While I see this API makes the buffering (max frame size) problem for
the websocket developer to be not an issue, is in fact not solving but
moving the problem to the app level where, again, the application will
have to buffer the content until a message is completed.

I still think we need a way to each party to notify its buffering or
message size limit capabilities, *mainly*, because we have a framing
designed to notify messages, defined as *units* by the draft, not
bytes...

> -- Scott
> 
> >> Regards,
> >> Willy
> >>
> 
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi