> He should still be able to do reliable communication by doing the
> state maintanance within the user space app.
> The mechanism is already in place.
> [nlmsghdr.nlmsg_seq. as well as flags NLM_F_ACK, NLM_F_ECHO ]
Well, having flow control alone doesn't help. You still have the
problem of what to do when you generate more events that the
receiver(s) are handling. In TCP, you simply block the sender,
or return EAGAIN, pushing the responsibility one level up.
I don't like the idea of ifconfig hanging because some netlink
monitoring demon just decided to take a break. Neither do I like
the idea of ifconfig coming back with an error in this case. So
in this sense, netlink is certainly doing the right thing.
The question here is of course if the entire communication model
is appropriate. An alternative approach could be to just record
that a notification is needed, wake the reader(s), and generate
the actual message in response to the recvmsg call. This way,
one could still pretend to user space that we have a simple
message-based notification system, while underneath, we happily
Note that this wouldn't work well in all cases. E.g. if you have
lots of routes coming and going (and not coming back), you can't
compress notifications. Of course, netlink may be the least of
your worries in such a situation ...
/ Werner Almesberger, ICA, EPFL, CH Werner.Almesberger@xxxxxxx /