Guenther Grau writes:
> I must admit that I don't like solution. What if two people
> on the same machine want to listen to the same mbone video
> broadcasting? Only the first will succeed? Maybe at least in case
> of multi-cast sockets this restriction should not be imposed.

If you look closely at the patch you'll see that they're not affected.

> IMHO, for a clean solution, we need yet another attribute to
> indicate if the above restriction should apply. How about
> SO_REUSE{ADDR,PORT}_INSECURE? Programs which want to allow
> the insecure behaviour can do so, and the existing daemons
> will work fine. I'd prefer SO_REUSE{ADDR,PORT}_SECURE, because
> this would preserve existing behaviour for other applications.
> That way we'd have to change the daemons, but hey, they are
> our code, and 3rd party sw is not.

The SO_NOREUSE concept I first toyed with was similar to this.
However, that required changing *every* daemon, both in-tree and
third-party.  The type of program that gets affected by this (e.g,
web servers) often run on ports > 1024; do you want to have a
NetBSD specific hack in the source to every freely available web
server?

FreeBSD (which has a larger installed base than us) and OpenBSD both
have this funcionality; so I'm sure this issue would have come up
for them if it really was going to affect people.