[PATCH] SPDY/3.1 protocol implementation

[Valentin V. Bartenev]

On Monday 27 January 2014 13:53:09 Piotr Sikora wrote:
> Hey Valentin,
> shouldn't SETTINGS_INITIAL_WINDOW_SIZE point to sc->init_window?

sc->init_window is intended to store the initial send window for new streams
that client tells us by sending SETTINGS frame (how much data we can send
to client from the start).  It's not the same window that we specify in
our SETTINGS for client, which in this case is the receive window (how much
data client is allowed to send to us).

> Or at least be hardcoded to NGX_SPDY_INIT_STREAM_WINDOW and not
> NGX_SPDY_STREAM_WINDOW?

Current receiving flow control implementation is pretty simple and effective:
we allow browser to send as much data as it wants.  That's why it is hardcoded
to the maximum value.

[..]
> Also, it seems that receiving window size is hardcoded to 2GBs, which
> makes flow control (which main point was to protect against single
> stream, for example big POST upload, taking over whole SPDY
> connection) totally useless. This value should be configureable or at
> the very least set to something much more reasonable than 2GBs.

No, it's actually browser's will to properly prioritize POST requests.

The receiving flow control has two uses for server:

 1. Preventing buffer bloat.  But it's not our case since
    nginx currently supports only buffered uploads, and
    buffers the whole request body anyway.

 2. It rather subcase of 1: preventing client from sending
    data till the moment when we actually need the body,
    (i.e. ngx_http_read_client_request_body() is called).

The last optimization can be useful for nginx, but it unnecessary
complicates implementation, what I would like to avoid at least
for a while.

  wbr, Valentin V. Bartenev