On 27/04/2018 07:05, Robert Elz wrote:
Date: Fri, 27 Apr 2018 05:18:16 +0100
From: Roy Marples <[email protected]>
Message-ID: <[email protected]>
| No-one has yet weighed in on how this should be resolved.
Go back to silently discarding the error (at least, by default).
Datagram type services (which is what the routing socket,
and others like it, are) generally are just "best effort" with
no error reporting at all. The higher level protocol needs to
cope.
However, some kind of sockioctl() to enable error reporting
would be OK, for applications that actually need to know
(but they still need to cope with data lost for other reasons.)
What might be interesting to discover however, is just why
there are so many routing socket errors with the buffer space
exhausted - particularly on a huge system like Paul's. I would
have expected this to be rare assuming everything else is
working correctly.
My understanding (and I've not looked, so could be wrong) is that the
routing socket gets a 2k buffer by default regardless of how big your
memory is.
Since NetBSD-5, I've modified the kernel to announce IPv6 address state
changes, introduced IPv4 address state changes which are also announced
AND added a layer of compat to the more generic RTM messages so that
interface address changes can report back PID and flags. In other words,
while a 2k buffer might have been fine for NetBSD-4 (and we'll never
really know because overflow errors were silently dropped) it might not
be fine for a router with many addresses that all become active with the
internet decides to work. This is an important part because of all the
NetBSD machines I have, the routing socket only overflows on my ERLITE
router. The other physical servers, laptops and VMs I have do not.
Roy
