Date: Mon, 7 Aug 95 13:18:26 MDT From: terry@cs.weber.edu (Terry Lambert) To: pete@puffin.pelican.com (Pete Carah) Cc: current@FREEBSD.org Subject: Re: workaround for talk's address problem Message-ID: <9508071918.AA26511@cs.weber.edu> In-Reply-To: <199508071909.MAA09580@puffin.pelican.com> from "Pete Carah" at Aug 7, 95 12:09:46 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> THIS *SHOULD* be possible to use (if possible) with no mods to the > client/server program source. This would eliminate the problem of > needing listens on all possible interfaces like xntpd now does. [ ... ] > Boy is that not general. We need to think about incoming connections > too (like the kadmind fix last week; will that work for xntpd too, > and is it possible to move the fix(es) to the library and/or kernel so > we don't need to go around modifying all possible clients *and* daemons? > As far as I know this is only a UDP problem. I can think of one simple and obvious fix, but it fails with SO_REUSEADDR and/or SO_REUSEPORT. On a reused port, are incoming packets treated as multicast (that is routed to each of the listeners)? It would seem that this would not be the case because of dynamic load balancing issues between several service engines on a single host. On the other hand, if it *is* the way things are done, then an incoming packet can be interface routed internally by considering the socket to which the packet is destined. This isn't a general solution for multihoming on anything by TCP and UDP, however, so there may still be problems with protocol and gateway and forwarding support. IPX would be particularly thorny, as it requires an internal net number to deal with multiple interfaces. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9508071918.AA26511>