Date: Sat, 18 Feb 2006 21:45:57 +0100 (CET) From: "Arne H. Juul" <arnej@pvv.ntnu.no> To: Nate Williams <nate@yogotech.com> Cc: freebsd-java@freebsd.org, Kurt Miller <kurt@intricatesoftware.com> Subject: Re: SO_REUSEADDR should not also mean SO_REUSEPORT Message-ID: <Pine.LNX.4.62.0602182107440.31913@decibel.pvv.ntnu.no> In-Reply-To: <17399.20883.741021.688682@caddis.yogotech.com> References: <43F4F22F.1060402@europe.yahoo-inc.com> <200602171054.11632.lists@intricatesoftware.com> <Pine.LNX.4.62.0602172357530.8209@decibel.pvv.ntnu.no> <43F72599.4030009@intricatesoftware.com> <17399.20883.741021.688682@caddis.yogotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 18 Feb 2006, Nate Williams wrote: >> Ok, thanks. I got that impression from reading some posts I found >> while googling. There was one in particular for NetBSD that >> discussed it in detail. Check out the Apr 2 portion of this >> http://www.tinyurl.com/b46gq by Jan Schaumann. Also this >> one http://tinyurl.com/9sa6a. From these posts it appears >> that SO_REUSEPORT is needed in some cases to be compatible >> with linux. > >> From the early days.... > > - In the Multicast constructor, the low level routine sets the > SO_REUSEADDR option by using JSO_REUSEADDR which corresponds to a call > to setsockopt(..SO_REUSEADDR). To make multicast sockets work in *all* > cases on FreeBSD, we should also set SO_REUSEPORT, else in many cases > the multicast bind will fail. I won't claim to know what's the best behaviour with multicast, but the problem is that SO_REUSEPORT is always used when SO_REUSEADDR was requested, meaning that: > SO_REUSEPORT allows completely duplicate bindings by multiple > processes if they all set SO_REUSEPORT before binding the port. so you can have two very different java servers listening on the same port, for example. Or the same java server started twice won't notice any problem because the second instance will bind its server port fine, while on all other OSes this would give a sensible error message. And so on. This is bad. The reason I found this problem in the first place was from a Java program that worked well on Linux, not at all on FreeBSD, and after much tracing we deduced that something was enabling SO_REUSEPORT on FreeBSD, after which finding the bad code was a simple matter of "grep", only leaving the question of why it was there in the first place. If anybody figures out what's best practice for supporting multicast applications, ask the BSD kernel people to change the kernel behaviour to match best practice, make it possible to control SO_REUSEPORT from the MulticastSocket class, or find some other solution that doesn't make *other* types of java application suffer. - Arne H. J.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.62.0602182107440.31913>