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

Re: [json] Re: jsonrequest and HTTP/1.1 message pipelining

Expand Messages
  • 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 1 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 2 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 3 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.