So, in PSARC this morning I asked for more time to consider this case because at that time I hadn't arrived at a place where I thought I was comfortable with what was being proposed and I wanted some time to think it through before letting it go.
So if I can ramble on for a bit.... ip_broadcast_ttl exists because of a binary compatibility requirement with SunOS4 in the early days of SunOS5. Even then this wasn't absolutely required, /etc/system could have been used instead (it's not clear that there are any architectural benefits of /etc/system vs ndd as both receive a fair share of criticism.) But alas the change was made and so here we are today... The use of ip_broadcast_ttl seems to be extremely rare (google provided me with no hits to searches for "ndd -set /dev/ip ip_broadcast_ttl") and only in situations where customers want to send out broadcast packets with a higher TTL - there is no way for their application to do so. Whereas on other platforms, a combination of IP_TTL and IP_MULTICAST_TTL seems to allow this to be achieved, we haven't blurred the meaning of IP_MULTICAST_TTL (it applies to multicast and multicast only packets) and neither do we support using IP_TTL to modify the ttl of broadcast packets. So adding in IP_BROADCAST_TTL to provide the means for setting the TTL in broadcast packets for IP fills in a gap we have, while at the same time aligning itself with a (familiar) name from ndd. While we're not aligned with others (and there does appear to be some variance out there), its not too radical. So really nothing to worry about. So there's just one issue remaining... 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. Darren
