Subject: [hybi] Interface for Large Frames

From: "Bob Gezelter" <[email-masked]>
Date: Wed, 22 Jun 2011 14:58:47 -0700

The FILE methods in stdio.h include a "number of bytes" parameter. In
the context of the WebSocket protocol, the natural unit would appear to
be the frame. Once the frame has been retrieved by a user, then a
character-by-character state machine may (emphasis MAY) be appropriate,
however, the interface is best (most efficient) if entire frames can be
transferred at a time.

If programs must pull one character at a time, the efficiency will be
poor, with a large amount of overhead being consumed moving up and down
the call tree.

For an example of how a past message-based protocol deal with this
issue, Digital's NSP (see citation below) is an example. NSP handled
long messages by segmentation, passing the segments in order to user
program.

- Bob Gezelter, http://www.rlgsc.com

Digital Equipment Corporation (1984, July) “DECnet DIGITAL Network
Architecture NSP Functional Specification, Phase IV, Version 4.0.1”,
Retrieved from http://linux-decnet.sourceforge.net/docs/nsp401.txt on
March 23, 2011

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 23 Jun 2011 00:15:01 +0200

Hi Bob,

> poor, with a large amount of overhead being consumed moving up and down

Obviously, and noone is recommending to do that! But the most common
read/write streaming loop is the appropriate way to do this in my
opinion, as it's done in any stream-based processor :

process_frame(int socket, int bytesleft)
{
    while (bytesleft > 0) {
        int bytes = read(socket, buffer, buffer_size);
        process(buffer, bytes);
        bytesleft -= bytes;
    }
}

Large frames will mostly be used for video streaming or file transfers.
It totally makes sense to use a loop similar to the above to write bytes
to disk (in case of file upload) or to pass the stream to the video
decoder. Here we're just facing a streaming protocol (which was the
goal of WebSockets since the beginning) so I don't see what's new here.

It is possible that the frames make people think they should process
them at once, but frames are just here to make streaming easier to
handle. It can be easier to think as an uninterrupted stream with
some occasional checkpoints.

Regards,
Willy

---

From: "Andy Green (林安廸)" <[email-masked]>
Date: Wed, 22 Jun 2011 23:18:04 +0100

> however, the interface is best (most efficient) if entire frames can be

That's true but it's inherently fragile when 63-bit length frames are 
allowed by the protocol but cannot be buffered.  It means there's a 
ceiling where the code must act different or break based on its 
buffering arrangements.

Requiring maximum frame size buffers per connection may also present 
scaling problems.

> poor, with a large amount of overhead being consumed moving up and down

Well, it depends.  You'll notice that "...and just buffer payload 
locally using any size buffer or none at all...", so buffering at the 
layer that contains the state machine is possible with this technique 
and reduces the calls to the handler dramatically even with a small 
buffer.  And with this technique, there's no dependency on that buffer 
size compared to max frame size so scalability is improved.

-Andy

---

From: Francis Brosnan Blázquez <[email-masked]>
Date: Thu, 23 Jun 2011 13:18:49 +0200

Hi Andy,

> ceiling where the code must act different or break based on its 

We have a framing with fragmentation support so each application could
decide how to handle such situations (63 bit frames), in some cases
better than stream oriented API because the application can choose the
chunk size it likes where stream oriented will return what is available
at the call time...

Whatever method used by a websocket implementation (stream oriented or
message/frame notification) I believe it is a contradiction to state
websocket is protocol designed to exchange *units* as messages but not
giving required elements to handle pointed situations, forcing people to
design stream oriented, and hence, force websocket users to
piece/buffering..

> Requiring maximum frame size buffers per connection may also present 

At the end, someone will buffer, or the websocket engine or the
application level. I think a checked websocket implementation will
buffer better than an application on top of it so, the scaling problem,
if present, will affect both methods...
-- 
Francis Brosnan Blázquez <[email-masked]>
ASPL
91 134 14 22 - 91 134 14 45 - 91 116 07 57

AVISO LEGAL
 
En virtud de lo dispuesto en la Ley Orgánica 15/1999, de 13 de
diciembre, de Protección de Datos de Carácter Personal, le informamos de
que sus datos de carácter personal, recogidos de fuentes accesibles al
público o datos que usted nos ha facilitado previamente, proceden de
bases de datos propiedad de Advanced Software Production Line, S.L.
(ASPL).
 
ASPL garantiza que los datos serán tratados con la finalidad de mantener
las oportunas relaciones comerciales o promocionales con usted o la
entidad que usted representa. No obstante, usted puede ejercitar sus
derechos de acceso, rectificación, cancelación y oposición dispuestos en
la mencionada Ley Orgánica, notificándolo por escrito a ASPL -
Protección Datos, C/Antonio Suárez 10 A-102, 28802, Alcalá de Henares
(Madrid).

---

From: Philipp Serafin <[email-masked]>
Date: Thu, 23 Jun 2011 13:25:19 +0200

> if present, will affect both methods...

Hasn't XMLHTTPRequest basically the same problem?
The current JS API for XHR makes it necessary for a browser to buffer
the complete response before passing it on to the JS layer. There also
don't seem to be any clear restrictions on the maximum size of a
resource fetched via XHR.
Maybe it could be useful to see how current browsers handle the edge
case of very large XHR responses?

Regards

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 23 Jun 2011 13:47:25 +0200

> case of very large XHR responses?

I expect the problem will be more in server side than in client side.

-- 
Iñaki Baz Castillo
<[email-masked]>