James Carlson wrote:
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.
Hmm, so BSD fixed that ages ago and our inetd seems to recognise
a "bind_addr" (see /var/svc/manifest/network/inetd.xml) but I've never
seen it used :-o
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.
Hence the reference to "traps".
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.
Sure, but that's not what I was asking about.
What I was asking is if NTP could respond to a query received via
multicast. I thought that both broadcast and multicast were send only.
I'm well aware that it can have other sockets open to do unicast things.
Darren
_______________________________________________
networking-discuss mailing list
[email protected]
