Improved viewer and script communications (Re: [sldev] Puppettering Branch)

Teravus Ovares teravus at gmail.com
Mon Jun 9 10:39:42 PDT 2008


Can anyone confirm that the client does not use a library that respects this
2 connection limitation?   So far in testing, it appears that it does.
When two threads get stuck, it fails to do anything else via http.    We've
tried to use HTTP CAPS for inventory, and consistently, when the inventory
service runs slow, the client stops making *any* further http requests.

Best Regards

Teravus


On 6/9/08, Tateru Nino <tateru.nino at gmail.com> wrote:
>
> Actually it is not a mandate. A mandate would be a MUST NOT. This is a
> SHOULD NOT, specifically:
> "A single-user client SHOULD NOT maintain more than 2 connections with any
> server or proxy. A proxy SHOULD use up to 2*N connections to another server
> or proxy, where N is the number of simultaneously active users."
>
> I've got personal knowledge that the author did not intend the above to
> apply to situations like this. For the substrate to MSIE, however, it is
> entirely appropriate. Also, the above only applies to persistent
> connections, not non-persistent connections (applying the same guideline to
> non-persistent connections would cause problems that this guideline is
> intended to avoid).
>
> Just because you're doing HTTP, doesn't make you a part of the Web, and
> connection considerations in Web architecture over HTTP are different to
> other architectures over HTTP.
>
>
>
>
> Teravus Ovares wrote:
>
>> I also note, that according to Microsoft's kb article:
>>  "The HTTP 1.1 specification (RFC2616) mandates the two-connection limit.
>> The four-connection limit for HTTP 1.0 is a self-imposed restriction that
>> coincides with the standard that is used by a number of popular Web
>> browsers."
>>  You can read the article here:
>> http://support.microsoft.com/kb/183110
>>  You can read the RFC here:
>> http://www.faqs.org/rfcs/rfc2616.html
>>  Best Regards
>>  Teravus
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080609/3199c322/attachment.htm


More information about the SLDev mailing list