Date: Sun, 8 Nov 1998 17:10:10 -0800 (PST) From: Marc Slemko <marcs@znep.com> To: Brian Somers <brian@Awfulhak.org> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: bind()/listen() race Message-ID: <Pine.BSF.4.05.9811081702180.8174-100000@alive.znep.com> In-Reply-To: <199811082334.XAA06518@woof.lan.awfulhak.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 8 Nov 1998, Brian Somers wrote:
> The code says something like:
>
> if (bind(blah) < 0) {
> /* we're happy to be the client */
> if (connect(blah) < 0) {
> socket is bound without a listen !
> }
> } else if (listen(blah) < 0) {
> oops !
> }
>
> The sockaddrs are local domain sockets used by ppp in multilink mode.
> Whoever gets to be the server will survive. The other ppp will
> become the client, pass a file descriptor to the server and hang
> around holding the session 'till the other ppp kills it.
>
> However, if the two ppps get unlucky, one bind()s and the second
> fails then tries to connect() and fails 'cos the server hasn't
> listen()ed yet. This is bad news.
>
> The only way I can see around it - given that I can't sleep() in ppp
> without screwing up with other timing issues - is to detect the error
> and do a 1 second timeout, and try again then. This is a nasty thing
> to have to do.... I'd prefer an atomic bind()/listen() facility....
No, an atomic bind/listen isn't the solution, you simply need some form of
synchronization between the processes.
For example, you could use a lockfile and require a write lock arouncd the
bind and listen.
Unfortunately, inter process synchronization is more of a pain than intra
process synchronization.
If you used a lock file on disk with the server pid, you could also avoid
mistakenly thinking that something else listening on the port is the
server.
You suggestion is possible as a workaround, and is probably the easiest
fix.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9811081702180.8174-100000>