bus limits

[Havoc Pennington]

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.

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

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

Havoc