On Mon, 2004-09-27 at 23:23, Herbert Xu wrote:
> But ifconfig doesn't use netlink. So I presume you're referring to
> some other application that's listening for interface/address/route
> events.
Thats right.
I think you should be able to run ip monitor to see the overrun.
> Firstly thanks this is exactly what I've been asking for -- a real
> world scenario :)
I can assure you theres many more like this;->
My remote app is not this btw.
> Now that we know where the events are coming from and what they are,
> we can decide on the solution. In this particular case, there is
> nothing you can do on the sending side. Stopping people from operating
> on networking objects just because some netlink listener can't keep up
> isn't going to work. So congestion control is out of the question.
fixing the NLM_GOODSIZE issue is a very good first step.
Adding congestion control would be harder but not out of question.
The hard part is not in the maintaing state part (as the case of dump)
its rather how you start getting slowed down (in a broadcast) by one
slow (or buggy) app thats also decided its gonna have very low socket
buffer sizes.
> That leaves two options AFAICS. The easy way out is to increase the
> receive buffer size. Of course after a while this is not going to
> work.
Indeed. It just postpones the overrun.
> The second option which is the one I prefer: If so many events are
> occuring and you can't keep up, it's time to give up :)
>
> So just bite the bullet and reread the system state by issuing dump
> operations.
We may as well choose to document it as being this mostly because of the
issue i described above. We shouldnt give up so easily though ;->
cheers,
jamal
|