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

[Alban Crequy]

Le Tue, 5 Oct 2010 11:01:13 -0400,
Havoc Pennington <hp at pobox.com> a écrit :

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

I was wondering what is the correct behaviour for an implementation of
the bus in the kernel. I was thinking about just closing the socket
when the outgoing queue is full (punishing the slow readers).

dbus-daemon chose another solution: not deliver the message and reply
an error to the sender if the problem was on the real destination
(but no error for an eavesdropping recipient).

In an implementation of the bus in the kernel, the queue in dbus-daemon
could be just replaced by the socket receiving queue in the kernel. We
cannot allocate indefinitely there.

SOCK_DGRAM Unix sockets has a limit of 10 messages by default. This
limit of 10 messages is really low compared to dbus-daemon's
max_incoming_bytes 1G. It can be changed
with /proc/sys/net/unix/max_dgram_qlen. But it cannot be changed on a
per-socket basis.

Alban