Which group messaging technology to use?

Question

I feel a little bit kind of confused — for about 24 hours I have been thinking which group broadcasting technology to use in my project.

Basically, what I need is:

• create groups (by some backend process)
• broadcast messages by any client (1:N, N:N)
• (potentially) direct messages (1:1)
• (important) authenticate/authorize clients with my own backend (say, through some kind of HTTP API)
• to be able to kick specific clients by backend process (or server plugin)

Here is what I will have:

1. Backend-related process(es) in either Ruby or Haxe
2. Frontend in JS+Haxe(Flash9) — in browser, so ideally communicating through 80/443, but not necessarily.

So, this technology will have to be easily accessible in Haxe for Flash and preferably Ruby.

I've been thinking about: RabbitMQ (or OpenAMQ), RabbitMQ+STOMP, ejabberd, ejabberd+BOSH, juggernaut (with a need to write a Haxe lib for it).

Any ideas/suggestions?

Sheepwalk

Answer 1

If you are going to be doing Flash dev have you looked at SmartfoxServer? It has everything you want and has native Flash client libraries. I used in on a project to manage 10s of thousands of connected users.

http://www.smartfoxserver.com/

Mod

although it looks really interesting – Sheepwalk

You can write backend scripts in Actionscript, Python or Java but it doesn't look like it has JRuby bindings. – Mod

Answer 2

Yurii,

RabbitMQ, Haxe and as3: http://geekrelief.wordpress.com/2008/12/15/hxamqp-amqp-with-haxe/

RabbitMQ, Ruby and ACLs: http://pastie.org/pastes/368315

You might also want to look at using Nanite with RabbitMQ to manage backend groups: http://brainspl.at/articles/2008/10/11/merbcamp-keynote-and-introducing-nanite

You say you need:

* broadcast messages by any client (1:N, N:N)
* (potentially) direct messages (1:1)

You can easily do both using RabbitMQ. RabbitMQ supports both cases, 1:N pubsub and 1:1 messaging, with 'direct' exchanges.

The direct exchange pattern is as follows:

Any publisher (group member) sends a message to the broker with a 'routing key' such as "yurii". RabbitMQ matches this key with subscription bindings in the routing table (aka "exchange") for you. Each binding represents a subscription by a queue, expressing interest in messages with a given routing key. When the routing and binding keys match, the message is then routed to queues for subsequent consumption by clients (group members). This works for 1:N and 1:1 cases; with N:N building on 1:N.

Introduction to the routing model: http://blogs.digitar.com/jjww/2009/01/rabbits-and-warrens/

General intro: http://google-ukdev.blogspot.com/2008/09/rabbitmq-tech-talk-at-google-london.html

You also require:

* (important) authenticate/authorize clients with my own backend (say, through some kind of HTTP API)

Please see the ACLs code for this (link above). There is also a HTTP interface to RabbitMQ but we have not yet combined the HTTP front end with the ACL code. That shouldn't hold oyu back though. Please come to the rabbitmq-discuss list where this topic has been talked about recently.

You also require:

* create groups (by some backend process)
* to be able to kick specific clients by backend process (or server plugin)

I suggest looking at how tools like Nanite and Workling do this. Group creation is not usually part of a messaging system, instead, in RabbitMQ, you create routing patterns using subscriptions. You can kick specific clients by sending messages to them by whichever key they have used to bind their consuming queue to the exchange.

Hope this helps!

alexis

Clarindaclarine

Answer 3

Well group communication is a slightly different beast than simple messaging / queuing.

Most group communication systems are commercial but there are two (that I know of) open-source / free you can take a look at:

• Spread Toolkit
• OpenAIS

Both of these might be tough to find Ruby bindings though. Spread, and probably OpenAIS, view clients as trusted so a browser based client doesn't make sense. You'd need to have your browser front-ends talk to a group client(s) on the back-end.

Karleenkarlen

Yeah, I knew about Spread, I developed an Objective Caml binding for it years ago... and it looks like Spread 4.0 has been released, what, about 3 yrs ago? Anyway, thanks :) – Sheepwalk

Answer 4

We've been using ActiveMQ. Our vendor who supplies our HR system is using Ruby/ActiveMQ to broadcast and receive updates.

http://activemq.apache.org/cross-language-clients.html

Orfield

Answer 5

Other open source message brokers which support the Stomp protocol are OpenMQ, which is included in GlassFish V3 and GlassFish 2.1.1 but also works standalone, and soon the JBoss message broker, HornetQ V2.1. OpenMQ supports temporary queues which are useful for a RPC style communication, but ActiveMQ offers some interesting features in the Stomp adapter too.

Chere