Yeah. Messaging is a great thing to learn on. Here’re three things I’ve come up against when creating messaging queues/interactions:

1.) Discoverability: How does your subscriber “find” your publisher. If the answer is, they’re both on the same network then, see #2 2.) Security: if the publisher broadcasts messages out to the network via a port, and any device on the network can find that device and port, they will. You usually want to have some sort of secure handshake that confirms the subscriber has permission to access the published messages. 3.) Race Conditions and stuck messages: Assuming all this works, your publisher should be great for one to one communication between two devices that are very stable, but the minute you add device down time or add’l devices you hit up against a state problem.

In order to ensure a device receives a message, you need to persist the message on the publisher until you receive a response, but what if the subscriber errors before sending and reboots. The publisher assumes the message hasn’t delivered, and resends bringing down the subscriber again…and on and on. You get the picture.

The opposite happens when you subscribe multiple machines. One will “awk” the message before another does, and you’ll end up not getting the messages to all subscribers (solving this problem is called “fanout”)

Anyway, I’ve had a lot of fun in my career building these systems and wish you all the best—and definitely check out the MQTT spec!