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
frankv060597Asked:
Who is Participating?

Improve company productivity with a Business Account.Sign Up

x
 
amartin030297Connect With a Mentor Commented:
I'm glad that helped you... I had only put it as a comment
rather than as an answer since I was unsure.. HOWEVER...
since you have the problem solved, would you mind sending
the points my way?? (Since you can't get 'em back anyway)
-- Aaron
0
 
amartin030297Commented:
Just my $.02--
  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

0
 
frankv060597Author Commented:
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.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.