I've got three Raspberry Pis sitting around. I want 2 of them to be able to chat while the 3rd routes the messages (acts as a server between them).

The general flow of events should be something like this:

  • Server starts running on Pi #1
  • Pi #2 starts running and connects to the server (who's IP will be static I guess) with a name he chooses. Pi #3 does the same as #2.
  • Pi #3 can then, knowing the name of Pi #2, send a message to Pi #2 using ... something.

This is the general outline of what I want to achieve.

I'm not sure what the server that runs on Pi #1 should be (I've heard of webserver frameworks like Flask but I don't have enough knowledge to determine if they fit my needs).

I'm also not sure on what I should be using for the client side (Pi #2,3). I could probably use sockets but I assume there is a better / easier way.

  • You can indeed use Flask or web.py, or even Python's built-in SocketServer. But you only need this if you want to learn firsthand how to write a [makeshift] message-passing service. If you want to do something interesting with messages, take a ready-made framework like RabbitMQ, ZeroMQ, etc (see answers). – 9000 Aug 9 '14 at 0:35
  • @Shookie - is this a project that you'd like to use to learn about Python and networking, or something else? You might start from another place; choose an existing 'standard' like XMPP which seems to offer what you have described. There are several implementations. Set up a working system, then replace or expand pieces as you feel like it. I'm sure there is something lighter than XMPP, that is the first thing that I thought of. – gbulmer Aug 9 '14 at 2:36
  • @gbulmer - I know python and network "theory" however I have 0 experience in network programming. This is a small simplified part from a bigger project I'm working on. Eventually I'll also need to send and receive files between the two as well. – Shookie Aug 9 '14 at 8:09

You should look into message brokers like RabbitMQ and ActiveMQ. There are AMQP and STOMP client libraries in Python you can use with them.

Alternatively, if you want more control you could use ZeroMQ, but that will also require more work from you on the server side.

  • +1 for ZeroMQ which suits this scenario better – Thomas Junk Aug 9 '14 at 7:40
  • @ThomasJunk - Can you expand on why? – Shookie Aug 9 '14 at 8:13
  • @Derecho - Can the messages be sent in a secure manner in these ways? I'm concerned about impersonation in particular. – Shookie Aug 9 '14 at 9:21
  • @shookie Absolutely. Both RabbitMQ and the Python client Pika support SSL, for example. – Dan Ellis Aug 9 '14 at 18:17

Back in the days of old, one would indeed work and worry about sockets and the down and dirty of network programming. Those days are gone for nearly every modern language - there are easier solutions.

The essence of what you are describing is that of a message queue. These are things that have been built and can be used with rather little additional overhead.

There are two approaches to working with a message queue one to one messages and a publish/subscribe model (often written 'pubsub').

The essence of the one to one is that you connect to the server running a message queue and put a message on the queue, and you're done. Likewise, you can connect to the queue and get a message from the queue.

With a publish/subscribe model you've got something that is pushing messages out to one or more subscribers.

There are many more advanced topics that can be built on top of these with queues forwarding to other queues, or selectively accepting messages, or doing a remote procedure call on another system. The message queue is the underlying framework for a lot of different technologies.

Looking at RabbitMQ (just one of many - there are lots more out there) there is a specific tutorial for a single producer and consumer written in Python (and Java, and Ruby, and Php, and C#) that can be found under their tutorials page.

Pi #2 starts running and connects to the server (who's IP will be static I guess) with a name he chooses. Pi #3 does the same as #2.

Having a static server is indeed the easiest approach. The server is there and you're connecting to it.

However, if you want to go down the 'its not always a static IP address' because your dhcp server isn't cooperating nicely with that, there are technologies for this too.

Realize that I'm saying this in that I've never used RabbitMQ (ActiveMQ? WebSphere? yes... Rabbit, nope - but I've heard good things about it) nor been more than a user of this technology under other names...

Zeroconf. This is one implementation of the technologies that are known as zero configuration networking. The idea is your Pi #1, when it starts up its server would announce to the network "I have this service available!" and everyone else can then use it. It doesn't matter where Pi #1 is located on the network - its there.

This is how some IP cameras work - you look on your local network and you'll see the camera broadcasting its address and a program that can discover it on the network, can do so.

Specifically for RabbitMQ, I've stumbled across this gist which appears to announce to the network that "hey, there's an MQ server here" and now your Pi #1 can show up anywhere on the network and things will work. Because they always work the first time you deal with a technology Though it may take some additional understanding and delving into this. I wouldn't suggest doing this as a first step - get it working with some message queue server working on a static ip address, and then start seeing about making it broadcast from the static IP address, and then let it grab a dynamic address. Don't go down that particular heh rabbit hole at first.

  • This looks really promising! Thanks! I also like how you added the zero-configuration networking. I was going to look into that later. Thanks for going the extra mile! :) – Shookie Aug 9 '14 at 8:16
  • @Shookie I haven't set up zeroconf anywhere - just noticed its use on cameras that are connected to the local network and also the occasional use of Bonjour (a zeroconf implementation) on the mac for connecting to printers, cameras, and the like. – user40980 Aug 9 '14 at 19:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.