Re: shutdown(2)'ing a bound UDP socket

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> The shutdown'ed descriptor is global I think.

No; shutdown() affects the socket, not the descriptor and not the
address/port pair.  You are a very unusual case, having multiple
unconnected sockets on the same address/port pair.

> Usually this is done to give forked childs an opportunity to receive
> a packet after some algorithm (I'm guessing it's a round-robin alg or
> similar).  By shutdowning one of these I hope to tell the kernel that
> I want this excluded from this algorithm.  And let the other global
> "tuple" receive that packet.

Why not use a single socket with descriptors open in multiple
processes?  I don't know full details of how you're starting up, so
this might be difficult, but it seems to me that you want one read
descriptor and multiple write descriptors for a given address/port.  To
me, this sounds perfect for a single socket with multiple fds on it:
just treat most of them as read-only.  (Ideally, you should be able to
turn off write access at the descriptors without shutting it off for
the socket, but the obvious way to do that (fcntl F_SETFL turning off
FWRITE) probably won't work - it won't as of 5.2, and I'd be surprised
if anyone had made it work since then.)

To create it, the simplest way is to create the socket before you fork.
That may or may not be feasible in your case.

> [...why...]  It had to do with OpenBSD and their sandbox'ing
> mechanism called pledge(2).

I know nothing of pledge(2) beyond what I can infer from your mail,
but, if it breaks the "single socket with multiple descriptors"
approach, maybe you could do that only when pledge is unavailable?

> I write all my programs single-threaded and only fork alternatively
> mainly due to not understanding threads all that much.

Yeah, UNIX-and-C is a bad system for writing threaded code.  Things
like pthreads kinda-sorta make it work anyway, but it's never been a
good fit.

I'm not sure what the best fix is.

> It comes down to "what to do with shutdown(2)" and it's as much
> political as technical decision.  I think the way OpenBSD allows this
> makes sense, [...]

Given that it supports SO_REUSEPORT at all, I suppose that behaviour
makes as much sense as any other.  I'm not sure what I think of
SO_REUSEPORT.  It breaks the naming paradigm sockets were built around;
I think either it should be eliminated or the whole naming scheme (and
probably parts of the API) should be torn down and rebuilt in a way
that makes sense in the presence of multiple sockets on a given
address/port.  (With luck, that'd even permit getting rid of sin_zero!)

If we had a properly designed API, it would just be a question of
checking whether some OSes are out of spec or whether the is code
depending on behaviour not promised by the API.  But the socket API
wasn't really designed; it was more like `accreted', and it shows.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B