Incredible problem with MFC socket

[s_k]

Hi, I'm developing server application (FTP server). It works very well and it is very stable under all platforms (win9x/2k/nt/xp). But now I have a problem. We have new LAN (100mb), very fast (file transfer from/to server about 5000 kB/s). Here is the problem: Under W9x, when I start uploading/downloading big file (at least 30 MB), transfer starts and everything seems to be ok. But, when I want to list directory in client (eg Total Commander), server gives no response and the machine where the server is running is totally frozen up. With one exception - file transfer that I've started before, is going on well...When I kill the connection from client, server is ok again (as well as the whole OS). Some bug, I said. I tried to trace the error, so I put breakpoints to my socket OnReceive function. But NO DATA arrive to my socket, at least this function is never executed...I must note that this problem occurs only on this new LAN, when we had slower (10 mbps), it was ok...So where to search for the error ? I think that the bug must somewhere in CSocket/CAsyncSocket... Thanks for anything... Standa.

[Todd C Wilson]

MFC Sockets are worthless for anything I (and lots of other people) would consder "real use". The problem is that they are still based on the Windows 3.1 sockets design, in that they need to have access to a message handler and etc. What you're experiancing is probably message stavaration between the socket handlers and the windows handlers - you've got one socket loading down the handler, and none of the other ones can efecitivly get into it. For light use, MFC sockets can work on - for example, look at the Microsoft MSDN exampe "Chatsvr" which is a trivial messaging app using CSockets. For more robust sockets, I would look into some of the other things here on CodeProject, in the Networking code section. You should also consider using threads to handle socket actions, so that one socket will not load down the system. This is the method I've used in a high-end 1000+ client server - one thread for each client SOCKET handle (no MFC in it). WarFTP is open sourced I think, and is a Windows app, you might want to give that a look-see. That's my $0.02

---

"Perhaps the truth is less interesting than the facts?" -- Amy Weiss, RIAA's Senior Vice President of Communications.
It's the new math! 421 == 156 !

[Moak]

s_k wrote: Server gives no response and the machine where the server is running is totally frozen up. With one exception - file transfer that I've started before, is going on well...When I kill the connection from client, server is ok again (as well as the whole OS). Sounds pretty odd. I think you need to give details about your socket use. Do you use CAsnyncSocket (not CSocket)? Do you run sockets asynchronously in one thread context? Check which part is locking up your server, is it really socket core (winsock <-> application messages) or your GUI (application <-> GUI messages)?

[s_k]

I know MFC sockets are not ideal. But they work well for me, with the exception of this one problem. Otherwise, 30-35 clients even on Win98 and server is absolutely ok... Yes, I use separate thread for each fike transfer, that's why I can't understand this behaviour... Is it better to use CSocket or CAsyncSocket ? Standa.

[s_k]

I use my own class derived from CSocket, is it better to use CAsyncSocket ? I start separate working thread for each transfer, so I can't understand why one socket blocks whole OS...

[Moak]

s_k wrote: I use my own class derived from CSocket, is it better to use CAsyncSocket ? I would use CAsyncSocket or something else (but NOT CSocket). s_k wrote: I start separate working thread for each transfer, so I can't understand why one socket blocks whole OS... There are different socket concepts, the possible alternatives are: a) blocking servers (handling only one request at a time, then wait again blocking) b) threaded servers (handling simultaneous requests, one thread for every new socket). c) asynchronous server (handling simultaneous requests, one server thread will handle all sockets - CAsyncSocket will cover this) The server model always depends on application requirements.

[s_k]

But when I have the second case (threaded server) and start separate thread for each transfer, it is better to use CSocket, isn't it ?

[Moak]

s_k wrote: But when I have the second case (threaded server) and start separate thread for each transfer, it is better to use CSocket, isn't it ? Are you sure you want this? Multiple threads means using IPC or mutex or even more logic to avoid deadlocks or destroying your shared data. CSocket + multiple threads for incoming sockets is the worst of all combinations/possibilities IMHO.

[s_k]

But it works perfectly on all platforms, under extreme utilization...This problem only appears on very weak machines (32MB RAM) and only on Win95/98...

[Moak]

s_k wrote: But... you opened the can of worms, good luck with it! :)