[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: New class of receive error
Sent from my iPhone.
> On May 13, 2018, at 5:16 AM, Michael van Elst <mlelstv%serpens.de@localhost> wrote:
> I don't think that's the right approach. In particular, it shouldn't
> be pushed to netbsd-8 close to the release.
I agree, this is unfortunate behavior that results in binary and source incompatibility.
> If you want reliable transport of messages, then you should use
> a reliable transport protocol.
I think the intent isn’t reliable, but rather to simply know when best effort wasn’t good enough.
> If you want complete routing information use synchronous queries
> and use routing socket messages only as an optimization.
Isn’t that what dhcpcd is doing?
> 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
I think a perfectly reasonable solution to our current dilemma is to have the ENOBUFS behavior changed to opt-in with a socket option.
Main Index |
Thread Index |