James Carlson wrote: > 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.
You are right, it's not 100% compatible, but close enough for most applications. It's necessary to qualify specific applications, and that's what we are doing. The target is to accellerate specific applications, not to provide a 100% compliant replacement for TCP/IP sockets. While talking about semantic compliance: Is there a publicly usable socket test suite? We are writing test cases as we need them, but surely don't cover "everything". > (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.) These features are typically not needed within, say, a database cluster. See above. > 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. So far, we could avoid it, but we're not yet through. >>> 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. I just wanted to say "Thanks for the information, but we will not have to use it right away, so expect me to come back with problems on this part within a few months." ;-) >>> 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. O.k., thanks for this advice. But what do you mean by "integrating into the consolidation"? How would this change the status of an interface being undocumented/volatile? Joachim -- Joachim Worringen, Software Architect, Dolphin Interconnect Solutions phone ++49/(0)228/324 08 17 - http://www.dolphinics.com _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
