On Wed, Jan 17, 2001 at 06:00:42PM +0100, James R. Leu wrote:
> Hello,
>
> Comments at the bottom:
>
> On Wed, Jan 17, 2001 at 05:13:10PM +0100, Andi Kleen wrote:
> > On Wed, Jan 17, 2001 at 02:51:19PM +0100, James R. Leu wrote:
> > > Hello,
> > >
> > > On Wed, Jan 17, 2001 at 12:15:32PM +0100, Andi Kleen wrote:
> > > > On Wed, Jan 17, 2001 at 04:08:14AM +0100, Werner Almesberger wrote:
> > > > > James R. Leu wrote:
> > > > > > I'm not asking for the impossible. Sequence numbers and/or client
> > > > > > to server ACKs would solve the problem.
> > > > >
> > > > > So what do you do when the client doesn't ACK and you run out of
> > > > > buffer
> > > > > space ? Block all activities that may trigger netlink messages ?
> > > > >
> > > > > Obviously, in this case (interface up/down transitions), netlink
> > > > > doesn't
> > > > > scale well. A state-based interface would be better, e.g. netlink
> > > > > could
> > > > > generate a bit vector indicating the states (or the transitions, if it
> > > > > matters whether any have occurred), and update the vector until it has
> > > > > been read by the client. The question is of course whether we really
> > > > > need an optimized, scalable solution for this.
> > > >
> > > > A simple way is to delete ip addresses when you down an interface and
> > > > use
> > > > regular SIOCGIFCONF.
> > >
> > > That is basically a dump of the entire inteface table! If we are talking
> > > about 16K interfaces that is an awful lot of work just because an
> > > interface
> > > when down or up.
> >
> >
> > The thread was: when only a few interfaces go up/down then netlink messages
> > work fine.
> > Then someone complained that the netlink buffer overflows when too many
> > interfaces
> > go up/down. In this case you can do a whole resynchronization regularly
> > (e.g. every
> > minute) and do less work overall.
>
> Sorry for taking the previous comment out of context.
>
> As far as your last comment "resynchronization regularly": I disagree
> with it as well. :-)
>
> The reason a notification system like netlink is created is to prevent the
> clients from polling the kernel and doing aggregious dumps of information.
>
> Simply pushing it off to the clients by making them poll for this information
> is a hack. A client should only have to dump the inteface or routing table
> when it first connects, from then on it's view of the interface and routing
> table should be keep consistent via incremental and timly updates. Period.
>
> If netlink can not provide incremental, reliable and timly updates about the
> status of interfaces and routes then we should change it so it can.
I don't think polling is a hack. It's just that a single strategy for
synchronizing information is not the best in all cases. When you have lots
of data and only minor bits change then it is best to only transmit the
differences. When most of the data changes it is better to just dump the
whole data regularly.
Netlink supports both strategies, in addition you can use SIOCGIFCONF which
is a bit cheaper for the dump case because it doesn't queue.
Netlink even tells you when you should switch strategies.
What you should implement in your application depends on what you need to
handle, usually you will implement both strategies because netlink requires
you to support resynchronizion anyways because it's not reliable.
SIOCGIFCONF is just another optional optimization for the dump case.
None of this is a hack.
-Andi
|