On Mon, 29 Nov 2004, Thomas Spatzier wrote:
Yes, for the examples you mentioned the app should better be
notified. However, AFAICS, there are no such notification
mechanisms on a per-packet basis implemented in the kernel. And I
doubt that they are going to be implemented.
We do get notified. We get a netlink interface update with
unset IFF_RUNNING from the interface flags.
However, it can take time before zebra gets to read it, and further
time before zebra sends its own interface update to protocol daemons,
and further time before they might get to read and update their own
interface state. By which time those daemons may have sent packets
down those interfaces (which packets may become invalid before link
becomes back, but which still will be sent and hence which
potentially could disrupt routing).
Ideally, we should be notified synchronously (EBUFS?) or if thats not
possible, packet should be dropped (see my below presumption though).
The other solution is some means for a daemon to be able flush queues
for a specific interface. (but thats a bit ugly).
Good suggestion, if anyone has an interesting and feasible solution
I will be happy to integrate it. So far, however, it don't see one
and I would point people being worried about lost packets to TCP.
Surely TCP already was able to take care of retransmits? I'm not
familiar with Linux internals, but how did TCP cope with the previous
driver behaviour? (I get the vague impression that we're talking
about a driver specific buffer here, rather than the applications
socket buffer - is that correct?).
Jeff, David, enlighten us please! :)
Paul Jakma paul@xxxxxxxx paul@xxxxxxxxx Key ID: 64A2FF6A
I can't understand why people are frightened of new ideas. I'm frightened
of the old ones.
-- John Cage