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

[Colin Walters]

On Thu, Oct 7, 2010 at 2:25 PM, Alban Crequy
<alban.crequy at collabora.co.uk> wrote:
>
> Message deliveries should be atomic: either delivered to all recipients
> or none of them. Otherwise it would break the causal order:
> - A delivers the message M1 to B and C
> - C's queue is full, so M1 is delivered only to B
> - B receives M1 and sends M2 to C
> - C empties its queue and receives M2 from B
> - A tries again to deliver the first M1 to C
> - C received M1 and M2 in the wrong causal order

Hmm, but do we know of anything depending on this?  I can't think of a
scenario right now where A, B, C are all services that know of and
interact with each other in such a tightly coupled way.

Let's s/message/signal/ here under the assumption we can special-case
dbus-monitor.

One way to approach this might be to have the previously-blocked
process get notified of that (insert a special message to this
effect), for example, it could be an array of pending message serials.
 It then knows to wait and reorder the messages internally until the
other processes have sent.  There'd have to be a timeout on this side
too - I guess the pending list would have the time remaining for each.

> Also, if A terminates meanwhile, M1 would be delivered only to a subset
> of recipients.

True; we may have to take that hit.

> Just closing C's connection is easier.

Closing C's connection sounds very dangerous to me on the system bus.
For example, let C be NetworkManager, and there's a buggy app which
writes data faster than it can respond.  We shouldn't generally be
punishing the *receiver* here, but the sender (if we can).  Obviously
with a "dbus-send" scenario we can't punish the sending process, so we
may need to punish the sending UID (the one sending the most messages
say).