"These issues are irrelevant for connection-oriented and reliable unix sockets." This comment is really confusing to me. It's not irrelevant, you need to seria

"These issues are irrelevant for connection-oriented and reliable unix sockets." This comment is really confusing to me. It's not irrelevant, you need to serialize the messages somehow. And if you ever decide you want to add some new messages, then you have to deal with versioning. It's not simple. What you have described is just a cut down implementation of D-Bus. And you are leaving some other things out: - race-free name resolution, the solution you described has a lot of race conditions - message ordering, the best way to do this reliably across 3 or more processes is to use a bus-based method - security, auditing, rate limiting, i.e. how does a system admin manage your service. This is all solved with D-Bus I've seen lots of complaining about D-Bus over the years about how it's "too complex" but everything in it is there for a reason, and I've never seen anyone actually able to make a simpler design that works as well. If you implement all the stuff I just talked about then your solution will be about as complex as D-Bus. So in terms of message buses I actually think it is quite simple compared to other things like ActiveMQ. Please stop implementing ad-hoc protocols over a socket unless you have a really good reason to do that, it drives me nuts to see that stuff getting deployed and people going through the motions fixing the same bugs over and over. At the very least you could use protocol buffers, or use ASN.1, or re-use the D-Bus wire format, or do anything besides rolling your own.