System.Net.Socket -> waitBlockInternal

[Josh Patterson]

Ive been working on this async multithreaded server that sends data back and
for between 2 nodes/boxes; Every so often, the async listener thread blocks
and will not take any incoming connections (I can verify this as my protocol
is http/html/soap based so i can point a webbrowser at it and check out any
box running the process). I can run the process for 40k transactions, and it
will run fine, and then the blocking bug will happen sometimes when its only
been 2000 transactions. I have debugged and debugged, and always the listen
thread is blocking on the ManualResetEvent.WaitOne(); call, as it should,
but "BeginAccept()" never spins off a new request onto the threadpool as it
should. I modeled the basics of this app after:

http://msdn.microsoft.com/library/d...html/cpconnon-blockingserversocketexample.asp

Some people have mentioned that it could possibly be a problem where there
arent enough threads available on the thread pool, but ive checked that as
well (ran into that one before) via

ThreadPool::GetAvailableThreads( &nWorkerThreads, &nIOThreads );

which is telling me that plenty of threads are available to service the
incoming request.

So. I have been debugging, and the only thing i can find when this situation
occurs, that would be out of the ordinary, is that a variable of the listen
socket, "waitBlockInternal" is set to "true" whenever this occurs. It's
value is always "false" any other time the code is running as far as i can
see. I could be totally off base here, creating a deadlock issue SOMEWHERE
else in teh code, but I noticed this and just wondering if anyone could
confirm or dispell my theory on the waitBlockInternal member. I am in the
process of stripping the codebase back into just a core skeleton to isolate
it into just enough code to shoot text back and forth constantly between 2
processes.

Ideas?

Josh Patterson

 

[Josh Patterson]

I've continued to work on this problem, as it holds up development on this
project, being the underlying tech we are working on to build on top of;

To take myself, and any faulty techniques I may be using, out of the
equation, I looked into MSDN to get some examples from MS itself of the
async tcp code. I copied:

http://msdn.microsoft.com/library/d...html/cpconnon-blockingserversocketexample.asp

for my sync tcp client and

http://msdn.microsoft.com/library/d...html/cpconnon-blockingserversocketexample.asp

for my async server, very similar to my current setup, but a seperate
codebase to that of my own. I setup each c# example into its own project.
Now, I made 2 simple modications for demonstration purposes:

1.) Line ~27 of the client app, I changed to read as:

//IPHostEntry ipHostInfo = Dns.Resolve("192.168.0.6");

//IPAddress ipAddress = ipHostInfo.AddressList[0];

IPAddress ipAddress = IPAddress.Parse( "192.168.0.6" );

(the only real change being i pointed the app back at the client box, where
the server would be running too.)

2.) in the "Main" function of the client app, I changed it to connect in a
loop as so:

public static int Main(String[] args) {

for (int x = 0; x < 40000; x++) {

Console.WriteLine( x.ToString() );

StartClient();

}

return 0;

}



Which continually causes it to hammer the server, causing a mini stress test
effect. Other than that, the code is identical to the MSDN examples. Again,
eventually the server app blocks and takes no more connections, just like my
application, and under further examination in break/debug mode, the only
thing i can see is the "waitBlockInternal" flag is once again set to "true"
when this happens. Any comments or suggestions would be most appreciated.



Josh Patterson