5

The D-Bus specification says that

D-Bus is.. a simple way for applications to talk to one another... Currently the communicating applications are on one computer...

I would like something like D-Bus but to work across multiple Linux machines, and there may be firewalls involved. For example, if my mail server decides it receives an important message, I would like it to post an event to the bus that my computer at home can see and perhaps respond by launching a linpopup window.

The events I'm interested in are relatively infrequent, so a low-performance technique is OK. But I would prefer not to reinvent any wheels. I would also prefer that as much as possible is written in shell scripts or other high-level languages and as little as possible in C (but I am willing to call C APIs if that is what it takes).

The way I interpret the official D-Bus web pages, they say it would be nice to get D-Bus to talk to multiple computers, but it doesn't work.

Edit: What's attractive to me about D-Bus is the model of publish and subscribe:

  • A machine that observes an interesting event publishes that event to "the system".

  • A machine that is curious about particular events subscribes just to those events. When an event happens, "the system" lets the machine know.

In D-Bus, "the system" is a single machine. I want something similar for multiple machines. This rules out direct solutions like TCP or SMTP communicating between machines. But I am happy to have a central server which receives all publication and subscription requests. I'm beginning to think it would be easier to build my own than to understand the Advanced Message Queueing Protocol (AMQCP), which is too darn advanced for the likes of me.

Performance is no object. Simplicity is definitely an object.

Once more: What software should I look at?

Norman Ramsey
  • 198,648
  • 61
  • 360
  • 533
  • Is this question (and the [D-Bus remote doc](http://www.freedesktop.org/wiki/Software/DBusRemote)) out-of-date regarding the status of remote D-Bus? See [this other SO question](http://stackoverflow.com/questions/10158684/connecting-to-dbus-over-tcp). – Craig McQueen Jul 31 '13 at 02:25

8 Answers8

3

Since my research led me to this ancient question, and a lot has happened since, I'd like to add to it.

You want to have a look at MQTT which is a standard for IoT. It's an ISO and OASIS standard since 2016. http://mqtt.org/

It's very simple to use and designed to be lightweight. The principle is publish/subscribe.

A very nice implementation is Mosquitto https://mosquitto.org/ which is under the Eclipse umbrella. There are client libraries in the Eclipse Paho project at https://eclipse.org/paho/ .

Mattias Backman
  • 927
  • 12
  • 25
3

The "new thing" for managing messages and communication between apps, apparently is Rabbit.

Is an implementation of AMQP, that establishes messaing, routing and security...

check this:

http://www.rabbitmq.com

http://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protocol

Andor
  • 1,998
  • 3
  • 16
  • 24
  • Publish-and-subscribe is close to what I want but the AMQP specification sent me fleeing in terror. +1 anyway. – Norman Ramsey May 02 '09 at 17:35
  • As a last option, you could install a messaging system based on XMPP (Jabber), but with software as clients, instead of people... I've heard around that some people is using that kind of setup... Would that work for you? You have lots of libraries for connecting to XMPP, and also have servers, like OpenFire, that are extensible with plugins, so you can easily program the behavior it will have with messages... – Andor May 03 '09 at 11:10
3

You should search for messaging solutions but those depend on what language you intend to work in. Java has had this feature for a while, called JMS (Java Message Service). However other implementations exist.

  • ZeroMQ has API bindings for: C, C++, Python, .NET/Mono and more
  • OpenAMQ has API binding for: Python, Java, Ruby and C

I have no experience with the different frameworks so I can't tell you what to use, but you could give these a shot.

Andrioid
  • 3,362
  • 4
  • 27
  • 31
1

A TCP/IP based message queue (MQ) / message oriented middle ware (MOM) solution should meet your needs. Most mature offerings provide native-language bindings for a variety of languages. I've had good luck with ActiveMQ, it has a CLI interface that might suffice for simple scripting tasks.

A bit of background can be found here: http://en.wikipedia.org/wiki/Message-oriented_middleware

Good luck,

Shannon

1

Maybe I'm missing the point (entirely possible!), but why not just use SMTP and send e-mail messages? Or TCP packets, and have a listener program on the other side?

Andy Mikula
  • 16,796
  • 4
  • 32
  • 39
  • I'd prefer not to reinvent any wheels. Machines go up and down; listener programs are a pain to write; machines behind a firewall can TCP out but others can't TCP in. There are a *lot* of issues and design questions; I'd like to build on an existing infrastructure. – Norman Ramsey May 01 '09 at 23:31
  • SMTP is a great idea. The message passing infrastructure is all there, a firewall isn't going to stop properly relayed messages going in or out, and procmail + your favorite shell script should handle the rest. – vezult May 02 '09 at 00:55
1

I know of no ready-made solutions like this.

My suggestion is that you write scripts that use curl or wget to send HTTP POST requests to a very simple web application, containing your info. And another machine polls the same web in intervals and GETs the info.

Comet can improve the polling nastiness, but will probably require more effort.

hayalci
  • 4,089
  • 2
  • 27
  • 30
0

You should consider bridging D-Bus messages between the machines. Write a message bridge app that would receive D-Bus messages, filter them and send certain messages on to an AMQP topic exchange. This could easily be done with RabbitMQ as the MQ broker and it is worthwhile to take the time to learn the AMQP model. The RabbitMQ site is filled with docs, tutorials, blogs and FAQs.

A typical use of AMQP is to have a message producer process, and then a message consumer process which could be on a different machine. The producer simply connects to a Broker, and then publishes messages into a topic exchange with a routing key tag. The Exchange is a process on the Broker that routes messages onto Queues. A message consumer also connects to a broker, but it may not be the same broker. Then the consumer declares a Queue name to use. and bind that Queue name to a named Exchange with a binding key. The binding key is a pattern which is matched against any routing keys coming into the exchange. In the simplest case the routing key and binding key are the same, but it is more interesting when the binding includes wildcard patterns.

If you really don't want to learn AMQP then use 0MQ to bridge the machines. 0MQ is much simpler and basically allows you to have sockets with multiple endpoints.

Michael Dillon
  • 31,973
  • 6
  • 70
  • 106
0

If you are interested in trying a lower layer protocol, you could try SOAP. Its not as efficient as binary protocols, and you would have to do the higher level queueing yourself, but it can operate through web proxies and via SMTP servers. There is a decent PERL implementation that I have experimented with before.

For more info:

http://www.w3schools.com/soap/default.asp

Jay Dubya
  • 119
  • 2
  • Thanks; what do you perceive as the benefit to using XML and HTTP? (I'm reluctant to pay the angle-bracket tax.) – Norman Ramsey May 03 '09 at 23:18
  • HTTP because you can avoid firewalling/proxy issues. XML is suboptimal, but SOAP is a standard with multiple implementations on multiple platforms that have hopefully had their bugs (mostly) flattened. The SOAP::Lite implementation also has a number of simple but annoying things like compression, SSL and authentication already taken care of for you leaving you able to concentrate on the higher level implementation – Jay Dubya May 04 '09 at 03:49