Re: New class of receive error

[christos%astron.com@localhost (Christos Zoulas)]

In article <15289.1526216143%jinx.noi.kre.to@localhost>,
Robert Elz  <kre%munnari.OZ.AU@localhost> wrote:
>    Date:        Sun, 13 May 2018 07:24:37 -0400
>    From:        Jason Thorpe <thorpej%me.com@localhost>
>    Message-ID:  <AB39E25C-2DDA-40FE-A4A8-4A5EDEBEDBC8%me.com@localhost>
>
>  | I think a perfectly reasonable solution to our current dilemma is to
>have the
>  | ENOBUFS behavior changed to opt-in with a socket option.
>
>I agree.
>
>If I had to guess, my assumption would be that Roy is resisting this, as it 
>would add (another?) NetBSD specific piece of code in dhcpcd where
>he would (might) prefer to reduce the number of special cases.
>
>With that in mind, I would not be too upset if a new option as suggested
>was added, which defaulted to off on UDP and unix domain sockets, but
>defaulted to on for the routing socket (and if we ever get it, its clone, the
>mobile-ip socket).

That magical behavior is desirable from the DTRT perspective, but undesirable
from the consistency and explainability perspective. Doesn't the routing
socket know it has lost a message when the sequence number has a gap?

I am all for the opt-in behavior.

christos