[jdev] JEP-0124: multiple HTTP connections

[Justin Karneges]

On Friday 03 February 2006 13:52, Peter Saint-Andre wrote:
> the connection manager fairly complex to code (and more complex than it
> needs to be unless there is some compelling reason to support multiple
> connections).

To explain this requires some polling background:

Suppose a client normally polls every 30 seconds, but the polling attempt only 
takes 2 seconds to complete.  This means that 28 seconds is spent without a 
communications channel, assuming the client never tries to send data during 
that period.  If the server is smart, it could wait before returning data, 
holding the connection open until data is ready.

There are two huge benefits to this server optimization:
  1) it has the potential to reduce the frequency the client will poll
  2) instead of, for example, having a 2 second receive window and a 28 second 
idle period, there could be a 30 second receive window.  Now if data arrives 
after 5 seconds, it is received instantly, instead of 25 seconds late.

However, there is a disadvantage you might notice.  While the server is 
holding the HTTP connection open, the client is unable to perform another 
HTTP POST.  Thus, while the server optimization may yield instantaneous 
received messages, sent messages will be stuck with, for example, a 28 second 
pending period.  If the server didn't perform this optimization at all, then 
sent messages could go out instantly.  So it becomes a tradeoff: we can have 
fast received messages or fast sent messages, but not both.

But this is under the assumption that you can only have one HTTP connection.  
If JEP-124 allows at least two connections, then the client can "sit" on one 
connection that the server holds open, for instantly receiving data, and it 
can create secondary channels as necessary for instantly sending data.  This 
would allow JEP-124 to perform nearly as well as TCP.

-Justin