What about proxies? They can advertise a limit but the upstream server may have different limits. Short of opening extra connections to support the required amount of concurrency, seems like it should be able to tell the client it has reached a limit and to try again later... Sent from my iPad > On Nov 24, 2014, at 1:31 AM, Brad Fitzpatrick <brad@danga.com> wrote: > > >> On Sun, Nov 23, 2014 at 10:24 PM, Willy Tarreau <w@1wt.eu> wrote: >> On Sun, Nov 23, 2014 at 08:07:45PM -0800, Roberto Peon wrote: >> > Yup, modulo the lack of knowledge on the first RT or so... >> >> There's another case where network latency adds some uncertainty : >> when clients abort some streams from time to time and consider they >> can immediately open a new one as a replacement (the stop button or >> Ctrl-F5). It is possible that for internal scheduling reasons or >> flow control in the client, the abort is sent after the new stream >> is presented, and that from time to time a new stream is rejected. > > That's just a bad client. The frames from the client to the server are serialized over the one connection on which the limits apply. > > If the client is keeping its state under different locking than it orders its serialized frames on the connection, it's going to have all sorts of a bad time in any case. >
Received on Monday, 24 November 2014 11:47:10 UTC