Comments on: Juggernaut: Comet for Rails?

By: Michael Carter

Michael Carter — Tue, 31 Jul 2007 04:02:25 +0000

Juggernaut is not a good idea. In expressing this sentiment, I wrote an entire blog post. I believe this article to be factually incorrect, and my reasons are posted on my blog.

By: Siuying

Siuying — Sun, 01 Jul 2007 18:10:46 +0000

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/

By: Nic

Nic — Sat, 12 May 2007 05:20:27 +0000

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/

By: -TMA-1- » links for 2006-11-06

-TMA-1- » links for 2006-11-06 — Mon, 06 Nov 2006 00:22:54 +0000

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

By: Anonymous

Anonymous — Sun, 15 Oct 2006 20:17:17 +0000

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.

By: Terry

Terry — Mon, 04 Sep 2006 13:09:31 +0000

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

By: Alex Russell

Alex Russell — Sun, 23 Jul 2006 04:59:07 +0000

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

By: W3C

W3C — Sat, 22 Jul 2006 01:52:27 +0000

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.

By: Alex MacCaw

Alex MacCaw — Fri, 21 Jul 2006 14:11:35 +0000

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 :)

By: Chris Hamilton

Chris Hamilton — Fri, 21 Jul 2006 13:45:22 +0000

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/

By: A Comet is coming

A Comet is coming — Fri, 21 Jul 2006 10:33:13 +0000

[...] 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) [...]

By: andr3a

andr3a — Fri, 21 Jul 2006 10:09:59 +0000

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

By: Alex Russell

Alex Russell — Fri, 21 Jul 2006 06:18:57 +0000

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

By: Mario

Mario — Fri, 21 Jul 2006 03:50:55 +0000

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

By: baker

baker — Fri, 21 Jul 2006 02:57:59 +0000

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

By: Alex Russell

Alex Russell — Thu, 20 Jul 2006 23:13:59 +0000

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

By: Alex MacCaw

Alex MacCaw — Thu, 20 Jul 2006 16:29:16 +0000

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.

By: Jay

Jay — Thu, 20 Jul 2006 16:09:18 +0000

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.

By: Drew

Drew — Thu, 20 Jul 2006 15:27:40 +0000

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.

By: Tom Trenka

Tom Trenka — Thu, 20 Jul 2006 14:55:00 +0000

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.