X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=4.5 required=5.0 tests=AWL,BAYES_50,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Message-ID: Reply-To: "Uwe Appelt" From: "Uwe Appelt" To: Subject: WinSock: Connections/min & MaxUserPort=5000 Date: Sun, 8 Feb 2009 14:38:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com 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/