Darren Reed writes: > What I'm questioning is the architecture of the application (or use of > the application) if it finds itself in a position where it needs hundreds > of open file descriptors to manage all of the addresses.
Nobody likes it, but it's quite common -- at least prior to IP_PKTINFO. > I suppose one solution is what Dan's proposing, but I'm not > alltogether sure I like that because it encourages the use of > INADDR_ANY as something to bind to for servicing a port. I don't follow. Why is INADDR_ANY a bad thing? It allows the server to listen on all interfaces. It allows the server to deal with interfaces that may come and go over time or that might be renumbered. Heck, it's the default and indeed _only_ way to run something from inetd. > There are security traps present when one chooses to bind to > only INADDR_ANY, potentially allowing someone else to come > along and bind to a specific address, stealing your packets. That's a different (and known) issue, and isn't really resolved by binding to a specific address. In fact, you're making it worse by doing so: while you're bound to a specific address, someone else can bind to INADDR_ANY or to one of the other specific addresses and snatch up all the packets sent to any of the server's *other* addresses. See setsockopt(3SOCKET) and the SO_EXCLBIND option for a fix to the problem you're talking about. > > Not true for both. Both allow unicast query-response operations in > > addition to the multicast operation. > > > > Are you saying that NTP and RIP also do query-response for multicast > traffic? > I didn't know (and haven't seen) that... :-o Both can do unicast queries and responses when operating with a multicast server. It's common for a multicast server to have sockets open for every interface -- or to rely on something like IP_PKTINFO set the addresses as needed. (When an NTP client is in multicast mode, it doesn't send unicast packets, but that doesn't mean that there can't be unicast clients as well and that the server can't respond to them.) In any event, I give up. I don't think this fork of the discussion has been useful. I do think, though, that you're on some sort of mission here, and I don't understand what you're after. The RFCs (particularly 1122) are at least to me quite clear in how this is supposed to operate, but I guess you're free to do as you want. -- 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]
