This is the mail archive of the
mailing list for the Cygwin project.
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
- Date: Sun, 8 Feb 2009 11:21:35 -0500
- Subject: Re: WinSock: Connections/min & MaxUserPort=5000
- References: <DB30737F060741FFACB69142C65FF035@uwe>
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
- 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.
On 2/8/09, Uwe Appelt <email@example.com> 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:
> 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.
> 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
> 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?
> 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