New class of receive error

[mlelstv%serpens.de@localhost (Michael van Elst)]

Recently the recv() system call (and variants) were changed to
return the ENOBUFS error for datagram sockets to indicate that
the sender failed to send a packet.

Apparently this only works for local communication like UNIX domain
sockets or the routing socket, as you don't know about sender errors
of a remote system if e.g. UDP is used.

The intention was to make data sent to the routing socket more
reliable by informing the receiver that it lost information and
that it has to resynchronize. So far the only user that needs
that kind of information reliably is dhcpcd.

A side effect is that programs using UNIX domain datagram sockets
such as syslogd now fail when they can't keep up with messages
(but only for local messages).


I don't think that's the right approach. In particular, it shouldn't
be pushed to netbsd-8 close to the release.

If you want reliable transport of messages, then you should use
a reliable transport protocol.

If you want complete routing information use synchronous queries
and use routing socket messages only as an optimization.


The origin of this change seems to be the special case of Linux
NETLINK sockets. NETLINK sockets serve similar purposes as the
BSD routing socket for passing kernel information to userland
daemons. Reading from them may yield ENOBUFS errors to inform
userland that messages got lost.  This behaviour is also controlled
by the NETLINK_NO_ENOBUFS socket flag, so it can be turned off
again.

-- 
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."