Re: [GIT PULL] kdbus for 4.1-rc1

[One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>]

> When trying to split apart problems, for dbus it's important to keep
> ordering guarantees.

Yes I assumed that - minus disconnection/reconnect and running out of
queue space. Some users also want priority queueing (with or without the
guarantee for the same priority). Many of the other systems that can use
a fast multicast messaging system have priority queues - which is one
reason the existing POSIX messaging has priority.

> That is, with dbus if I send a broadcast message, then send a unicast
> request to another client, then drop the connection causing the bus to
> broadcast that I've dropped; then the other client will see those
> things in that order - the broadcast, then the request, and then that
> I've dropped the connection.

That's a simple matter of refcounting the buffers 8). I'm not really
concerned about the low level queue side of things. The proposed
implementation looks horribly convoluted for what the sk_buff layer can
already do standing on one leg. We know how to implement that part
cleanly, and its probably not hard to nail onto AF_UNIX or to expand
posix message queues to provide that service (and maybe then even
convince POSIX about it)

If it was just "here's a general purpose multicast message service" in a
small clean chunk of code I'd be cheering it into the tree. Even if you
need complicated filter rules because we can use EBPF to allow the client
library to do really sophisticated filtering and avoid wakeups for noise.

It's the complexity, the attachment to a lot of state in kernel and the
fact it doesn't appear to solve the general purpose problems that bothers
me.

> By pushing everything through one queue, dbus is trying to reduce the
> number of codepaths in applications. Apps have a lot of new problems
> to solve if messages get their order scrambled.

And I assume any user space solution for that purpose would end up
re-ordering messages if they could get shuffled so its

> (dbus does NOT guarantee order across multiple clients, of course -
> there's no guarantee that all clients get the broadcast, before anyone
> gets the next message - each client has its own buffer on both read
> and write. The ordering is only with respect to each client's message
> stream.)
> 
> Ordering is vital for tracking state, because if you're sending out
> events to describe changes in state, the order of those changes is
> important.

Most of the time IMHO you don't want to listen to changes in state, you
want to notice that the state wasn't the value it was before and adapt.

> Of course there are more complex ways to handle this over in
> distributed-systems-world.

And publish/subscribe models - which for certain uses scale better, are
easier to make reliable and avoid a lot of the mess.

Alan