bus limits

[David Zeuthen]

On Sun, 2004-08-15 at 12:35 -0400, Havoc Pennington wrote:
> Hi,
> 
> On Sat, 2004-08-14 at 17:30, David Zeuthen wrote:
> > 
> > So, I've recently ran into the limits of the system message bus when
> > stress testing hal - (basically unplugging 10 USB devices at once,
> > leading to 50+ message calls at nearly the same time). The way I
> > discovered this was that some of the method calls to the service was
> > rejected by the bus with the message 'The maximum number of pending
> > replies per connection has been reached'. This limit, though
> > configurable from the system.conf file, defaults to 32. 
> 
> 32 is pretty much just made up, fwiw. We could change it.
> 

Yeah, but it would still be some weird constant though.

> > I do realize that the bus should be resistant to denial of service
> > attacks, but wouldn't it be better to just slow down traffic instead of
> > rejecting messages? Or at least make the limits per <policy> item in the
> > configuration file so e.g. messages from trusted sources, say hotplug
> > helpers, always get through. Because otherwise application programmers
> > will have to assume that every message can get lost and this leads to
> > more complicated code and thus more errors.
> 
> One approach might be to just stop reading new messages from a
> connection when a limit is reached, though that could lead to deadlocks
> so has its own dangers.
> 

Right.

> As Mike says there is a bug open where some unrelated problem was
> causing limits to be reached, so we should resolve that first and see if
> the problem goes away.
> 
> I think it's likely that app authors do have to assume every message can
> get lost - that's the nature of IPC and one reason "network transparent"
> isn't such a good idea. However, we should certainly make errors as
> infrequent as possible, because yes people will fail to write the error
> handling code (and often it's unclear even how to do it).

Ok, the way I 'solved' this was to reconsider whether it's appropriate
at all to use D-BUS for the purpose of the point-to-point communication
that is sending messages from a hotplug helper spawned by the kernel to
a daemon. 

It pretty much isn't; it's private communication between two components
of the same software package (in this case hal), that's not entirely
what D-BUS is for (well, maybe in point-to-point mode, but maybe not),
so now my hotplug helpers simply sends a datagram over a local socket to
the daemon process. Kind of a cop out, but, hey, it works for me :-)

David