SINGLESOCK - How much to strip away?

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> 
> esr at thyrsus.com said:
> > >Is there a clean way to get notified when an interface comes or goes?
> > Yes, that's what routing sockets gives you - notification when there's a
> > routing change.  (I don't understand the details well, but this seems to be
> > the big picture.) 
> 
> Are routing sockets available on all platforms?

I don't know.  I did a little digging and found out they were
introduced in 4.3 Reno; therefore all the open-source BSDs almost
certainly have them. They're certainly in Linux.  I also found a search
hit that they're in Solaris.  On the other hand, I found an Apple
Developer Forum post indicating they're missing or suppressed in OS X.

> There is a command line option:
>    -U Num uinterval      interval in secs between scans for new or dropped 
> interfaces
> I'm guessing there is also a polling option in the code and that's part of 
> what makes the code so ugly.  Or maybe wakeup on the routing socket doesn't 
> work, or isn't used.  ??

I'd have to look at the code to be cetrain, 

> If it's not used, we can fix that.

Creating a port-verification pain in the ass.  This is why I want to do
Case OMEGA and dump all this interface-aware crap overboard.  It's got
"DEFECT ATTRACTOR!!!" written all over it.

> > I agree. I'm not in favor of this combination.  But apparently Gary and
> > Jason want to keep some sort of explicit interface selection.  I don't know
> > why. 
> 
> There is an interesting quirk in this area.  The command line defaults to 
> none and you get to add the ones you want.  The config file defaults to all 
> and you get to drop the ones you don't want.  (If I understand things 
> correctly.)

I very much fear that you do. Did I mention that this stuff has
"defect attractor" written all over it?  Whenever you see that kind of
quirk you should think "bad smell, code or design under it may be
rotten".  (Ian, you paying attention?  This is an important heuristic.)

I've had my suspicious eye on -I and -L since long before we started
discussing SINGLESOCKET.  I won't say I had them Marked For Death, but
they definitely made it into "please someone give me a good enough
reason to remove these".

> FreeBSD missing IP_PKTINFO:
> > Search for IP_PKTINFO.  It's documented there.  I don't know where the
> > header is lurking, though; that is a bit odd. 
> 
> I found one discussion that said that FreeBSD didn't have it.  That was from 
> early 2017.
> 
> I have kernel sources from last July.  IP_PKTINFO is only in contrib, and a 
> lot of that is ifdefs.  So I'm pretty sure it doesn't exist.  Nothing in 
> include/
> 
> My guess is that the documentation got copied from someplace and they grabbed 
> too much.

Well, that sucks.  It's very not good that we can't trust their API docs.

Good thing Mark decided to drop interface-name filtering; this means
we can't save it portably if we do SINGLESOCK.

> How many other OSes are we interested in?  Anybody checked Mac?

I have.  It's not there.

> Back up a few steps.  Why do you think multiple sockets are so ugly?  To my 
> view, the ugly part is tracking interfaces and using a single socket doesn't 
> fix that.

Usual reasons.  I want simple code.  One place where we're doing UDP
reception is simpler than many places.  I think it will be
specifically helpful if we decide to move to a tickless, event-based
architecture.

I'm still running the long bet my technical leadership of this project is
premised on.  That is, simplifying as ruthlessly as possible smashes out
bugs we don't know about yet.  It's worked pretty well so far and I intend
to continue doing it.

> Should we run some timing tests?  Do we want to use recvmsg and sendmsg if 
> they are significantly slower?  What is significant? ...

The code already uses recvmsg on any platform where it can use CMSG to
get true packet arrival times from the network layer.  So there's no
additional overhead implied on the receive side.

I'm not worried about the transmit side.  I think I know how the
implementation works and there's no reason for the overhead to be
more than minimal.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.