[tomegun]

One should think the goals are conflicting, but they are not. The secret is that the order is partial, as you say, but from userspace's point of view it is indistinguishable from a total order. The only messages that are not well ordered are messages that can never interact, so it is not possible to observe the lack of order from userspace. I wrote up how it works here: https://github.com/bus1/bus1/wiki/Message-ordering

[gpderetta]

As long as processes communicate only via Bus1, yes, it is not possible, but there are plenty of other IPC systems on unix that can make the lack of total order manifest. Advertising it as a total order doesn't seems like a great idea.

[tomegun]

I don't see how. We should handle side-channel communication just fine. Care to give an example?

[gpderetta]

proc1 sends a message to proc2 via bus1, then sends a signal to proc3 via a shared memory channel by incrementing a counter in shared memory; proc3 sees the message and signals proc4 via bus2;

There is no partial ordering between proc1->proc2 and proc3->proc4 as the memory channels are invisible to bus1, but Proc2 and proc4 can detect the total ordering violation by using another counter in shared memory.

[tomegun]

Right, we only enforce the _order_ of message delivery, not the _time_ of deliver. I.e., consider the sequence of messages received on each peer, these sequences each respect a global, total order on all messages. But there are no timestamps on them, and no way to compare sequences from separate peers.