Take the 2-minute tour ×

I'm designing a system that is built on several small applications written in python, some of these will be services and others will be programs that only run during special situations. What I need to achieve is to let the server communicate to a service when a certain event occurs with some small amount of data. So that the service knows about the new situation and can take the appropriate action, sometimes immediately and sometimes in the future.

I've been looking at memcached, but it seems like an overkill solution for my system (which is just a few separate applications running on a raspberry pi), or writing to files and using something like pyinotify but I don't think that is very elegant and finally I've been thinking about storing state in a database which I also don't like very much.

Are there any preferred ways to handle this sort of communication between processes that I haven't thought of(I'm sure there is) or which of the above mentioned ones would be the smartest to go with?

share|improve this question
I don't know about Python specifically, but a good place to get some ideas might be here: en.wikipedia.org/wiki/Inter-process_communication –  FrustratedWithFormsDesigner Mar 1 '13 at 15:04
ZeroMQ –  Yannis Rizos Mar 1 '13 at 15:14
add comment

2 Answers

up vote 1 down vote accepted

To my knowledge, the only standard for specific technologies is "whatever works for your needs."

That said, you might want to look into Redis. I've used it before to communicate between disparate systems, and it works well.

Basically, what it is is an in-memory datastore. You set the service to watch for a specific key, and when your system does something with that watched key, the service reacts.

In a more general sense, what you're asking for is often known as a "pub-sub" (publisher-subscriber) setup. So if Redis doesn't work for you, you might be able to use the more general term to find a solution that does work. And really, if you wanted to, you could leverage Twitter to be the intermediary, if you really wanted to (the system would post a tweet, and the service would watch the twitter feed for updates). If I recall correctly, GitHub uses Hubot and Campfire in a similar manner (Hubot sits in a Campfire chat room, waiting for someone to send commands, to which Hubot responds).

share|improve this answer
Thank you, I'll try to go with redis, which seems to be a nice solution for this. –  Daniel Figueroa Mar 1 '13 at 20:59
add comment

There is no need to use an external service, you can use sockets.
At least if you have one-to-one communications, if there are many listeners for certain events, a pub-sub solution, like @Shauna recommended, might be better.

for an overview on sockets and their use in python see the docs

share|improve this answer
add comment

Your Answer


