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

Reply via email to