On Tue, 23 Oct 2012 00:01:29 -0400, Monty Brandenberg wrote: > On 10/22/2012 6:28 PM, Henri Beauchamp wrote: > > > In the current implementation, the new HTTP core can be configured to > > spawn from 12 to up to 256 (!) simultaneous connections... The texture > > fetcher code however never queues more than 40 requests at once, thus > > limiting the potential damages, but you might want to have a look at > > that and provide safer bounds before the new HTTP core gets used for > > more services in the viewer... > > No, the current HTTP code allows up to 12 concurrent connections with > a shipping default of 8. A debug control is available to *reduce* not > increase the concurrency.
>From indra/llcorehttp/_httpinternal.h: // Limits on connection counts const int HTTP_CONNECTION_LIMIT_DEFAULT = 8; const int HTTP_CONNECTION_LIMIT_MIN = 1; const int HTTP_CONNECTION_LIMIT_MAX = 256; So, yes you are right that the default is 8, but the maximum is 256, like I reported. Now, looking closer, there are two different limits. From indra/llcorehttp/httprequest.h: enum EClassPolicy { /// Limits the number of connections used for the class. CP_CONNECTION_LIMIT, /// Limits the number of connections used for a single /// literal address/port pair within the class. CP_PER_HOST_CONNECTION_LIMIT, /// Suitable requests are allowed to pipeline on their /// connections when they ask for it. CP_ENABLE_PIPELINING }; And in fact, llappcorehttp.cpp only touches CP_CONNECTION_LIMIT, so CP_PER_HOST_CONNECTION_LIMIT is kept at its default (8) whatever the TextureFetchConcurrency debug setting value, meaning the viewer never opens more than 8 simultaneous connections per HTTP server. I therefore think that, as it is used right now TextureFetchConcurrency is not really useful (there's already a hard-coded limit of 40 in lltexturefetch.cpp for the max number of simultaenously queued texture fetching requests: perhaps this number should be affected by TextureFetchConcurrency instead ?), and in fact, the CP_CONNECTION_LIMIT will need to be much greater than 8 or 12, once the new HTTP core is used for connecting to other servers than just texture servers (mesh, capabilities, etc). On the other hand, I agree that CP_PER_HOST_CONNECTION_LIMIT should be kept below a reasonnable maximum value (8 sounds good for pipelining requests, but non-pipelining ones could probably allow up to 32 which is the default for per-host connections in most HTTP servers). > I'm interested in having available a control > more refined than HTTP Textures on/off for people who have chronic > connectivity problems. My hope is that knocking back concurrency will > prevent certain routers from falling over. But other consumers, like > mesh fetch, may completely swamp any improvement that control might > offer. Unless the router is buggy, it shouldn't be impacted by the number of open sockets (at least not under 60K sockets)... Some protocols, such as torrent can use hundreds or even thousands of sockets at once. The true limit is server side. > > My backports allows from 8 to 32 simultaneous connections, with 12 as > > the default (i.e. same default as in viewer-http). > > You're running 50% hotter than I am. Stop eating all the sockets! :-) In fact no, because I didn't touch CP_PER_HOST_CONNECTION_LIMIT... ;-P Regards, Henri. _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges