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
