Very Poor Man's Window for SPDY/3

‹prev | My Chain | next›

It seems that version 3 of SPDY is pretty serious about flow control. Last night I found that, when I neglected flow control, Chrome would simply drop SPDY data frames. Tonight, I hope to cobble together a solution that more or less works.

First up, I re-enable the socket buffering in node.js:

Connection.prototype.write = function write(data, encoding) {
  if (this.socket.writable) {
    // this.socket.setNoDelay();
    return this.socket.write(data, encoding);
  }
};

My hope is that this will provide enough buffering to "just work".

It does not as I still have Chrome informing my that it is no longer paying attention to me:

SPDY_SESSION_SEND_RST_STREAM
--> description = "Negative recv window size"
--> status = 1
--> stream_id = 7

Ah well, that would have been too easy. I notice that Socket in node.js has a pause() method, so I set an internal data transfer window to roughly 64kb, and pause the socket when it gets too low:

var internal_window = 64000;

Stream.prototype._writeData = function _writeData(fin, buffer) {
  internal_window = internal_window - buffer.length;
  if (internal_window < 0) {
    this.connection.socket.pause();
  }
  // ...
}

Of course that does not work either because pause() is for readable sockets, not writeable ones. It would help if I read documentation before making assumptions.

Sooo... it seems that I am suck with buffering data on my own. I start with the dumb approach first:

var internal_window = 64000;
var backlog = [];

Stream.prototype._writeData = function _writeData(fin, buffer) {
  internal_window = internal_window - buffer.length;
  if (internal_window < 0) {
    backlog.push([fin, buffer]);
    return;
  }

  // really write...
}

And that actually seems to work. Now when I load the page, I see part of the image:

There is much more to that image, but at least I am on the right track. I call it an early night here, but I will pick back up with this approach tomorrow.

Day #373