[rabbitmq-discuss] Exposing Erlang nodes/proceses through RabbitMQ

Tony Garnock-Jones tonyg at lshift.net
Wed Mar 3 23:10:54 GMT 2010

Hi Garrett,

This is really interesting topic. We thought about this a bit way back
when Rabbit was new. Things have moved on a bit since then, so perhaps
the time is right for taking another look.

Initially, we only had Erlang (and Java) libraries for speaking AMQP.
Since then, I've hacked together rabbitmq-c, which makes implementing an
Erlang distribution protocol perhaps possible, as the Erlang VM needs
its distribution protocols to be implemented in C, IIUC.

Garrett Smith wrote:
> I think brokers are a natural next step in dealing with these issues.

Yes, this makes sense. Some abstraction over the details of the network,
in a similar vein to the way SQL databases permit abstraction over the
file system.

> * Marshalling Erlang terms

term_to_binary/1 and binary_to_term/1 do nicely here :-)

> * Global process registry (e.g. sync'd fanout)

Hmm. State sync is tricky, but could be done, perhaps by addition of a
new stateful-exchange plugin? Like a "hashtable" exchange type.
(Actually maybe MikeB's LVC plugin could step in here?

Alternatively, standard election techniques for use with multicast media
could be implemented. Ick.

> * remote_process() ! term()

This is where the C-level VM hackery would come in.

> * rpc:xxx

I *think* this is mostly done at the Erlang level.

> The point of this would be to make transitioning to rabbitmq from a
> standard Erlang mesh as seamless as possible. E.g. gen_server:call/2
> would just work without much/any work for the developer.

It's a lovely idea.


More information about the rabbitmq-discuss mailing list