Expoert advice on MFC TCP/IP sockets, please?
-
I seriously suspect MFC's socket implementation is broken. We have developed commercial software based on the MFC CSocket and CAsyncSocket classes. We've used the MFC examples using CFile and CArchive for communication. We have separate software using these classes and they all seems to suffer from the same problem: sockets lockup. When it happens communication stops one way until the socket is closed and a new connection is opened. Anyone here know of any problems in MFC sockets? Will they be solved if we re-write using WinSock, C raw sockets or whatever? What is an expert's advice?
-
I seriously suspect MFC's socket implementation is broken. We have developed commercial software based on the MFC CSocket and CAsyncSocket classes. We've used the MFC examples using CFile and CArchive for communication. We have separate software using these classes and they all seems to suffer from the same problem: sockets lockup. When it happens communication stops one way until the socket is closed and a new connection is opened. Anyone here know of any problems in MFC sockets? Will they be solved if we re-write using WinSock, C raw sockets or whatever? What is an expert's advice?
Warreng Young's article CSocket Considered Harmful strongly discourages the use of MFC socket wrappers. It is hard to know wheter the problems you're experiencing with your app are due to bugs in the implementation of these classes, but you'll be probably better off using raw Winsock sockets (to which the MFC wrappers add little) or some other, better designed, socket library (the Winsock Programmer's FAQ names a few). Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
-
Warreng Young's article CSocket Considered Harmful strongly discourages the use of MFC socket wrappers. It is hard to know wheter the problems you're experiencing with your app are due to bugs in the implementation of these classes, but you'll be probably better off using raw Winsock sockets (to which the MFC wrappers add little) or some other, better designed, socket library (the Winsock Programmer's FAQ names a few). Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Thanks, I'll read the link. I doubt we have any bugs. The software's are three years aold and are installed at numerous customers and have been disected over and over again to find these problems. We've reaching a point where we are convinsed it's a Windows/MFC/WinSock problem. We don't suspect network hardware, since it's running on numerous environments using various network cards, routers, switches and configurations. It's also running on both W2000 and NT4 enviroments, sometimes mixed.
-
I seriously suspect MFC's socket implementation is broken. We have developed commercial software based on the MFC CSocket and CAsyncSocket classes. We've used the MFC examples using CFile and CArchive for communication. We have separate software using these classes and they all seems to suffer from the same problem: sockets lockup. When it happens communication stops one way until the socket is closed and a new connection is opened. Anyone here know of any problems in MFC sockets? Will they be solved if we re-write using WinSock, C raw sockets or whatever? What is an expert's advice?
We've been using the MFC CAsyncSocket class for a number of years now, in part of a commercial distributed system. While we have experienced 'broken' code in the past (I think with the release of VC 4.2, there was an error in one the MFC header files, and the Ioctl call didn't work!), everything does seem to work with the current VC 6. We probably send hundreds of thousands of realtime messages daily, and don't experience any lockups, so I wouldn't immediately suspect MFC. It isn't easy to diagnose a problem like this from a short message, but I would suggest looking at your socket 'reader' programs. I have in the past had lockups when the 'reader' program had a bug and stopped reading the socket. The TCP buffers then filled up, and the 'writer' was blocked. I've implemented socket code both using winsock and MFC, and have found the MFC version generally easier to use. Unless you really want to write and manager your own event loop, I would look for the cause of your problem instead. In any case, you might experience the same problem even if you re-write if it is just a 'reader' bug. Hope this helps... Dharminder Birdi
-
We've been using the MFC CAsyncSocket class for a number of years now, in part of a commercial distributed system. While we have experienced 'broken' code in the past (I think with the release of VC 4.2, there was an error in one the MFC header files, and the Ioctl call didn't work!), everything does seem to work with the current VC 6. We probably send hundreds of thousands of realtime messages daily, and don't experience any lockups, so I wouldn't immediately suspect MFC. It isn't easy to diagnose a problem like this from a short message, but I would suggest looking at your socket 'reader' programs. I have in the past had lockups when the 'reader' program had a bug and stopped reading the socket. The TCP buffers then filled up, and the 'writer' was blocked. I've implemented socket code both using winsock and MFC, and have found the MFC version generally easier to use. Unless you really want to write and manager your own event loop, I would look for the cause of your problem instead. In any case, you might experience the same problem even if you re-write if it is just a 'reader' bug. Hope this helps... Dharminder Birdi
I agree with you. I also have been using the CSocket class extensively in a lot of programs, there were three things that got me in the past: 1. You have to call AfxSocketInit() in each thread you use CSocket. 2. You need a message pump in the thread that uses CSocket if you expect the handlers (such as OnAccept, OnReceive, etc.) to work. 3. You need to check the error code whenever possible and re-establish the connection if necessary. Other than that, it is great! ;) ;) ;)
-
I agree with you. I also have been using the CSocket class extensively in a lot of programs, there were three things that got me in the past: 1. You have to call AfxSocketInit() in each thread you use CSocket. 2. You need a message pump in the thread that uses CSocket if you expect the handlers (such as OnAccept, OnReceive, etc.) to work. 3. You need to check the error code whenever possible and re-establish the connection if necessary. Other than that, it is great! ;) ;) ;)
1. We do this. 2. We use these callbacks 3. We do, including exception handling. What we have done is have parent threads ping the worker threads for alive status. If they are not alive, locked up somehow, first we check IsBlocking() and it is, then we call CancelBlocking() which causes an exception which we then handle and can get out of the locked state. But because this software is communication intensive, it's used for semi-realtime applications that cannot ever lose connection, this is not a satisfactory solution. To answer previous poster, we constantly send messages. One application combination uses one message per second one way, plus other communication originating from both sides. Another application sends at least one message per second, plus otehr communication from both sides frequently (every few seconds kByte sized packets).
-
I seriously suspect MFC's socket implementation is broken. We have developed commercial software based on the MFC CSocket and CAsyncSocket classes. We've used the MFC examples using CFile and CArchive for communication. We have separate software using these classes and they all seems to suffer from the same problem: sockets lockup. When it happens communication stops one way until the socket is closed and a new connection is opened. Anyone here know of any problems in MFC sockets? Will they be solved if we re-write using WinSock, C raw sockets or whatever? What is an expert's advice?
-
Rewrite using WinSock. I tried using MFC CSocket/CFile/CArchive communication in a project about a year ago, suffered mysterious crashes and lockups in testing, and solved all problems by rewriting code with WinSock calls.
markkuk wrote: Rewrite using WinSock. I tried using MFC CSocket/CFile/CArchive communication in a project about a year ago, suffered mysterious crashes and lockups in testing, and solved all problems by rewriting code with WinSock calls. I never had problems with CSocket/CFile/CArchive but I never used it for intensive tasks, just simple text back and forth. Once I tried using it for file transfers it would crash every time. Though not very portable once you send objects through. I like to convert my projects over to WinSock, just havn't got around to it yet. I would recomend that to others as well.