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

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

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