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

[Havoc Pennington]

Hi,

On Tue, Oct 5, 2010 at 10:36 AM, Colin Walters <walters at verbum.org> wrote:
>
> Well let's be clear - applications don't have control over the size of
> the buffer that is shipped by the operating system.
>

I had the impression Alban was worried about memory for some embedded
setup or something. For a mainstream OS release we set the limit super
high, which is not a problem because we can grow memory infinitely
while stuff buffers and then let it drain back down. The only reason
to drop the limit is if you don't have swap.

Apps can call malloc() themselves anyhow after all.

>> or you have to handle buffer-full errors.
>
> How would applications handle this though?

They would have to throttle and resend or something like that. It is
not easy to handle, that's why the default limit is essentially
"infinite, unless something is super broken in which case we'll give
up eventually"

> 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.

IIRC the idea was that the per-connection or per-user limits were
supposed to be set enough lower than the total global limits that you
would need N users to break the global limits. I don't know if that is
still true or was ever completely true, but that was the general idea.

Havoc