Thursday, July 20th, 2006

Juggernaut: Comet for Rails?

Category: Comet, Ruby, Toolkit

Alex MacCaw has released a plugin for Ruby on Rails that “aims to revolutionize your Rails app by letting the server initiate a connection and push data to the client. In other words your app can have a real time connection to the server with the advantage of instant updates.”

The plugin Juggernaut initiates a flash xmlsocket between server and browser allowing real time communication between the two. The open socket connection allows the server to ‘push’ base64 encoded javascript to the browser which is subsequently decoded and evaluated.

I see this as Comet for Rails, as it is about the interaction model not technology (e.g. if Flash or not). Alex may disagree :)

Frequently Asked Questions

What flash version does Juggernaut use?

Flash socket uses version 6 which is supported by more than 95% of users.

Does it work in all browsers?

It works in all the major ones: Firefox 1+, IE 6+ and Safari 2+.

What are the advantages/disadvantages of using a flash socket over other methods?

It’s better than comet because:

  • It’s much less of a hack
  • It doesn’t crash your browser (Comet can do this after a while)
  • 95% of browsers support it (flash 6).
  • It’s much easier to implement
  • It can use a different port – unlike comet – so you don’t need any custom dispatch servlets for forwarding messages through rails to the push server – it can connect directly.

It’s better than polling because:

  • Much cleaner
  • Doesn’t use as many server resources

Posted by Dion Almaer at 7:41 am
21 Comments

++++-
4.1 rating from 11 votes

21 Comments »

Comments feed TrackBack URI

Interesting.

I’m just curious: How does Juggernaut connect to a browser? If the browser initiates a connection, it is actually (the same as) Comet. If the server initiates the connection, you have a problem reaching browsers behind NAT routers.

Comment by Bart Guijt — July 20, 2006

The Browser has a flash plugin – which initiates a socket connection. Thus data can be sent both ways, from the browser to the push server (although this doesn’t happen in Juggernaut) and from the push server to the browser. If a browser wants to send a request it makes an ajax request to rails – which in turn opens up a socket connection to the push server – relaying the data. The push server than broadcasts the data to all clients. You’re right about trouble with firewalls. Flash can only make a xmlsocket connection to ports over 1024.

Comment by Alex MacCaw — July 20, 2006

I’m curious: why are you base64 encoding what amounts to a string? By doing that you’ve increased the size of all of your packets by 33%…it’s one thing if you’re sending out actual bytecode, it’s another if you’re encoding a stream of bytes that already represent a string.

Comment by Tom Trenka — July 20, 2006

The firewall trouble is HUGE. If you want your application to be usable inside corporate firewalls (and why wouldn’t you?) your persistent HTTP connections must be served on port 80 – nothing else will make it through the firewall. Doing it the other way, the dispatching is kind of annoying, but it’s really not that hard.

Also: why do this in rails? This seems like a terrible fit. By making the push server a simple relay, you’re making your life miserable. If, say, you want to log every chat message that comes in, every call to rails will have to hit the database, open a socket (non-trivial if you’re handling tons of chat messages) and pass the command to the push server. Lets complicate the issue a little bit. Say you want to enable different chat rooms. Each incoming chat message will need a chat room ID on it. You’ll have to do validation on those first, to make sure they’re valid room IDs. Once you’ve validated, you’ll have to see which users are in that chat room so you know who to send too. This means at least one select per chat message. So if you’re doing validation and logging, two queries per request minimum. This won’t scale for anything but the most trivial application.

Sorry to rain on your parade, but I think you should rethink your architecture. Rails is pretty, sure, but it’s just not for this.

Comment by Drew — July 20, 2006

Unless Adobe/Macromedia gets there act together that 95% is going to go down as more AMD64 machines are sold. I hate not having flash on my AMD64 desktop. But it has taught me a lesson. No website should _DEPEND_ on Flash.

Comment by Jay — July 20, 2006

RE Drew:
I agree – the firewall issue is a big one. There may be away around it however with flash 9’s binary sockets. However I wanted it to work for as large a range of people as possible at the moment – most people don’t have flash 9. Why do this in Rails? Because you can easily parse input , escape strings and html if needs be and then generate javascript with the RJS templates. Rails makes this so easy. The alternative is to have a client – that broadcasts by going straight through the push server. This is feasible, but you’d end up violating the MVC as you’d have too much code in the view. Another reason why I put rails in the middle is to authenticate any broadcasts. Again you could authenticate broadcasts straight through the push server – but again, Rails makes this so easy through sessions etc. I’ve already made a task manager with Juggernaut and, although this is not conclusive testing, it supports a large number of concurrent users. If you want speed – then the socket server could be rewritten in C – something not too taxing, surely. I have already thought about chat rooms – actually Richard White suggested it – and so Juggernaut has channels which clients can subscribe to. Messages can then be broadcasted on specific channels to the right clients. Stability is key and so I’m looking into beefing up the push server to handle many concurrent users. Also the push server needs to be separate from rails as rails uses Fast CGI so long requests would crash it.

Comment by Alex MacCaw — July 20, 2006

Too bad about the flash dependency. It’s not necessaray at all and will surely complicate deployment and debugging. For details on how to implement other client styles, see:

http://trac.dojotoolkit.org/browser/trunk/src/io/cometd.js

