> I would like to have seen being able to issue an > IP_BROADCAST_TTL require that SO_BROADCAST had been > issued first. While there is established behaviour > in our deployed code base that requires SO_BROADCAST > to be ignored for sending broadcast packets, this > case introduces a new socket option so it seems > within reason to require IP_BROADCAST_TTL to need > SO_BROADCAST to be set. I don't see that this would > change the architecture of SO_BROADCAST, just refine > that for IP_BROADCAST_TTL. A little bit of a stick > to get people to use SO_BROADCAST as they should. > > ...so having thought it through, I'm happy with the > case as it is, I'd just be happier if it recognised > SO_BROADCAST as being significant.
I don't think that request makes sense. Even if we enforced SO_BROADCAST, it would be (as per the documentation) to restrict the transmission of broadcast messages. That does not mean that it should restrict the configuration of the content of those broadcast messages. That is, the choke point should occur when actually sending the message, not when configuring the characteristics of those messages. Phrased differently, requiring one to call SO_BROADCAST prior to calling IP_BROADCAST_TTL is one more unnecessary rule for the application developer to remember, and one more unnecessary rule for the kernel to enforce. Further, it is especially strange given that SO_BROADCAST has (intentionally) done nothing since Solaris 2.0. However, if one day we decide to enforce SO_BROADCAST, it should be done uniformly by restricting the transmission of broadcast packets, which is both simple and in-line with existing documentation. -- meem
