On Sat, Jul 05, 2014 at 12:45:37PM -0400, Tim Hudson wrote:
> On 5/07/2014 9:12 AM, Kurt Roeckx wrote:
> > On Sat, Jul 05, 2014 at 08:13:04AM -0400, Eric Covener wrote:
> >> On Sat, Jul 5, 2014 at 7:37 AM, Kurt Roeckx <k...@roeckx.be> wrote:
> >>> Does anybody have an idea why it's trying to do that, and why we
> >>> shouldn't just do SO_REUSEADDR the first time? Was there some
> >>> OS that maybe did strange things when trying to use SO_REUSEADDR
> >>> and it was already in use?
> >> FWLIW: I've seen this pattern in some other proprietary software,
> >> where they try hard to not set SO_REUSEADDR unless it appears needed
> >> due to a bind failure. But whatever they were working around, it is
> >> detrimental to modern Linux where the outgoing TIME_WAIT socket has to
> >> also have been opened with SO_REUSEADDR for the reuse to be allowed.
> > man socket(7) documents that behavior on Linux. They also say that
> > you ussually don't notice it because most things always set
> > SO_REUSEADDR. So it seems to me like the behavior of that piece
> > of code will at least don't do what you want it to do on Linux so
> > other than being weird it looks like an other reason to just drop
> > it.
>
> If you have SO_REUSEADDR set and a listener already in place you will
> start a new listener
No you won't. You will get a bind() error:
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
bind(3, {sa_family=AF_INET, sin_port=htons(3344),
sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
Except on windows it seems.
Kurt
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
