One for the CSocket Gurus.. an MFC Bug?

[Bob Sheep]

It's been annoying me for some time that MFC sockets don't seem to work under heavy usage. I have an app which handles 2000+ concurrent TCP connections and when the server app starts up and start accepting client requests it hangs. I solved the problem by writing my own non-mfc socket class.

But looking at CSocket I think I've found a bug so I invite all those CSocket gurus to see if I'm right.

In PumpMessages if the message is a socket notification for a socket for which we're not interested in (that is not the current socket) the msg is placed in the AuxQueue. When we finally process the notification for our socket a WM_SOCKET_NOTIFY is posted to process the accumulated socket notifications for other sockets handled by this thread.

But..... If CancelBlockingCall is called from OnMessagePending (as you would for a timeout) then the message is never posted because WSAEINTR is returned leaving these messages unprocessed until the code gets around to posting another WM_SOCKET_NOTIFY.

The code is the same for VC++ 6.0, &.0 and 7.1

I think I'm right but I'd like others to see if they can agree/disagree with me.

[Bob Sheep]

Looks like I'm on my own. Sigh.

[OReubens]

Well, you are right, but it's not so much a bug in MFC rather than you trying to use CSocket to do something it wasn't designed to do.

From your description, I would guess that CSocket is too abstract for your purposes. CSocket was created to work together with CArchive & CSocketFile.
CAsyncSocket (the parent class of CSocket) is probably a better way to go.

[Bob Sheep]

Thanks for that I appreciate it.
Any way I have written my own classes which work well enough for my needs now. It's just that the company I work for had always insisted that we use MFC Sockets and I was getting so many problems. I thought there was this problem but never found it until now.

Many thanks.

[OReubens]

Well, your company is right in trying to get programmers to use as much of the available classes as possible. The MFC classes are well tested and do the job they were designed to do very well.

If however you need to do something the classes weren't actually designed to do.. Then it sometimes becomes messy or even impossible to get the thing done that you want. In this particular case, I'm guessing you chose a class that was already too special purpose (CSocket), and you should've gone a more generic class (CAsyncSocket). Maybe it would be a nice exercise to see if whatever you're doing would have actually worked well with CAsyncSocket. (But don't tell your bosses or they'll make you change something that works ;-))

[Andreas Masur]

[Moved thread]