Michael Hunter writes: > On Thu, 28 Jun 2007 12:06:25 -0400 > James Carlson <[EMAIL PROTECTED]> wrote: > > However, I wasn't necessarily suggesting pushing it into "the > > application." In this case, we're talking about inetd services, so I > > was talking about pushing it into inetd itself -- a single place where > > the problem can be dealt with, rather than the dozens or hundreds of > > clients that inetd may have. > > If it was just inetd that we needed to make more resiliant then I'm > with you. But of your 3 points the last one was to have name service > clients react to change without having to blow the world away and > restart it. That one seems to me like it would push burden onto many > of the clients.
I think they were in that situation before SMF. I'm just unconvinced that SMF, and its bias towards internal dependency representation, is the right way to handle this sort of problem. > > Otherwise, I don't understand what you're suggesting or how it fixes > > the underlying problem: trying to translate a "service name" into a > > port number may take a very long time and may not succeed at all, and > > yet we've got a single service that's dependent on doing this for > > dozens or hundreds of separate entries. That doesn't sound like the > > right design. > > For inetd I agree that the inability to translate one service number > shouldn't hang up other services that might already be up or that might > be specified numerically. But this bug is about inetd-update. Yep; understood. It's just part of a broader context. As Dave said, inetd-update could just import those services without bothering to check at all. > > Whether you get there with this fix or not is another matter. "Out of > > scope for now" doesn't seem like a wrong answer to me. > > Thats what I think is the right answer for inetd-upgrade (inetconv). I > think its a P2 bug against inetd if it ever hangs on name resolution. > Its probably a P2ish RFE to clean up the whole "name service can > traffic jam a bunch of valid services" issue. OK. inetd-upgrade causing the traffic jam today probably obscures other problems down the road. :-/ -- 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 networking-discuss@opensolaris.org
