frankv060597
asked on
Windows Programming question
Overview:
I am developing a multi-threaded app for NT using MFC and VC++ 5.0 that creates multiple simultaneous CSocket connections (both UDP and TCP) in their own "worker" threads. After 60+ TCP connection failures my app, and my machine, "freeze". If only a few connection errors occur, the app runs fine.
My present theory is that the failed connections leave sockets in open or indeterminate states even after I explicity call CSocket::Close. Is this a known problem? Is there a way to force CSocket or the OS to free these resources?
Details:
The app is spawning mutilple simultaneous threads to deliver email via SMTP. Each thread creates one UDP socket to do a MX record lookup from a DNS server and then a second TCP thread to connect to the SMTP server. The UDP socket is closed and its CSocket object destroyed before the TCP socket is created. A connection failure results in an exception being thrown which ultimately calls CSocket::Close. After a connection failure the same CSocket object may then be re-used to attempt a connection to a different server. In general however the CSocket objects are not re-used unless an error occurs as each thread creates its own CSocket objects each time it's spawned.
The connection failures happen at random throughout the sending process, however the number of connection failures before the app freezes remains relatively constant. I have set a max limit of 30 simultaneous threads, and the app tends to average about 15-20 threads actually running at any given time. These threads are running with a priority of "above normal." Memory and CPU usage do not seem to be a factor as the app runs fine if no connection errors occur.
I have created my own socket class that inherits from CSocket that uses a timer to timeout the UDP receives on the DNS lookups. Other than this I'm using CSocket without modification.
Typical connection failures are:
10060 - Connection Timeout
10065 - No Route
10051 - Net Unreachable
10022 - Invalid Arg. - Seems to refer to unresolvable domain names
10048 - Address in use - Very rare, maybe 1 in 500000 connections.
Any help would be much appreciated.
Thanks-
Frank Vernon
I am developing a multi-threaded app for NT using MFC and VC++ 5.0 that creates multiple simultaneous CSocket connections (both UDP and TCP) in their own "worker" threads. After 60+ TCP connection failures my app, and my machine, "freeze". If only a few connection errors occur, the app runs fine.
My present theory is that the failed connections leave sockets in open or indeterminate states even after I explicity call CSocket::Close. Is this a known problem? Is there a way to force CSocket or the OS to free these resources?
Details:
The app is spawning mutilple simultaneous threads to deliver email via SMTP. Each thread creates one UDP socket to do a MX record lookup from a DNS server and then a second TCP thread to connect to the SMTP server. The UDP socket is closed and its CSocket object destroyed before the TCP socket is created. A connection failure results in an exception being thrown which ultimately calls CSocket::Close. After a connection failure the same CSocket object may then be re-used to attempt a connection to a different server. In general however the CSocket objects are not re-used unless an error occurs as each thread creates its own CSocket objects each time it's spawned.
The connection failures happen at random throughout the sending process, however the number of connection failures before the app freezes remains relatively constant. I have set a max limit of 30 simultaneous threads, and the app tends to average about 15-20 threads actually running at any given time. These threads are running with a priority of "above normal." Memory and CPU usage do not seem to be a factor as the app runs fine if no connection errors occur.
I have created my own socket class that inherits from CSocket that uses a timer to timeout the UDP receives on the DNS lookups. Other than this I'm using CSocket without modification.
Typical connection failures are:
10060 - Connection Timeout
10065 - No Route
10051 - Net Unreachable
10022 - Invalid Arg. - Seems to refer to unresolvable domain names
10048 - Address in use - Very rare, maybe 1 in 500000 connections.
Any help would be much appreciated.
Thanks-
Frank Vernon
ASKER
Aaron-
Thanks so much for you quick and insightfull response. This was definately part of my trouble. The thread priority issue was compounded by a few things in CSocket::Recieve() but I now have it all working.
In testing various combinations, I found that setting the worker thread priority to "below normal" actually increased throughput since it ensures that a maximum number of threads are running at any given time. Since I am heavily bound by network latency this turned out to help a bit.
Thanks again-
Frank Vernon
BTW- This is a very very cool site. I hope I can help someone myself someday.
Thanks so much for you quick and insightfull response. This was definately part of my trouble. The thread priority issue was compounded by a few things in CSocket::Recieve() but I now have it all working.
In testing various combinations, I found that setting the worker thread priority to "below normal" actually increased throughput since it ensures that a maximum number of threads are running at any given time. Since I am heavily bound by network latency this turned out to help a bit.
Thanks again-
Frank Vernon
BTW- This is a very very cool site. I hope I can help someone myself someday.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I suspect that the winsock.dll may have threads running
at normal priority level rather than above. So with a
large number of threads running at a higher priority, you
may be starving the winsock threads. I recommend you try
creating the threads at normal priority... then IF you want,
dynamically change your whole processes priority class (which
is scarry also, but worth a try).
-- Aaron