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

Colin Walters walters at verbum.org
Tue Oct 5 07:36:44 PDT 2010


On Fri, Oct 1, 2010 at 10:15 AM, Havoc Pennington <hp at pobox.com> wrote:
>
> It may not be silent - you may find that an error reply is generated
> and returned to the sender.
>
> But yes, this sounds like correct behavior. If you limit the buffer

Well let's be clear - applications don't have control over the size of
the buffer that is shipped by the operating system.

> then the message can't be buffered and the only option is to fail the
> delivery. You have to either make the buffer large enough

"You" here is operating system vendors that include dbus?

> it's never exceeded

I assume we're defining "never" here as "under normal operating
conditions, disregarding buggy applications which may e.g. spam a
particular service on the bus".

> or you have to handle buffer-full errors.

How would applications handle this though?

Though one thing I would note is I might expect the behavior to differ
for method calls vs signals.  For method calls, one might desire for
dbus_connection_send() to block (thus restoring reliablity), even
though it's explicitly documented not to.  So a new method would have
to be introduced.

In the current codebase though, it seems to me we pretty much have to
say that dbus-daemon is not robust against buggy or malicious
applications which send too much data.


More information about the dbus mailing list