WinSock: Connections/min & MaxUserPort=5000

WinSock: Connections/min & MaxUserPort=5000

[Uwe Appelt]

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/

Re: WinSock: Connections/min & MaxUserPort=5000

[Lee]

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@rainbow-it.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/