max_outgoing_bytes: What if a D-Bus peer is too slow to read?

[Colin Walters]

On Tue, Oct 5, 2010 at 2:31 PM, Alban Crequy
<alban.crequy at collabora.co.uk> wrote:
>
> Alternatively, we can drop the constraint that a peer cannot block all
> the communication on the bus; it can be useful for debugging if
> dbus-monitor is slow. It could be an option in session.conf.

Well, we could special case eavesdropping in some way; base it off
SystemTap say.  Or  disable kernel passing if a monitor is connected
(sort of unfortunate, but I think it makes sense to optimize for the
common case).

> In dbus-daemon, the current behaviour differs whether a recipient
> receives the message because it is the destination of the message or
> because it has a matching match rule on the message (eavesdropping):
> - For the destination recipient, the message is dropped and an error
>  message is sent to the sender.
> - For an eavesdropping recipient, the message is dropped without
>  notification.

Ok.  That sounds not too bad.  Our test coverage of this is probably
nonexistent though.

So thinking about this a little more, I was on crack with suggesting
dbus_connection_send() block; what we obviously want here is for a
method call (with no eavesdroppers active) that the bus queues the
message up at least until the method call timeout.

Really, we need this for signals too, it's pretty much equally as bad
if we can randomly lose them.

For the session bus, this seems like it'd be fairly straightforward to
implement.  The system bus would need per-uid limits on maximum total
size of queued messages.

The implications for a kernel implementation are more complicated; one
approach that comes to mind is that a client app can write its message
to the socket; if the kernel can't deliver it to some of them, it
writes back a special message "I failed to deliver to the following
recipients, please try again".  After that userspace could poll, which
would be lame, but then again we don't really expect this to happen
often.  Possibly there could be another special message which notifies
of non-full buffers for particular connections.

Shooting from the hip here admittedly, but the current state of
"reliable unless you happen to write 1G before a client reads" is
pretty lame.