On Fri, Feb 22, 2013 at 8:16 AM, Martin Thomson <martin.thomson@gmail.com>wrote: > On 22 February 2013 05:18, Roberto Peon <grmocg@gmail.com> wrote: > > Why 1? > > 1 seems a little restrictive, especially since 6 concurrent > connections is the current expectation in many browsers. > > > If a client sends 8 concurrent streams, and the server only wants to > handle > > 6 (say, because it is particularly resource limited right now), then it > will > > reset two of the streams with an error code that essentially says > > try-again-later, and it can do so after sending the SETTINGS frame. > > This is not isomorphic with a lower stream limit simply because the > client will have sent some amount of data for the 2 rejected streams, > expending some of what is a fairly limited resource (INIT CWD being as > it is). That's probably OK if you consider that it's the client > prerogative and responsibility. > Well, we get to waste resources either way unless the default MAX_STREAMS is already optimal (fat chance)-- one way wastes bandwidth by pushing at most 1 BDP worth of bytes on the wire, and the other has the connection idle for a BDP or more. :/ I'm guessing that the latter ends up dominating thanks to short NAT timeouts, etc, when a user comes back to the browser after some period of being idle. Also, assuming we do keep persisted SETTINGS, then the impact of opening up too many streams becomes even more limited as it happens far more rarely. -=R
Received on Friday, 22 February 2013 16:27:27 UTC