Paul Jakma writes:
> Good to see this, but still: *Groan*. Are there good reasons to be
> incompatible with Linux and, worse, /contrary/ to the established usage?
> This just makes things very tedious for users and leads to much auto*
> and ifdef ickyness (needlessly?).
And what about the places where Linux simply gets it wrong?
At one point, we[1] were attempting to follow Linux in this area for
_exactly_ the reasons you suggest. There seems to be so much broken
on Linux, though, that to follow it unquestioningly would be foolish.
We must also look at what makes sense for Solaris.
For example, setting the destination address on output, as Linux
appears to do, is just senseless and wrong. Not only is that
functionality already covered by plain old sendto(), but it completely
breaks symmetry.
The symmetry argument is this: recvfrom() gives you the inbound packet
source, and sendto() sets the outbound packet destination. This new
feature gives you the inbound packet destination, and it thus must set
the outbound packet *source*. The intentional model is that most
applications can just take the bits from the receive side and copy
them over to the send side without having to look at them. As far as
the application is concerned, the bits are just a token representing
the peer.
Why would you ever want to set the output packet destination address
to be the same as the original input packet destination address?
I agree that we ought to be as compatible with others as we possibly
can, but if all of our friends jump off a bridge, I don't think we're
compelled to jump as well.
A better answer might be to help the Linux folks fix flaws here ...
> a) Call this something else (to avoid Linux IP_PKTINFO clash)
I disagree. It has symmetry with the existing IPV6_PKTINFO.
> b) Remove the ifindex member from the struct to avoid clashing with
> routing (raw + IP_HDRINCL remains an option for those wanting
> such absolute control over outbound interface selection).
Raw + IP_HDRINCL doesn't appear to set ifindex ...
> Alternatively document that ifindex is ignored for the option (if you
> want to reuse the struct across both options) - might be mildly
> confusing though.
I mildly agree with this, but for a different reason. IP_RECVIF and
IP_XMIT_IF provide decent control here. I don't know why Linux chose
to mix in the interface here as well.
[1] This is Rao's RFE, but he and I have been discussing it off-line
for quite some time.
--
James Carlson, KISS Network <[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]
