From: Robert Klemme <shortcutter@...>
Date: 2009-11-30T02:55:08+09:00
Subject: Re: Which server component?

On 11/29/2009 06:12 PM, Tim Bennen wrote:

>> Correct. So the client must send a request GET /messages (say). If the 
>> server responds immediately with 'no message available' then the client 
>> must poll periodically. If the server blocks and doesn't send a response 
>> until there is one, then you get COMET. If you're running COMET with 
>> something like Apache or nginx in front, you need to beware that they 
>> may time out idle connections, there may be some tweaking to do.
> Hm, that's a problem, because if something happened on the server, and 
> the user should be notified, I have to poll every 2-3 seconds and that's 
> a lot of data, because the clients could be mobile devices and that's 
> expensive.

In that case it sounds like as if HTTP was not the ideal protocol for 
the task.  Maybe you should rather follow the other direction and think 
about a solution with EventMachine as Brian has sketched.  That way you 
can also have better control over the protocol overhead - HTTP can be 
quite verbose if your messages are really small (say 50 bytes or so): 
the ratio of payload to protocol wouldn't be too good in that case.

> Using Rack/Mongrel or Apache/Mongrel/Rack the connection could be 
> established as persistent?

AFAIK with HTTP even if the client indicates he wants to stay connected 
the server is free to drop the connection if he feels like it (e.g. 
running low on open file descriptors, too much idle time etc.  Brian 
hinted in the same direction).  That, too, seems like a reason to look 
at something other than HTTP.  My 0.02 EUR anyway.

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/