[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Bug: svnserve fail to detect it is already running

From: Peter Samuelson <peter_at_p12n.org>
Date: Fri, 9 Jul 2010 09:36:05 -0500

[Stefan Sperling]
> This doesn't make any sense.
> I don't understand how an OS can allow a user process to break
> a system service simply by binding a socket to the same port.

And yet ... http://msdn.microsoft.com/en-us/library/ms740621%28VS.85%29.aspx

    Once the second socket has successfully bound, the behavior for all
    sockets bound to that port is indeterminate. For example, if all of
    the sockets on the same port provide TCP service, any incoming TCP
    connection requests over the port cannot be guaranteed to be
    handled by the correct socket — the behavior is non-deterministic.

From that article, it appears SO_REUSEADDR means something rather
different in Windows than in Unix.

    Likewise, an "active" TCP port is a port that is currently in one
    of the following states: ESTABLISHED, FIN_WAIT, FIN_WAIT_2, or
    LAST_ACK. Ports without SO_EXCLUSIVEADDRUSE set may be reused as
    soon as the socket on which bind was previously called is closed.

So here's how I interpret the situation:

    Windows Unix Meaning
    -------------------------------------------------------------------
    default SO_REUSEADDR Can reuse a socket immediately
                                       after you close it, without
                                       waiting for the other end of the
                                       connection to close (or time out)

    SO_EXCLUSIVEADDR default Cannot reuse a socket until both
                                       ends of all connections have
                                       closed them (or timed out)

    SO_REUSEADDR not possible Unsafe!

Of course what we want is the first case.

-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
Received on 2010-07-09 16:37:40 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.