bus limits

[David Zeuthen]

On Sun, 2004-08-15 at 17:43 -0400, Havoc Pennington wrote:
> Hi,
> 
> Something to think about here, if I'm app A communicating with apps B
> and C, in the blocking proposal if B stopped responding and pending
> replies accumulated, then app A would no longer be able to talk to app
> C. So app B can effectively shut down app A entirely, by causing app A
> to block (the bus stops reading from app A until app B replies).
> 
> It'd be worth thinking about approaches other than shutting down app A
> in this case. One might be to expire the timeout on the oldest pending
> request for app B.
> 
> Of course, this still sends an error to app A saying that a method call
> on app B failed... which is the whole problem we were trying to solve
> ;-)
> 

One way to get around this would be to enforce the limits per
connection-pair instead. E.g. in your example the bus blocks on messages
from A to B, but not A to C. Of course this significantly lowers the
number of users/applications etc. needed to DoS the bus and thus maybe
some ridiculous low limits, dunno.

Ideally it should also be possible to specify limits per service. E.g.
so even though app A is blocked for some reason, it will always receive
e.g. a signal if it comes from a service that specifies "ignore all
limits" (such as from the kernel that says it's overheating; e.g. a
policy piece needs to take action immediately). Even, if assuming limits
per connection-pair and your example, when that service is owned by app
B.

But now I'm probably rambling. Oh well :-)

Cheers,
David