Monday, May 23, 2011

What Endian the SETTINGS SPDY Frame?

Today I begin my investigation of some things I did not quite understand while looking at SPDY requests and SPDY responses in detail. To get up to speed with the node-spdy codebase, I start with an easy one: the SETTINGS frame.

While examining the SPDY response SETTINGS frame last night, I noticed that it does not match up with the spec:

Specifically, the ID is wrong. The first octet ought to be an optional flag (0x1 = client should persist this setting; 0x2 = this is a persisted value). The actual value being set, 0x04 is not a valid SPDY SETTINGS frame flag, so I would guess that this is the ID. Per the SPDY draft (#2) spec, an ID of 0x04 is SETTINGS_MAX_CONCURRENT_STREAMS.

Looking through the node-spdy source, I see that a server is created with the following default options:

The zlib context being passed in is required to decompress/compress multiple frames over the course of a single connection. The settings are an object literal like that from the server core ({SETTINGS_MAX_CONCURRENT_STREAMS: 100}). The createSettingsFrame function then builds a buffer large enough to hold 4 bytes/octets describing the number of keys being set (one in this case) plus 8 bytes/octets for each key. The number of keys are written to the first four octets (via writeUInt32 / 32 bits). Next, the code iterates (using a reduce) over each key writing the ID in the first 32 bits and the value in the second 32 bits.

But why the use of little-endian byte order? All packets that I have seen so far have been in big-endian order—something the spec confirms:

All integer values, including length, version, and type, are in network byte order.