Jim Moore writes: > On 09/23/08 13:13, James Carlson wrote: > > Better still, just lose that code. I see no obvious reason to be > > trying to skip over the loopback interface. > > > > > Okay, I'll look at the other attributes. We need to filter loopback > addresses because > we are going to supply them to the iSCSI initiator via an iSCSI inquiry > or iSNS registration.
Now's probably not the time to get too deep into design issues, but that explanation sounds fishy to me. You should have a suitable local address available by using getsockname on a socket connected to that peer. Supplying other unrelated addresses from your system is, I think, of questionable utility. Those addresses may well represent subnets that are unreachable by the peer or (worse) represent things on the other side of a NAT, where global uniqueness just isn't guaranteed -- leading to havoc. You have no way of knowing what addresses your peer wants or can use, and those addresses are every bit as toxic to your peer as are loopback addresses or other bogons. If iSNS really needs multiple addresses at the same time for a single system, it ought to use transports that support that (such as SCTP) and naming services that can allow the administrator to group the addresses as needed (e.g., multiple DNS A records) rather than just "guessing." Fishing around in the interface lists in order to do something other than a bunch of bind() calls may well indicate design or even protocol issues. (Yes, I've heard the "walled garden" explanations a thousand times -- how iSCSI is used only on special "storage networks" and so on. Very few usable systems have connections to disk alone and nothing else.) -- 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 _______________________________________________ networking-discuss mailing list [email protected]
