Home » U++ Library support » U++ MT-multithreading and servers » Socket: SYN_SENT stalled when ipscan connections in CoWork (MT)
Re: Socket: SYN_SENT stalled when ipscan connections in CoWork (MT) [message #28324 is a reply to message #28322] |
Fri, 27 August 2010 18:00   |
 |
kohait00
Messages: 939 Registered: July 2009 Location: Germany
|
Experienced Contributor |
|
|
by the way, this problem is occuring when runnning on windows.
i know of the outgoing connection limitation of windows (10 connections)..but what surprises me the most is that those SYN_SENT remain even though i closesocket normally after time out and Linger(0) is set. so a hard socket close should occure.
i even did a handbreak to only have run a max of 4 concurrent connect attempts by wating for completion of all threads. (if(++q%4 = 0) wq.Finish())
i did some searching but cant find the heart of the problem, there is a lot of crap out there, but nothing that directly adresses this one..
http://docs.softinventive.com/En/Total_Network_Inventory/FAQ
Quote: |
Q: Where do I install the program on - a server or a workstation?
A: Either server or workstation can run Total Network Inventory. It is just a matter of usage convenience, because it's not a client-server application and you need to have access to the graphical console of the computer you install it on, either directly or using some remote desktop utility. Besides, if you run it under domain admin account, you will be able to scan all computers "as current user", otherwise you would need to specify domain admin credentials explicitly.
However take note that if you install the program on Windows XP (starting with SP2), Windows Vista or Windows 7, and if there are many scan threads launched simultaneously, there may be issues with connections to remote computers. This is due to a restriction on the maximum number of TCP half-open connections (connection attempts, SYN_SENT socket state) existing in the mentioned Windows versions, which doesn't allow more than 10 outbound connections to be in this state at a time. After reaching this limit, all other connections in the system (including those executed by this program) are queued and may reach their timeout, thus producing inconsistent results. This issue is also known as "Event 4226 issue", because reaching the limitation produces a record in the System Event Log with EventID 4226. Windows XP SP0/SP1, Windows 2000 Professional and all Windows Server systems don't have such limitation. So in general case we suggest installing the program on a server operating system.
|
http://www.microsoft.com/products/ee/transform.aspx?ProdName =Windows%20Operating%20System&ProdVer=5.1.2600.2180& EvtID=4226&EvtSrc=Tcpip&LCID
Quote: |
Explanation
The TCP/IP stack in Windows XP with Service Pack 2 (SP2) installed limits the number of concurrent, incomplete outbound TCP connection attempts. When the limit is reached, subsequent connection attempts are put in a queue and resolved at a fixed rate so that there are only a limited number of connections in the incomplete state. During normal operation, when programs are connecting to available hosts at valid IP addresses, no limit is imposed on the number of connections in the incomplete state. When the number of incomplete connections exceeds the limit, for example, as a result of programs connecting to IP addresses that are not valid, connection-rate limitations are invoked, and this event is logged.
Establishing connection–rate limitations helps to limit the speed at which malicious programs, such as viruses and worms, spread to uninfected computers. Malicious programs often attempt to reach uninfected computers by opening simultaneous connections to random IP addresses. Most of these random addresses result in failed connections, so a burst of such activity on a computer is a signal that it may have been infected by a malicious program.
Connection-rate limitations may cause certain security tools, such as port scanners, to run more slowly.
|
but why the hell is an actively closed connection considered half-opened? or does the system impose another timeout in this, which has nothing to do with the select timeout??
[Updated on: Fri, 27 August 2010 18:10] Report message to a moderator
|
|
|
Goto Forum:
Current Time: Fri Jul 18 03:26:01 CEST 2025
Total time taken to generate the page: 0.04579 seconds
|