> > *) Move the fd_* and watch_* fields from AvahiServer to AvahiInterface. > > *) Encourage use of avahi_interface_send_packet and replumb a few interfaces > > *) Change the socket setup code to use setsockopt(...,IP_MULTICAST_IF...). > > > > After that, Avahi shouldn't need to use IP_PKTINFO. > > What's the advantage of that? I would say IP_PKTINFO is the only > reasonable API for all this stuff. It's a pity the BSDs don't support > it. But I'd say it would be a step in the wrong direction to not make > any use of it.
After trying to make the patch for a little while, you may be right. The per-interface fds has a serious issue when it comes to the bind() call - I'd have to figure out what address to bind to, versus the current architecture of just binding to it all. If we could figure out this bit, though, there are some advantages: *) No need to do lookups to figure out which interface it came in on (just map from fd back to AvahiInterface). This argument is weak, since the lookup is minimal 99.9% of the time. *) Better portability for the sendmsg. However, after digging into it, and glancing at mDNSResponder for curiousity, I think I like your way better. Looks like mDNSResponder uses IP_MULTICAST_IF and per-interface fds, but doesn't solve the bind issue (uses INADDR_ANY). That seems like a poor idea. I'll keep digging on a better way for the BSDs. I submitted the simple patch on the bug, its only real flaw is performance (2 syscalls per send), and a lack of thread atomicity (two threads trying to send out the same fd may stomp on each other). I'm more worried about the latter, but it doesn't look like a big deal right now. ...Zach _______________________________________________ avahi mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/avahi
