Re: [hybi] hum #3: Message

[John Tamplin <[e-mail]>]

On Thu, Aug 5, 2010 at 3:31 PM, Ian Hickson <[e-mail]> wrote:

> I was trying to express both.
>
> Having to split a 2GB file into a bazilion pieces and write each one out
> individually with frame headers, compared to just writing the whole thing
> at once, seems inefficient far beyond simply the concern about the
> on-the-wire overhead.


Assuming you don't care about buffering requirements on the client and you
only care about the case where you already have the entire data to send in
memory and you don't care about compressing the output, then I agree just
doing write(socket, buf, len) is easier.  However, it isn't much easier
than:

while(len > MAX_FRAME_SIZE) {
  writeHeader(socket, true, MAX_FRAME_SIZE);
  write(socket, buf, MAX_FRAME_SIZE);
  buf+=MAX_FRAME_SIZE;
  len-= MAX_FRAME_SIZE;
}
writeHeader(socket, false, len);
write(socket, buf, len);

Also, you have previously stated that you expect compression to always be
used once we get around to supporting it.  I have given pseudocode
previously of what the compression loop looks like -- if I have to send the
length for everything up front, I have to complete compressing the entire
data before I can send one byte over the wire.  I have to have an
arbitrarily large output buffer (which means reallocating it with multiple
copies), which is inefficient.

Finally, there are cases where the WebSocket server isn't the ultimate
source of the data to send, so requiring a length up-front means buffering
every byte from the source before you can write a single byte on the
WebSocket connection.  If instead I have fragments, I can use a fixed-size
buffer that I never have to reallocate, read the data from the server, and
write individual WebSocket frames as that buffer fills.

Regarding the small-frame case -- a variable-length length field is only
more efficient than fixed length if the payload data is between 0 and 127
bytes.  In that case, the extra byte required seems insignificant to the
TCP/IP overhead for a small packet, where even mobile devices don't use IP
header compression.  Again, this doesn't seem to rise up to "quite
inefficient".

When considering inefficient beyond bytes on the wire, consider these two
receivers:

int len = 0;
int c;
do {
  c = readByte(socket);
  len = (len << 7) + (c & 127);
} while(c & 128);
(re)allocate buf[len]
read(socket, buf, len);

vs

struct WSHeader hdr;
read(socket, &hdr, sizeof(hdr));
fixup byteorder
// buf is preallocated to be the maximum size frame
read(socket, buf, hdr.len);

[ignoring error handling of course]

The former again requires either many allocations/frees of the buffer or
reallocating it as larger frames are seen, and more system calls.

-- 
John A. Tamplin
Software Engineer (GWT), Google