Loading ...
Sorry, an error occurred while loading the content.

Re: [ydn-javascript] Re: connection manager

Expand Messages
  • Alex Russell
    ... This relates specifically to HTTP 1.1 connections. IE bumps the limit to 4 connections when dealing with HTTP 1.0 and Mozilla always has a soft limit of
    Message 1 of 5 , May 3, 2006
    • 0 Attachment
      On Monday 01 May 2006 11:30 pm, kmcoleoz wrote:
      > Philip,
      >
      > > > I believe that I read the IE <= 6 is restricted to 2 concurrent
      > > > XMLHttpRequest calls at a time.
      > >
      > > It's not exactly IE <= 6, it's the HTTP specification that suggests
      > > that
      > > no more than 2 concurrent persistent connections be open to the
      > > same web server. See section 8.1.4 of RFC 2616:
      > > http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.1.4
      > >
      > > This isn't restricted to XHR requests, but all requests.

      This relates specifically to HTTP 1.1 connections. IE bumps the limit to
      4 connections when dealing with HTTP 1.0 and Mozilla always has a
      "soft" limit of 2 with a hard limit of 4 where 2 of the connections are
      allocated to a pool of longer-running requests and 2 are for "normal"
      request dispatch.

      > Cool, thanks for the specific reference. This then makes my wish for
      > an array of objects managed by connection manager even more viable,
      > IMHO.

      Why? The network stack is going to manage this stuff better than you'll
      be able to, unless the goal is to be able to garuntee return order.
      Writing this kind of abstraction on top of the async primitives is very
      straightforward in a language (like JS) that supports closures. Dojo's
      dojo.io.queueBind() is less than 50 lines.

      Regards

      --
      Alex Russell
      alex@...
      alex@... BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723
    • kmcoleoz
      Alex, ... limit to ... connections are ... for normal ... Good to know, thanks. ... you ll ... so a properly defined network stack controls these
      Message 2 of 5 , May 3, 2006
      • 0 Attachment
        Alex,

        > This relates specifically to HTTP 1.1 connections. IE bumps the
        limit to
        > 4 connections when dealing with HTTP 1.0 and Mozilla always has a
        > "soft" limit of 2 with a hard limit of 4 where 2 of the
        connections are
        > allocated to a pool of longer-running requests and 2 are
        for "normal"
        > request dispatch.

        Good to know, thanks.

        > Why? The network stack is going to manage this stuff better than
        you'll
        > be able to

        so a properly defined network stack controls these limitations?

        > unless the goal is to be able to garuntee return order.

        not really, nut that could be a side benefit.

        > Writing this kind of abstraction on top of the async primitives is
        very
        > straightforward in a language (like JS) that supports closures.
        Dojo's
        > dojo.io.queueBind() is less than 50 lines.

        Thanks for the heads up on this, I will check it out.

        Ken
      Your message has been successfully submitted and would be delivered to recipients shortly.