Joachim Worringen writes: > James Carlson wrote: > > Even then, I think such things are of questionable design. It sure > > would be nice if new transport layers became first-class citizens > > rather than piggybacking off TCP/IP. > > This is a valid opinion; we already discussed this about one year ago > when the "pluggable socket module" project (now "volo") was about to > start. One (the?) major goal of this project is to allow alternate > transport layers be used via the standard sockets API.
One of the problems I have with that answer is that these replacement paths rarely (if ever) faithfully reproduce the semantics of standard TCP/IP, including IP options, TCP's half-open connections and urgent marker, and delivery of ICMP errors. Lacking the same semantics means that applications are left in an uncertain state. They may work, if they're lucky, and don't rely in any way on the unimplemented parts. They may also fail. And there's no simple way to know which applications are in which class. It's just happenstance. (And that's not even mentioning the higher-level problems, such as having a data path that completely ignores configured IP filters, IPsec policy, QoS, and TX labeling.) > The missing adaption of "better" APIs like uDAPL shows why this approach > is necessary, including IP addressing schemes. There are probably many ways to read that result. In any event, what you're doing sounds like a familiar path. I'd suggest getting in touch with the SDP folks and doing something similar. I suspect that getting it right enough to be usable very likely means relying on currently-undocumented interfaces. > > If you go with sockets, then a routing socket (PF_ROUTE) will tell you > > about interface events. > > Thanks, we'll see how we can use this. This is not our primary problem, > though. I don't think I understand that answer ... your question was about getting notification when an interface changes so that you can get the updated address / mask / flags on that interface. That's exactly what a routing socket will do. > > See neti and the existing IP Filter code ... but you'd likely want to > > be in bed with the IP implementation itself to accomplish this. Doing > > it as a separate driver sounds dicey to me, as we don't have stable > > interfaces for it. > > We are not eager to use undocumented interfaces... Understandably so. If you do end up using undocumented interfaces, and you're not willing to integrate into the consolidation where those interfaces are managed (ON), then I'd recommend finding out who has responsibility for those interfaces, and getting an ARC contract on them. An ARC contract isn't a financial or legal instrument; it's a technical tool that allows you to specify which undocumented interfaces you need to have unchanged for your code to continue working, and outline a plan for communicating and coordinating changes that are required. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
