David McDaniel (damcdani) writes:
> WRT "null?"... I meant defaulted, as in zero. But I hadnt considered
> the case of explicitly set to zero.
There are two options there, neither one of which I particularly like.
If you use zero as the "wildcard" value, then applications just cannot
set zero and mean it. The outbound TOS will always be a copy of the
inbound TOS in that case.
If you distinguish between "never set" and "set by application," then
I think you get into a much more murky area. What can applications
that inherit sockets (such as from inetd) expect? Can a socket ever
go back to "default mode?" Can an application tell the difference
between "forced zero" and "default zero" when doing getsockopt?
Of those two, the former ("zero means copy") seems slightly less
problematic. If it's done intentionally as a hack (a special fix for
one particular usage; assuming strongly that nobody else would ever
want a feature like this), then I might go along with that plus a
system wide "enable hack" flag.
As an intentional new feature, though, I don't think either makes it.
> From the developer perspective I actually prefer #2 also, because it
> lets me do precisely what I want done on a per-socket basis. My
> complaint about introducing a seldom used option is from the certain
> knowledge that over the years these bits add up and you can never (or
> hardly ever at least) get rid of them.
Yep. But in the face of changing the default behavior of the system
(as the alternative position), I'd be extremely careful.
If there were some sort of standard to point to, or at least some
reference expectation ("every BSD system and Linux 2.6," for example),
then it'd be relatively easy to get consensus that changing the
default is the right thing to do, even if it means that the result
isn't strictly compatible. Being compatible with current practice is
sometimes more important than being compatible with old code.
Without that, I think having the application signal intent is best.
Even for "unfixable" applications, it'd be possible to code up an
LD_PRELOAD hack to force the flag on where needed as a work-around.
If we ever get proper DSCP mapping features, that flag ought to fit
right in. It just works as (flag?inbound:socket) in the mapping
input.
--
James Carlson, Solaris Networking <[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
networking-discuss mailing list
[email protected]
