Real-time message passing to browser in Rails?

rubyonrails-talk
#1

Has anyone had any success getting "realtime" message passed to the
browser in Rails? I'm wondering if there's a helper or Prototype
snippet that can help pass messages to a "status" window.

Basically, I have an app that is doing system tasks, like running
command-line scripts and tailing logfiles. I want to show the output in
near-realtime, similar to what a user would see in a command-line
terminal window. Any ideas?

Thanks,
Nate Wiger
dangerrabbit.com

#2

Haven’t used it personally, but it sounds like you want Comet…

http://ajaxian.com/archives/juggernaut-comet-for-rails

#3

Nate wrote:

Has anyone had any success getting "realtime" message passed to the
browser in Rails? I'm wondering if there's a helper or Prototype
snippet that can help pass messages to a "status" window.

Here's my How To Chat post:

http://www.forbiddenweb.org/topic/130997/index.html

GMail reputedly chats by leaving the HTTP socket open. I wouldn't
tweak my server (and the prototype Ajax objects) just for a Status
panel.

Use periodically_call_remote to repeatedly call the status action on
the server. That's slow, and high-bandwidth, but completely stable. My
Chat post tells generally how.

Tip: Have one periodically_call_remote per page, and let it update
anything that needs updating, via render :update.

#4

Awesome, very nice, detailed chat post, thanks!

#5

If you happen to be using lighttpd...
http://www.refwell.com/blog/index.php/2007/01/25/full-dulpex-ajax-module-for-lighttpd/

#6

Just a little thing to keep in mind:

Keeping network sockets open can quickly saturate your server's
network stack and degrade performance to the point where no new
connections are accepted and the server grinds to a halt.

I am not sure what your user base is, but if you are expecting it to
be in the thousands, all connected with open sockets, then you should
really check what the upper socket limits for your server's network
stack are.

At the very least you should kill inactive sockets after a timeout. I
have not used either of the solutions mentioned in the replies but it
is highly likely that the have an idle timeout setting.

-christos