This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
Re: subtle problem with bind() semantics breaks bindresvport()
- From: Corinna Vinschen <vinschen at redhat dot com>
- To: Cygwin Developers <cygwin-developers at cygwin dot com>
- Date: Thu, 25 Sep 2003 00:12:25 +0200
- Subject: Re: subtle problem with bind() semantics breaks bindresvport()
- References: <3F71F9D9.6090304@hekimian.com>
- Reply-to: cygwin-developers at cygwin dot com
On Wed, Sep 24, 2003 at 04:08:57PM -0400, Joe Buehler wrote:
> FYI, there appears to be a subtle difference in the semantics of winsock
> bind() that makes Cygwin behave differently than UNIX.
>
> I am seeing the problem in bindresvport() in librpc.a but it looks
> like this may have been seen before in ftpd if I read the mailing list
> archives correctly.
>
> On a UNIX machine, bind() will return EADDRINUSE if an attempt is made
> to bind to a port that is already bound. Winsock is subtly different.
> If you use INADDR_ANY for the socket address in the bind(), you can
> succeed with bind() but later on fail with connect() -- Windows is
> delaying the test until it can determine whether the (proto, port,
> address) triple is unique.
>
> This breaks the usual UNIX implementation of bindresvport() that just
> scans through successive ports trying bind() until one succeeds. So
> I am seeing failing rpc calls because bindresvport() is picking a
> port number that Windows later refuses to use in connect().
This is a known problem. Winsock's `rresvport' function returns a socket
descriptor to a reserved port which still is timing out.
See the rshd.c source in the inetutils package which contains a hack to
workaround this.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Developer mailto:cygwin@cygwin.com
Red Hat, Inc.