connect response for long-polling channels

[Markus Joschko]

Hi list,
I'm wondering whether a server is expected to keep the connection for a
/meta/connect request open in case of a long-polling request or if he
should immediately return.

Normally I would guess that the connection should be kept open but the
dojo client code expects the connectionId in the response of the
connect request. If not given the next messages (e.g. subscribe) will
pass a null value as connectionId.

So
- either the client code needs to be adopted
- or the server needs to return immediately
- or I have overseen the obvious and posted too early ;-)

Regards,
Markus

[Markus Joschko]

Whee, I meant long-polling connections. Why must I always skip the
preview :-(

[Chris Barber]

Hi Markus,

There's two things that your talking about: the connection and the request.  If you are implementing your own server, it's kinda up to you whether you want to keep the connection open after the request is processed.

If you should support HTTP/1.0, then by default, connections are closed immediately after the request is processed.  If the client supports keep-alives, then the client should notify the server in the HTTP headers that keep-alives should be used.  If the server is to use keep-alives, then the HTTP response headers will specify that keep-alives are enabled.

If you should support HTTP/1.1, then by default connections are kept open for a few minutes after a request is processed.  Web browsers are allowed to keep up to two connections per domain and up to four domains per page open at any time.

For example, using Dojo with long polling to connect to a HTTP/1.1 compliant comet server, the web browser fires an XMLHttpRequest to open the connection to the server and send the request (/meta/handshake if first time).  The server processes the request and sends a response, but keeps the connection open.  The browser will reuse that connection for future requests.  Assuming you have already handshaked and subscribed to a channel, when Dojo connects to /meta/connect, the browser will fire an XMLHttpRequest using the already open connection and if the server has messages queued for that channel, the messages are simply returned, thus ending the request, but the connection remains open.  If the server didn't have any messages, then the connection is parked until a message arrives or a timeout (usually 30 seconds or so) is exceeded.  When the XMLHttpRequest returns, it will request another /meta/connect using the existing connection and life is good.

So, keeping the connection open is good for performance, but remember that you'll effectively tie up one of your allowed connections.  It would be a good idea to put your website on www.mysite.com and the comet server on comet.mysite.com.  This page has lots of good information.

Note, not all transports follow this re-request pattern.  The iframe transport leverages HTTP's chunked encoding and the request can remain open for a very long time.

So, in a perfect world, the connection on the server side should be kept open until the client disconnects or for a couple minutes after the last request, but the request should only live as long as it takes to get the queued messages or the timeout period waiting for messages.

Hope this helps.

-Chris

[Markus Joschko]

hey chris,
Thanks for the in depth information. There were some new information
included for me.

I think I have to adjust my terminology ;-) Let me rephrase the last
mail this time with XMLHttpRequest instead of connection.

With "long-polling" the XMLHttpRequest will be closed after a response
from the server. That still means that if I want to transfer the
connectionId as a result from the /meta/connect back to the client I
need to close the request immediately. After that a /meta/reconnect/
will happen and that XMLHttpRequest can be kept open for some time.

The question whether the server should return immediately or the
client should not expect to have the connectionId after sending a
/meta/connect still remains

After reading your mail I would assume that the server should send the
response immediately (and therefore close the request), as it is a
limitation of the long-polling transport that the response can't be
send without closing the request.

Is that true?

Regards,
Markus

[David Davis]

On 11/27/06, Markus Joschko <markus....@gmail.com> wrote:

Hi list,
I'm wondering whether a server is expected to keep the connection for a
/meta/connect request open in case of a long-polling request or if he
should immediately return.

It should return immediately.

[Chris Barber]

Markus Joschko wrote:

hey chris,
Thanks for the in depth information. There were some new information
included for me.

I think I have to adjust my terminology ;-) Let me rephrase the last
mail this time with XMLHttpRequest instead of connection.

With "long-polling" the XMLHttpRequest will be closed after a response
from the server. That still means that if I want to transfer the
connectionId as a result from the /meta/connect back to the client I
need to close the request immediately. After that a /meta/reconnect/
will happen and that XMLHttpRequest can be kept open for some time.

The question whether the server should return immediately or the
client should not expect to have the connectionId after sending a
/meta/connect still remains
  

From what I've gathered, the server should return immediately and the response should contain a connectionId that will be used by the client when issuing /meta/reconnect requests.

After reading your mail I would assume that the server should send the
response immediately (and therefore close the request), as it is a
limitation of the long-polling transport that the response can't be
send without closing the request.

Is that true?
  

Yes, that is my understanding.

Regards,
 Markus

-Chris

[Markus Joschko]

Thanks everybody.

Markus