> but in practice with UNIX socket, you have issues like "which instance owns the socket", "how are the requests distributed", "how does an instance know the current handler died"
While bus-based publish-subscribe paradigm may have some merit in desktop setting, for direct control the client-server is much more straightforward, and in this case these answers are easy. Each instance owns one socket, if there are multiple instances and not a default one, a client needs to know which to connect to (as they are generally not interchangable), and even if they are, a client can just enumerate sockets and open the first alive.
> "how to serialise and version the remote requests"
These issues are irrelevant for connection-oriented and reliable unix sockets.
> Dbus solves a lot of that without (effectively) designing your own custom underspecified version of half of dbus.
Not really. Connection-oriented client-server solution is just much simpler that dbus and offers some advantages like implicit state associated with connection. Dbus makes things much more complicated and then solves some of these complications.
"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.
While bus-based publish-subscribe paradigm may have some merit in desktop setting, for direct control the client-server is much more straightforward, and in this case these answers are easy. Each instance owns one socket, if there are multiple instances and not a default one, a client needs to know which to connect to (as they are generally not interchangable), and even if they are, a client can just enumerate sockets and open the first alive.
> "how to serialise and version the remote requests"
These issues are irrelevant for connection-oriented and reliable unix sockets.
> Dbus solves a lot of that without (effectively) designing your own custom underspecified version of half of dbus.
Not really. Connection-oriented client-server solution is just much simpler that dbus and offers some advantages like implicit state associated with connection. Dbus makes things much more complicated and then solves some of these complications.