and:

http://svn.xantus.org/shortbus/trunk/cometd-twisted/cometd.py

Regards

Comment by Alex Russell — July 20, 2006

Something like FJax?
Visit http://www.fjax.net
Regards.

Comment by baker — July 20, 2006

I like the idea of using the flash seems nice. I will check out Alex Russell’s links (even though I dont like attacking a gnat with a Nuke) and I must say is it getting Smug in here 8P

Comment by Mario — July 20, 2006

Mario,

Hrm, dunno about smug, but I think there’s genuine excitement about seeing this stuff finally escaping out into the real world. I’m stoked to see the demos that Alex MacCaw is doubtless whipping up as we speak. FWIW, we are fully intending to do an XMLSocket provider for Cometd and provide for it in the protocol spec. It just makes sense, esp given its super-low-latency characteristics.

Alas, that doesn’t make it easier to debug ;-)

Regards

Comment by Alex Russell — July 21, 2006

Well done Alex, I’ve seen an application example and seems really cool!!! Flash player is free, V6 is available for all major platforms/browsers.
If you think that a web-app shouldn’t depend on free Flash Player, you should think that a web-app shouldn’t depend on javascript too because JS is not always present or enabled, isn’t right ? :D

Btw, if anyone is interested on JavaScript XMLSocket with Flash, here there’s “the base” ( of this project too ;-) )

See you

Comment by andr3a — July 21, 2006

[…] Posted by massive Fri, 21 Jul 2006 10:31:51 GMT There is a new plugin for RoR that allows the server to push data to browser. No more polling for Ajax. Well this isn’t Ajax anymore. It’s very Comety if you ask me (or Ajaxian) […]

Pingback by A Comet is coming — July 21, 2006

There’s really nothing revolutionary about this from a concept point of view. You’re basically describing message based architectures that people have been doing for a long time. I know you feel like you’re pioneering, but if you look at some of the free (and not free) msg/queue based systems out there, you’ll see that 90% of your “connection manager” code is already written and it scales, has fail over and load balancing.

Look at the ajax section of active MQ to see how you can do exactly what you’re saying without flash. This would never fly in enterprise because of the flash dependency and the apparent lack of scalability.

http://activemq.org/site/home.html

Tibco’s Messaging System
http://www.tibco.com/software/messaging/enterprisemessageservice.jsp

IBM (MQ SERIES)
http://www-306.ibm.com/software/integration/wmq/features/

Comment by Chris Hamilton — July 21, 2006

I’ve released a new version of Juggernaut that solves the firewall issue (it uses port 443 which should be unblocked with most companies).

RE: Alex Russell – debugging isn’t too difficult as you can just use flash’s ‘trace’ function to show any data being received. Glad to see you’re looking into using flash :)

Comment by Alex MacCaw — July 21, 2006

This SHIT is ILLEGAL, according to the HTTP Spec you Idiots. You cannot do this (ie push random shit) to the unsuspecting public.

Oh yeah, you desparados will learn it the hard way.

Oh what? No freaking client in existence today allows Keep-Alive connections. So, whacha gonna push.

IDIOTS.

Comment by W3C — July 21, 2006

hey W3C,

Every modern browser I’ve tested supports some variant of Comet, either via progressive-rendering hack, long-poll XHR, or mime multipart/x-mixed-replace. None of these violate the HTTP spec AFAIK. There’s nothing in RFC 2616 that notes that clients should close connections as soon as possible, only that they should only hold 2 concurrent connections open to any server at any time. None of this even relies on HTTP 1.1 keepalive. It’s just a server that doesn’t close a connection immediately.

Regardless, the Flash-based system that Juggernaut employs *doesn’t even use HTTP*. It may be sending XML over the wire, but it’s a custom full-duplex socket scheme supported only by Flash clients.

If there’s some part of RFC 2616 that we haven’t correctly understood, a section number would be a helpful reference.

Regards

Comment by Alex Russell — July 22, 2006

I tried this plus-in. It’s cool especially to implement a web page based online chat. While I meeting one problem as below:
I think it’s still about firewall things. The warning message is:
“there has been an error connectin. please check the push server and make sure your firewall has the correct ports open”
For my understanding, this is because of my adsl service provider block the 443 port, is it correct? Could you pls kindly advise on it? And is there some better solution to handle such problem?
Many thanks

Comment by Terry — September 4, 2006

Juggernaut — push content to your Rails app (comet)

Collaborative apps, from chat to real-time collaboration, can be created once you add the ability to push and pull data to and from your rails app. Find out how.

Trackback by Anonymous — October 15, 2006

[…] Ajaxian » Juggernaut: Comet for Rails? (tags: Tech WebDev AJAX Comet RubyOnRails) […]

Pingback by -TMA-1- » links for 2006-11-06 — November 5, 2006

A lot of work has been done updating Juggernaut since the last posts. Check here for the most up-to-date information:

http://ncavig.com/blog/

Comment by Nic — May 12, 2007

I have a experiment to use only Ruby on Rails + AJAX + Mongrel + ActiveMQ to archive same real time function without Flash dependency. Check it out here: http://www.reality.hk/articles/2007/07/01/736/

Comment by Siuying — July 1, 2007

Leave a comment

You must be logged in to post a comment.