Re: New class of receive error

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sun, 13 May 2018 15:01:42 +0100
    From:        Roy Marples <roy%marples.name@localhost>
    Message-ID:  <12e84d93-9f83-359c-3fd4-17f359f289de%marples.name@localhost>

  | Other OS's document ENOBUFS on recv calls.

That other OS's (by which I assume you mean linux) are broken is no reason
that we should be too.

Datagram protoctols inherently lose packets - aside from in this one very 
special case, there's no way at the network level to inform the receiver of
a lost packet, as there's no way to know one was ever sent.   The application
level needs to recover using its own mechanism - which could be using sequence
numbers in the packets as Christos suggested - but here I do not think can
work, as the messages come from a variety of sources (including other 
processes) and there's no way to synchronise the (current) sequece numbers 
(rtm_seq).

But we could add a kernel geneerated seq number - set whenever a routing
packet is generated, and delivered to the receiver - that at least would be a
application layer recovery mechanism.

Aside from dhcpcd every instance of "handling" this error is to (at most)
log it and ignore it - it really is pointless.

The routing socket is something special - it arguably should not be using the
socket interface at all - as it is puerly a local host communication mechanism,
so the local host OS knows when a packet is sent, and when one is received,
and when one is lost, and so can (reliably) inform the receiver that a  packet
has been lost - but that one is a very special case (along with the mobile IP
socket, which is just the routing socket with a different name (and purpose)).

My overall opinion is that if this message is not made opt-in (whatever the
default is set to for routing sockets)  then the whole mechanism should simply
be deleted.

kre