WSAAsyncSelect I/O & Multithreading :: Winsock

[kuphryn]

Hi.

I am working on a simple client-based winsock Windows program. The program works well under the current software design. However, I discovered a huge resource problem.

The program support multiple simultaneous connections. I use the WSAAsyncSelect() I/O model to handle I/O. Everything works well. I implemented two worker threads. One thread sends data. The second thread receives data. WSAAsyncSelect() sends messages via Windows queue and update the program on FD_WRITE, FD_READ, etc. Again, the program works as planned.

I discover a huge resource problem. The program takes up all CPU resource as it makes more and more socket connnections. In other works, the program stalls if the user attemps to makes ten or more connections. CPU usage is 100%.

I re-read Network Programming for Microsoft Windows, Second Edition by Anthony Jones and Jim Ohmund. If I am not mistaken, you do not need workers thread for winsock if you use a non-blocking I/O such as WSAAsyncSelect().

I would like to know if there is a flaw in the program design. My thought right now is that this design will not work because of the worker threads. There is no way Windows can handle too many worker threads. However, let say I implemented WSASend() and WSARecv() solutions directly in the primary thread (main applications), I believe that will lock up Windows or at least the program. For example, if I implement a while loop that calls WSARecv() until it returns 0, that will lock up the program. Is that right?

Thanks,
Kuphryn

[novacain]

I use WSAAsyncSelect() method with nearly 10 sockets. Have no where near 100 cpu usage on my P2 450 test machine. No threads needed. All sockets read and write and receive large data chunks (inc sound and image files).

I think it is because you are doing small multiple receive reads. (It is like reading a file byte by byte rather than the whole lot into memory in one read.)

[kuphryn]

Okay.

Are you referring to a calling WSARecv inside a while-loop?

Kuphryn

[novacain]

Yes. Think of it as a file. You would not read a file byte by byte, it would be too slow.

I read 32Kb at a time (if available) then process the data. As I do not know the size of the incomming file I get sent the size as an int, then the data, then an int, ect.

Have a complex function to sort out the data stream back into its components and send (using function pointers) to be used.

[kuphryn]

Okay. Thanks.

Yes, the problem definitely resulted from a while-loop. I am in the process of implementing a different approach to the algorithm.

I am debug a weird problem. For some reason, I cannot close an event handle. For example,

-----
HANDLE mEvent = ::CreateEvent(NULL, TRUE, FALSE, NULL);
...
// This code crashes the program.
// Visual C++ debug says the error has something to do with an invalid
// handle.
::CloseHandle(mEvent);
-----

Kuphryn