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

connection manager

Expand Messages
  • kmcoleoz
    G Day, I believe that I read the IE
    Message 1 of 5 , May 1, 2006
    • 0 Attachment
      G'Day,

      I believe that I read the IE <= 6 is restricted to 2 concurrent
      XMLHttpRequest calls at a time.

      Is this correct?

      If it is correct and since IE <= 6 will be around for sometime to
      come has anything been discussed about maybe allowing for a FIFO
      array of request objects and getting the connection manager when on
      IE <= 6 automatically popping and pushing requests when connections
      are available?

      This would save the user having to manager the requests. I am
      looking at converting several large applications currently using
      other DHTML methods to simulate AJAX type tasks that were written
      long before XMLHttpRequest was around. They typically use iframes
      in hidden DIV's and similar such black magic, but they gave AJAX
      like functionality before it was around. These methods were
      synchronous within each iframe and required many iframes for
      asynchronous connections all of which had to be managed by the
      programmer which ended up very messy.

      Just a thought!

      Thanks for a great library and feedback interface with this group.

      Ken
    • Philip Tellis
      ... It s not exactly IE
      Message 2 of 5 , May 1, 2006
      • 0 Attachment
        Sometime Today, k cobbled together some glyphs to say:

        > 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.

        Philip

        --
        In 1750 Issac Newton became discouraged when he fell up a flight of stairs.
      • kmcoleoz
        Philip, ... that ... web ... Cool, thanks for the specific reference. This then makes my wish for an array of objects managed by connection manager even more
        Message 3 of 5 , May 1, 2006
        • 0 Attachment
          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.

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

          Ken
        • 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 4 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 5 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.