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

jsonrequest and HTTP/1.1 message pipelining

Expand Messages
  • Tyler Close
    Has any thought been given to specifying the use of HTTP/1.1 message pipelining with JSONRequest? The current specification says: The browser must be able to
    Message 1 of 7 , Dec 16, 2007
    • 0 Attachment
      Has any thought been given to specifying the use of HTTP/1.1 message
      pipelining with JSONRequest? The current specification says:

      "The browser must be able to keep open two requests per host per page.
      Excess requests will be queued."

      I'd rather the browser keep open one connection per host per page for
      use by JSONRequest and pipeline all requests over that one connection.
      In addition to making more efficient use of the network and reducing
      the impact of latency, this policy would also reduce the impact of
      network non-determinism on the correctness of the Javascript
      application. The current specification introduces a race condition
      between every pair of outstanding requests.

      This kind of policy could be expressed in the API by having the client
      instantiate a JSONRequest object and then send multiple requests to
      the same JSONRequest object. These requests are then guaranteed to be
      sent in order. Requests sent to separately instantiated JSONRequest
      objects would have no order specified and could be sent over separate
      connections.

      Thoughts?

      --Tyler

      --
      Use web-keys for RESTful access-control:
      http://waterken.sourceforge.net/

      Name your trusted sites to distinguish them from phishing sites.
      https://addons.mozilla.org/firefox/957/
    • Mark Nottingham
      Pipelining is often regarded as problematic, especially from the client side, because of uneven support in proxies and servers, as well as some uncomfortable
      Message 2 of 7 , Dec 17, 2007
      • 0 Attachment
        Pipelining is often regarded as problematic, especially from the client side, because of
        uneven support in proxies and servers, as well as some uncomfortable decisions you need
        to make about optimisation.

        Also, non-idempotent methods (e.g., POST, PUT) shouldn't be pipelined, so this effectively
        limits it to GET.

        Even with pipelining on a single connection, you can't make assumptions about messaging
        ordering. Intermediaries are allowed to (and do) split requests up and put them on
        different connections, which may have different routes back to the origin. Somewhat
        pathological, but entirely possible (I've seen configurations which would allow -- or even
        encourage -- this to happen).

        Cheers,

        --- In json@yahoogroups.com, "Tyler Close" <tyler.close@...> wrote:
        >
        > Has any thought been given to specifying the use of HTTP/1.1 message
        > pipelining with JSONRequest? The current specification says:
        >
        > "The browser must be able to keep open two requests per host per page.
        > Excess requests will be queued."
        >
        > I'd rather the browser keep open one connection per host per page for
        > use by JSONRequest and pipeline all requests over that one connection.
        > In addition to making more efficient use of the network and reducing
        > the impact of latency, this policy would also reduce the impact of
        > network non-determinism on the correctness of the Javascript
        > application. The current specification introduces a race condition
        > between every pair of outstanding requests.
        >
        > This kind of policy could be expressed in the API by having the client
        > instantiate a JSONRequest object and then send multiple requests to
        > the same JSONRequest object. These requests are then guaranteed to be
        > sent in order. Requests sent to separately instantiated JSONRequest
        > objects would have no order specified and could be sent over separate
        > connections.
        >
        > Thoughts?
        >
        > --Tyler
        >
        > --
        > Use web-keys for RESTful access-control:
        > http://waterken.sourceforge.net/
        >
        > Name your trusted sites to distinguish them from phishing sites.
        > https://addons.mozilla.org/firefox/957/
        >
      • Tyler Close
        Hi Mark, Thanks for the response. I ve got a few questions about your comments and am also wondering if it s feasible to work around the issues you raise. ...
        Message 3 of 7 , Dec 17, 2007
        • 0 Attachment
          Hi Mark,

          Thanks for the response. I've got a few questions about your comments
          and am also wondering if it's feasible to work around the issues you
          raise.

          On Dec 17, 2007 4:19 PM, Mark Nottingham <mnot@...> wrote:
          > Pipelining is often regarded as problematic, especially from the client
          > side, because of
          > uneven support in proxies and servers, as well as some uncomfortable
          > decisions you need
          > to make about optimisation.

          Could you elaborate on the optimization issues?

          For the server support, I was figuring the Javascript code would be
          signaling the server's support for message pipelining by virtue of
          asking that a set of requests be sent in order. For example, if the
          Javascript code sends multiple requests to the same JSONRequest
          instance, it's telling the browser that the server supports HTTP/1.1
          message pipelining.

          > Also, non-idempotent methods (e.g., POST, PUT) shouldn't be pipelined, so
          > this effectively limits it to GET.

          I remember reading something along these lines in RFC 2616, but the
          argument never made any sense to me. Perhaps you could clarify the
          issue. RFC 2616 contains some language about the client not knowing
          what state the server is in if the connection died with multiple
          outstanding POST requests, but the same is true if there is even one
          outstanding POST request. Also, the situation seems to be the same if
          the client is using multiple non-pipelined connections, since there
          may be multiple outstanding POST requests. I expect all the POST
          requests queued by the client also get sent out regardless of the
          status of the previous requests, so it seems like the client is in
          much the same predicament regardless of the use of pipelining.

          > Even with pipelining on a single connection, you can't make assumptions
          > about messaging
          > ordering. Intermediaries are allowed to (and do) split requests up and put
          > them on
          > different connections, which may have different routes back to the origin.
          > Somewhat
          > pathological, but entirely possible (I've seen configurations which would
          > allow -- or even
          > encourage -- this to happen).

          How about this: If there is no HTTP proxy, pipeline requests;
          otherwise, send the requests one at a time. So if the client asked
          that requests be ordered, this is guaranteed and performance is best
          effort. If the client doesn't care about ordering, but wants best
          performance, then it uses separately instantiated JSONRequest objects.
          Sound good?

          --Tyler

          --
          Use web-keys for RESTful access-control:
          http://waterken.sourceforge.net/

          Name your trusted sites to distinguish them from phishing sites.
          https://addons.mozilla.org/firefox/957/
        • Mark Nottingham
          ... There are several aspects, but if you have an outstanding request on a connection, and another request is queued, deciding whether it s more efficient to
          Message 4 of 7 , Dec 18, 2007
          • 0 Attachment
            On 2007/12/18, at 4:53 PM, Tyler Close wrote:
            > Hi Mark,
            >
            > Thanks for the response. I've got a few questions about your comments
            > and am also wondering if it's feasible to work around the issues you
            > raise.
            >
            > On Dec 17, 2007 4:19 PM, Mark Nottingham <mnot@...> wrote:
            > > Pipelining is often regarded as problematic, especially from the
            > client
            > > side, because of
            > > uneven support in proxies and servers, as well as some uncomfortable
            > > decisions you need
            > > to make about optimisation.
            >
            > Could you elaborate on the optimization issues?
            >
            There are several aspects, but if you have an outstanding request on a
            connection, and another request is queued, deciding whether it's more
            efficient to pipeline or to open a new connection (or, to wait for
            the other connection to clear) isn't always a simple thing to do. If
            the outstanding request takes a long time to process (either because
            the response is very large, or because it takes a lot of server-side
            processing time), it may be better to use your other connection.

            In cases where the resources on the server have low processing
            overhead and are relatively homogenous in size, pipelining works well.
            Subversion is a good example of this, and indeed it benefits from the
            use of pipelining. I'm personally not convinced it's a great solution
            when that isn't the case. YMMV.

            > > Also, non-idempotent methods (e.g., POST, PUT) shouldn't be
            > pipelined, so
            > > this effectively limits it to GET.
            >
            > I remember reading something along these lines in RFC 2616, but the
            > argument never made any sense to me. Perhaps you could clarify the
            > issue. RFC 2616 contains some language about the client not knowing
            > what state the server is in if the connection died with multiple
            > outstanding POST requests, but the same is true if there is even one
            > outstanding POST request. Also, the situation seems to be the same if
            > the client is using multiple non-pipelined connections, since there
            > may be multiple outstanding POST requests.
            >
            Well, it's a SHOULD NOT, not a MUST NOT, but consider a sequence of
            PUT and DELETE requests; if they're pipelined and the connection drops
            in the middle, the client has no idea what state the world is in; if
            it doesn't pipeline, it still has to figure out whether the last
            request was applied, but not the previous ones.

            Also, keep in mind that connections in an intermediary aren't
            necessarily "sticky" to one client; a proxy may be using one single
            persistent connection to send requests from several clients to a
            single server. If pipelining of nonidempotent requests were allowed
            here, the failure cases get really ugly.

            > I expect all the POST
            > requests queued by the client also get sent out regardless of the
            > status of the previous requests, so it seems like the client is in
            > much the same predicament regardless of the use of pipelining.
            >
            Hopefully not...

            > > Even with pipelining on a single connection, you can't make
            > assumptions
            > > about messaging
            > > ordering. Intermediaries are allowed to (and do) split requests up
            > and put
            > > them on
            > > different connections, which may have different routes back to the
            > origin.
            > > Somewhat
            > > pathological, but entirely possible (I've seen configurations
            > which would
            > > allow -- or even
            > > encourage -- this to happen).
            >
            > How about this: If there is no HTTP proxy, pipeline requests;
            > otherwise, send the requests one at a time. So if the client asked
            > that requests be ordered, this is guaranteed and performance is best
            > effort. If the client doesn't care about ordering, but wants best
            > performance, then it uses separately instantiated JSONRequest objects.
            > Sound good?
            >
            You don't always know whether there's an intermediary there;
            interception proxies (aka "transparent proxies") and HTTP accelerators
            aren't apparent to the client.

            --
            Mark Nottingham mnot@...
          • Tyler Close
            Hi Mark, I think message ordering and pipelining are really useful features, so I ld like to kick this around some more to see if there s something that could
            Message 5 of 7 , Dec 31, 2007
            • 0 Attachment
              Hi Mark,

              I think message ordering and pipelining are really useful features, so
              I'ld like to kick this around some more to see if there's something
              that could work. For example, I've seen some web applications that
              implement their own request boxcarring to compensate for the lack of
              pipelining. At this point, they are basically tunneling their own
              protocol through HTTP and so not getting many of the benefits of HTTP,
              such as caching.

              On Dec 18, 2007 9:06 PM, Mark Nottingham <mnot@...> wrote:
              > There are several aspects, but if you have an outstanding request on a
              > connection, and another request is queued, deciding whether it's more
              > efficient to pipeline or to open a new connection (or, to wait for
              > the other connection to clear) isn't always a simple thing to do. If
              > the outstanding request takes a long time to process (either because
              > the response is very large, or because it takes a lot of server-side
              > processing time), it may be better to use your other connection.

              Seems like this logic is something that should be expressed by the end
              client. So if the client issued requests like:

              JSONRequest.post(...);
              JSONRequest.post(...);

              it's saying there is no expected ordering and the browser should use
              separate connections if possible. Whereas if the client issued
              requests like:

              var c = JSONRequest.ordered();
              c.post(...);
              c.post(...);

              it's saying these requests must be ordered and the browser should
              pipeline over a single connection if possible.

              > > How about this: If there is no HTTP proxy, pipeline requests;
              > > otherwise, send the requests one at a time. So if the client asked
              > > that requests be ordered, this is guaranteed and performance is best
              > > effort. If the client doesn't care about ordering, but wants best
              > > performance, then it uses separately instantiated JSONRequest objects.
              > > Sound good?
              > >
              > You don't always know whether there's an intermediary there;
              > interception proxies (aka "transparent proxies") and HTTP accelerators
              > aren't apparent to the client.

              OK then, SSL to the rescue. For the case where the client asks that
              requests be sent in order:

              1. If its an HTTPS connection, open a single connection and pipeline
              the requests.
              2. Otherwise, open a single connection and send requests synchronously.

              For requests that don't use the ordered request API, they can be sent
              as they currently are, over multiple connections.

              This seems like a small amount of complexity to add, while gaining the
              benefits of message ordering and pipelining when making secure
              web-applications.

              I suppose there could be some server-side infrastructure that again
              "helps" the developer by re-ordering requests, but the web-application
              developer is presumably in a better position to do something about
              this. Are there any other gremlins?

              Thanks,
              --Tyler

              --
              Use web-keys for RESTful access-control:
              http://waterken.sourceforge.net/

              Name your trusted sites to distinguish them from phishing sites.
              https://addons.mozilla.org/firefox/957/
            • Mark Nottingham
              Hm. Personally, I wouldn t go this way; you re making a bet that the overhead of setting up SSL/TLS is less than that of working synchronously. If you re just
              Message 6 of 7 , Jan 1, 2008
              • 0 Attachment
                Hm.

                Personally, I wouldn't go this way; you're making a bet that the
                overhead of setting up SSL/TLS is less than that of working
                synchronously. If you're just POSTing stuff to the server, combining
                several things into one request format may be the way to go.

                That having been said -- if you are going to use https, you'll need to
                have an API available that guarantees to give you a single connection
                back. XHR doesn't do that.

                I totally agree that pipelining is useful, and reducing latency is a
                good goal. It's just that the proper place to fix this sort of thing
                is lower in the stack, not higher.

                Cheers,


                On 01/01/2008, at 7:24 AM, Tyler Close wrote:

                > Hi Mark,
                >
                > I think message ordering and pipelining are really useful features, so
                > I'ld like to kick this around some more to see if there's something
                > that could work. For example, I've seen some web applications that
                > implement their own request boxcarring to compensate for the lack of
                > pipelining. At this point, they are basically tunneling their own
                > protocol through HTTP and so not getting many of the benefits of HTTP,
                > such as caching.
                >
                > On Dec 18, 2007 9:06 PM, Mark Nottingham <mnot@...> wrote:
                > > There are several aspects, but if you have an outstanding request
                > on a
                > > connection, and another request is queued, deciding whether it's
                > more
                > > efficient to pipeline or to open a new connection (or, to wait for
                > > the other connection to clear) isn't always a simple thing to do. If
                > > the outstanding request takes a long time to process (either because
                > > the response is very large, or because it takes a lot of server-side
                > > processing time), it may be better to use your other connection.
                >
                > Seems like this logic is something that should be expressed by the end
                > client. So if the client issued requests like:
                >
                > JSONRequest.post(...);
                > JSONRequest.post(...);
                >
                > it's saying there is no expected ordering and the browser should use
                > separate connections if possible. Whereas if the client issued
                > requests like:
                >
                > var c = JSONRequest.ordered();
                > c.post(...);
                > c.post(...);
                >
                > it's saying these requests must be ordered and the browser should
                > pipeline over a single connection if possible.
                >
                > > > How about this: If there is no HTTP proxy, pipeline requests;
                > > > otherwise, send the requests one at a time. So if the client asked
                > > > that requests be ordered, this is guaranteed and performance is
                > best
                > > > effort. If the client doesn't care about ordering, but wants best
                > > > performance, then it uses separately instantiated JSONRequest
                > objects.
                > > > Sound good?
                > > >
                > > You don't always know whether there's an intermediary there;
                > > interception proxies (aka "transparent proxies") and HTTP
                > accelerators
                > > aren't apparent to the client.
                >
                > OK then, SSL to the rescue. For the case where the client asks that
                > requests be sent in order:
                >
                > 1. If its an HTTPS connection, open a single connection and pipeline
                > the requests.
                > 2. Otherwise, open a single connection and send requests
                > synchronously.
                >
                > For requests that don't use the ordered request API, they can be sent
                > as they currently are, over multiple connections.
                >
                > This seems like a small amount of complexity to add, while gaining the
                > benefits of message ordering and pipelining when making secure
                > web-applications.
                >
                > I suppose there could be some server-side infrastructure that again
                > "helps" the developer by re-ordering requests, but the web-application
                > developer is presumably in a better position to do something about
                > this. Are there any other gremlins?
                >
                > Thanks,
                > --Tyler
                >
                > --
                > Use web-keys for RESTful access-control:
                > http://waterken.sourceforge.net/
                >
                > Name your trusted sites to distinguish them from phishing sites.
                > https://addons.mozilla.org/firefox/957/
                >
                >

                --
                Mark Nottingham mnot@...
              • Karthik Kumar
                ... Not all browsers support pipelining. Opera has it enabled, Firefox has it disabled by default; The browser must be able to handle it transparently to the
                Message 7 of 7 , Jan 1, 2008
                • 0 Attachment
                  On Jan 2, 2008 11:15 AM, Mark Nottingham <mnot@...> wrote:
                  >
                  >
                  >
                  >
                  >
                  >
                  > Hm.
                  >
                  > Personally, I wouldn't go this way; you're making a bet that the
                  > overhead of setting up SSL/TLS is less than that of working
                  > synchronously. If you're just POSTing stuff to the server, combining
                  > several things into one request format may be the way to go.
                  >
                  > That having been said -- if you are going to use https, you'll need to
                  > have an API available that guarantees to give you a single connection
                  > back. XHR doesn't do that.
                  >
                  > I totally agree that pipelining is useful, and reducing latency is a
                  > good goal. It's just that the proper place to fix this sort of thing
                  > is lower in the stack, not higher.
                  >
                  > Cheers,
                  >
                  > On 01/01/2008, at 7:24 AM, Tyler Close wrote:
                  >
                  > > Hi Mark,
                  > >
                  > > I think message ordering and pipelining are really useful features, so
                  > > I'ld like to kick this around some more to see if there's something
                  > > that could work. For example, I've seen some web applications that
                  > > implement their own request boxcarring to compensate for the lack of
                  > > pipelining. At this point, they are basically tunneling their own
                  > > protocol through HTTP and so not getting many of the benefits of HTTP,
                  > > such as caching.
                  > >
                  > > On Dec 18, 2007 9:06 PM, Mark Nottingham <mnot@...> wrote:
                  > > > There are several aspects, but if you have an outstanding request
                  > > on a
                  > > > connection, and another request is queued, deciding whether it's
                  > > more
                  > > > efficient to pipeline or to open a new connection (or, to wait for
                  > > > the other connection to clear) isn't always a simple thing to do. If
                  > > > the outstanding request takes a long time to process (either because
                  > > > the response is very large, or because it takes a lot of server-side
                  > > > processing time), it may be better to use your other connection.
                  > >
                  > > Seems like this logic is something that should be expressed by the end
                  > > client. So if the client issued requests like:
                  > >
                  > > JSONRequest.post(...);
                  > > JSONRequest.post(...);
                  > >
                  > > it's saying there is no expected ordering and the browser should use
                  > > separate connections if possible. Whereas if the client issued
                  > > requests like:
                  > >
                  > > var c = JSONRequest.ordered();
                  > > c.post(...);
                  > > c.post(...);
                  > >
                  > > it's saying these requests must be ordered and the browser should
                  > > pipeline over a single connection if possible.
                  > >

                  Not all browsers support pipelining. Opera has it enabled, Firefox has
                  it disabled by default; The browser must be able to handle it
                  transparently to the JS app; Synchronous requests with browser-side
                  polling may benefit from pipelining; Pipelining effects are good only
                  for small-sized requests; So the browser should determine when to
                  pipeline or not (depending on immediately receiving the response
                  content-length)

                  > > > > How about this: If there is no HTTP proxy, pipeline requests;
                  > > > > otherwise, send the requests one at a time. So if the client asked
                  > > > > that requests be ordered, this is guaranteed and performance is
                  > > best
                  > > > > effort. If the client doesn't care about ordering, but wants best
                  > > > > performance, then it uses separately instantiated JSONRequest
                  > > objects.
                  > > > > Sound good?
                  > > > >
                  > > > You don't always know whether there's an intermediary there;
                  > > > interception proxies (aka "transparent proxies") and HTTP
                  > > accelerators
                  > > > aren't apparent to the client.
                  > >
                  > > OK then, SSL to the rescue. For the case where the client asks that
                  > > requests be sent in order:
                  > >
                  > > 1. If its an HTTPS connection, open a single connection and pipeline
                  > > the requests.
                  > > 2. Otherwise, open a single connection and send requests
                  > > synchronously.
                  > >
                  > > For requests that don't use the ordered request API, they can be sent
                  > > as they currently are, over multiple connections.
                  > >
                  > > This seems like a small amount of complexity to add, while gaining the
                  > > benefits of message ordering and pipelining when making secure
                  > > web-applications.
                  > >
                  > > I suppose there could be some server-side infrastructure that again
                  > > "helps" the developer by re-ordering requests, but the web-application
                  > > developer is presumably in a better position to do something about
                  > > this. Are there any other gremlins?
                  > >
                  > > Thanks,
                  > > --Tyler
                  > >
                  > > --
                  > > Use web-keys for RESTful access-control:
                  > > http://waterken.sourceforge.net/
                  > >
                  > > Name your trusted sites to distinguish them from phishing sites.
                  > > https://addons.mozilla.org/firefox/957/
                  > >
                  > >
                  >
                  > --
                  > Mark Nottingham mnot@...
                  >
                  >



                  --
                  Karthik
                  http://guilt.bafsoft.net
                Your message has been successfully submitted and would be delivered to recipients shortly.