Though I don't specifically discuss boost::asio there, I believe some of the points made there apply. Also, last time I checked, boost::asio mandated linking with threads library (at least for some features) whereas Dasynq doesn't, and boost::asio didn't offer support for watching POSIX signals or child process termination (Dasynq does). Finally, the boost::asio multi-threading model is awkward, for reasons I try to explain here: https://davmac.wordpress.com/2016/06/18/boost-asio-and-resou...
> More importantly, this is an error which can happen purely on the client side. You don't need to compromise the node itself, you just need to compromise some peer between the client you wish to attack and the node. This is a larger attack surface and potentially allows you to force a reconnect and other bad things.
I don't understand what you mean by this. There aren't any peers between the client and the node. The node (socket) is owned by some process and the client has a connection to that socket.
> Or somebody closes your socket. There are several ways in which this can happen, most of them undesirable
Please tell me how a third party can close an anonymous socket connection between two processes (because if there really is a way to do that, it's a huge problem in a bunch of existing programs).
> You can, for instance, pass your socket to another process and it can (maliciously) close it
That won't have any effect; if you pass a socket to another process, it's a separate file descriptor in the other process. It can't close your file descriptor, and it can't close the socket since there remains an open descriptor.
> So you can't really pass your own sockets around, you need some protocol to obtain a new socket
Right; this is discussed in the blog post.
> Will this new socket be closed automatically if your parent closes the socket?
No. It's an independent connection. There's no way AFAIK to have two connections to the same socket where closing one will automatically close the other, even if you did want to do that, without kernel-level changes.
> The guarantee you have in an object capability system is that you can only communicate with a node if you have obtained its address (the capability to communicate) beforehand
This is also guaranteed by the file descriptor = handle model. If you don't have a file descriptor representing a channel to some particular service, you can't magically create one, not by guessing addresses or any other means.
> and this causes a lot of pain in the design of distributed algorithms
Hmm, usually distributed algorithms are used for distributed nodes - to which Bus1 doesn't apply; it's for local communication only (or did I miss something important)?
> Sadly, the author failed to read on the history of kdbus and AF_BUS
On the contrary, I've been following their development from the beginning, with some interest.
> This is more or less what dbus currently does
Actually D-Bus multiplexes all messages, so they all pass through the message bus daemon. What I'm proposing is clearly different.
> and has major issues with memory accounting
This is a valid technical point, though I'm not sure it's ever been a problem in practice and I'm not convinced it needed a whole new IPC mechanism to solve.
Let me clarify: this is exactly how D-Bus conceptually works right now. In practice of course D-Bus acts as a multiplexor for the communications also. It is, however, possible to send one half of a socket pair via a D-Bus message.
It's strange to me how often that particular quote, which was intended to be more humorous than anything (ok - I understand if most people don't think it's funny; that doesn't mean it wasn't meant to be) - is used as some kind of evidence that my ideas are wrong on a technical level, while never providing any actual technical analyses.
As for being biased; well, I've criticised SystemD and D-Bus and a whole slew of other pieces of software, and indeed that's more-or-less what the blog was originally for, but just because I do criticise does not mean that criticism is unwarranted. Where's your technical argument?
> Also some of the suggestions are downright dangerous
You give only one example, which I've rebutted below. I disagree with the assertion as a whole.
> this is another failure state that you add to every single connection, and which every single client has to handle
They already have to handle the node disappearing. The only difference is that you can sever the connection from particular handles via the process containing the node/socket, if it chooses to. Otherwise, there is no difference.
> I read the preceeding explanation as saying "here is a security guarantee that clients can rely on"
What particular guarantee is that? The whole point of the post was that you have the same guarantees, from a security perspective, with file descriptors.
> What is the alternative? Having unix domain sockets sprinkled somewhere in the file system where everyone with the right permissions can access them?
I think you've misunderstood me. Unix domain sockets do NOT have to be associated with a path in the file system (see socketpair function). You can have some kind of arbiter process (aka the D-Bus daemon) which hands out socket connections, just as you need (with Bus1) some way of handing out handles. This is exactly how D-Bus works right now.
> Maybe the ordering doesn't have to be globally consistent, but better safe than sorry.
So you build a whole new, Linux-only, IPC mechanism because it might be important to have global ordering, even though no-one's been able to identify a use case in which it matters?
I recently wrote a blog post discussion why I created Dasynq, here: https://davmac.wordpress.com/2017/12/17/introducing-dasynq/
Though I don't specifically discuss boost::asio there, I believe some of the points made there apply. Also, last time I checked, boost::asio mandated linking with threads library (at least for some features) whereas Dasynq doesn't, and boost::asio didn't offer support for watching POSIX signals or child process termination (Dasynq does). Finally, the boost::asio multi-threading model is awkward, for reasons I try to explain here: https://davmac.wordpress.com/2016/06/18/boost-asio-and-resou...