MIME-Version: 1.0
In-Reply-To: <DB30737F060741FFACB69142C65FF035@uwe>
References: <DB30737F060741FFACB69142C65FF035 AT uwe>
Date: Sun, 8 Feb 2009 11:21:35 -0500
Message-ID: <dd5f2deb0902080821x643a9275wabb4cbf61ec6ecc9@mail.gmail.com>
Subject: Re: WinSock: Connections/min & MaxUserPort=5000
From: Lee <ler762 AT gmail DOT com>
To: Uwe Appelt <appelt AT rainbow-it DOT de>, cygwin AT cygwin DOT com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

You're right - it's not a cygwin problem; I think nmap has the same
problem & suggested fix.

here's what I changed the values to:
- TCP/IP parameter changes
     start / run / regedit
     HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
     - increase max ephemerial port number from 5000 to huge number
         create MaxUserPort as DWord value of 0xFFF0
     - lower timed wait delay so ports are reused faster
         create TcpTimedWaitDelay as dword value 32
         This parameter determines the time that a connection stays in
the TIME_WAIT state when it is closing.
         While a connection is in the TIME_WAIT state, the socket pair
cannot be re-used. According to RFC,
         the value should be two times the maximum segment lifetime on
the network. See RFC793 for more details.

Regards,
Lee


On 2/8/09, Uwe Appelt <appelt AT rainbow-it DOT de> wrote:
> Dear Cygwin-guys,
>
> i'm trying to run a bioinformatic tools suite from UCSC
> (http://genome.ucsc.edu/) under cygwin and unfortunately there seems to be a
> incompatibilty with regard to the standard TcpStack-settings in *ix and
> windows. I hope, this is the right place to discuss this.
>
> This is my environment:
> 1) Windows Server 2003 R2 x64 Enterprise ServicePack2 (can also be
> reproduced Win2003 x86 and the WinXP pendants)
> 2) Cygwin 1.7 (can also be reproduced with current 1.5.25-15 release)
> 3) blatSuite - official sources:
> http://www.soe.ucsc.edu/~kent/src/blatSrc34.zip
>
> What the UCSC-blatsuite does:
> The parts i'm using consist of a server app (1), that binds to a
> preconfigured tcp-port to accept client (2) inquiries that are sent via
> socket connections. The client opens up a new connection per inquiry, sends
> the query details to the server, receives the server answer within the same
> connection and finally closes the connection. Due to the nature of the
> biological context, it is a common task, to use the client to make the
> server answer several thousand inquiries per minute. Openeing so many
> connections within such a short period of time seems to be a problem for
> windows, because after a certain amount of inquies the client aborts the job
> (collection of inquiries) and claims the server wouln'd be available.
> Browsing the sources reveals, that the client was not able to open a new
> connection in such a case.
>
> TCP-problem?
> In fact netstat on *ix shows, that there are dozens of connections, even if
> the client has already terminated. This is the same on windows with one
> exception - the maximum port number, the client uses for outgoing
> connections seems to be 5000. Googling this told me things about
> connections, held in TIME_WAIT status (a certain period of time, the OS
> keeps ports opened/blocked, after they've been closed by the application
> code). And it told me, that there is indeed a windows port number limit for
> temporary connections, namely 5000.
> I guess, the OS blocks ports of recently closed connections for a certain
> period of time to avoid that for example a TCP_ACK of a former connection
> disturbs the new connection. This clearly leads to a lack of
> available/usable ports, as soon as an application opens a certain amount of
> connections per second.
> It seems, i'm having different chances to solve this. Raising the
> MaxUserPort and lowering the TCPTimedWaitDelay settings in
> [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
> seems to solve my problem. I think doing so ensures, that the OS has always
> enough ports left, that can be used to open new client connections, while
> recently closed ports can be blocked in the TIME_WAIT status. However i
> feel, that this a weak workaround, since its efficiency only a question of
> cpu-performance. Assume an enironment, thats capable to answer a 100 times
> more queries (just because of faster cpus), the client app will again fail
> due to the higher new connections per second rate.
>
> Has anyone had the same problem (i think, it would be same with a heavily
> loaded webserver) and what is appropriate way to circumwent this?
>
> Regards
> Uwe Appelt
>
> ps: retrospectively, this post doesn't look like a cygwin question. On the
> other hand cygwin provides many tricky things, that *ix apps expect,
> especially in network fields.
>
>
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Problem reports:       http://cygwin.com/problems.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/
>
>

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/