CSocket stoping in PumpMessage (please help)
-
Hi I have a realy stange problem with a mfc networking application I am writing (I couldn't see a netwoking message board, and I think it's more of an mfc problem) Basically I have your standard central server and multiple clients. Clients can connect and run happily doing what they do for hours on end (tests have run for 15 hours no worries) but quite frequently the appliction will freeze at any random time(when this happens all connected instances server and clients also freeze) the cpu usage drops to zero and they do nothing. When I break the app in debug mode (server or client) the code is always waiting at the waitmessage point in the pumpmessage function //sockcore.cpp, PumpMessage function else { // no work to do -- allow CPU to sleep WaitMessage(); //STOPS HERE bPeek = TRUE; } The pumpMessage function is called when a non blocking socket is going to block. I've read a few articles about the pumpmessage function causing a freeze but they all say its for older versions (im using vs 2005). http://support.microsoft.com/kb/154649 Has anybody else had this problem or does anyone know a solution? Your help would be greatly appreciated, as I am currently pulling my hair out over this and getting no where. Tom Hogarth
-
Hi I have a realy stange problem with a mfc networking application I am writing (I couldn't see a netwoking message board, and I think it's more of an mfc problem) Basically I have your standard central server and multiple clients. Clients can connect and run happily doing what they do for hours on end (tests have run for 15 hours no worries) but quite frequently the appliction will freeze at any random time(when this happens all connected instances server and clients also freeze) the cpu usage drops to zero and they do nothing. When I break the app in debug mode (server or client) the code is always waiting at the waitmessage point in the pumpmessage function //sockcore.cpp, PumpMessage function else { // no work to do -- allow CPU to sleep WaitMessage(); //STOPS HERE bPeek = TRUE; } The pumpMessage function is called when a non blocking socket is going to block. I've read a few articles about the pumpmessage function causing a freeze but they all say its for older versions (im using vs 2005). http://support.microsoft.com/kb/154649 Has anybody else had this problem or does anyone know a solution? Your help would be greatly appreciated, as I am currently pulling my hair out over this and getting no where. Tom Hogarth
I'm out of date on this but MFC Socket classes were always bugged when doing asynchronous operations. You could check the MSDN docs for MFC Socket realted bugs and see if any of the unsolved ones fit your issue ( I wouldn't necessarily trust the documented fixes though :suss: ). I've always resorted to direct socket API calls
send recvetc and doing any synchronisation myself. Pretty much every successful socket based client server app I've seen has gone this route including the MFC based one I used to work on. You have to watch your OS version issues as well. Anything pre Windows 2000 may well have a leaky or bugged version of Winsock itself and if you don't service the incoming socket fast enough buffer overruns can kill the OS and take down the whole machine. Even NT wasn't immune it would just take down only the process. If you're getting a full 15 hours of service before anything appears off then test what happens if you loose your network connection. Try actually pulling out the cable at various points to see if your software copes. TCP/IP should be robust enough for this not to cause any problems other than the inevitable lack of service so if service disruption kills your app then there's a bug somewhere. Theres little worse than a problem that takes days to reproduce :^). At least you wont be hunting for this one for 18 months with any luck ;)Nothing is exactly what it seems but everything with seems can be unpicked.
-
Hi I have a realy stange problem with a mfc networking application I am writing (I couldn't see a netwoking message board, and I think it's more of an mfc problem) Basically I have your standard central server and multiple clients. Clients can connect and run happily doing what they do for hours on end (tests have run for 15 hours no worries) but quite frequently the appliction will freeze at any random time(when this happens all connected instances server and clients also freeze) the cpu usage drops to zero and they do nothing. When I break the app in debug mode (server or client) the code is always waiting at the waitmessage point in the pumpmessage function //sockcore.cpp, PumpMessage function else { // no work to do -- allow CPU to sleep WaitMessage(); //STOPS HERE bPeek = TRUE; } The pumpMessage function is called when a non blocking socket is going to block. I've read a few articles about the pumpmessage function causing a freeze but they all say its for older versions (im using vs 2005). http://support.microsoft.com/kb/154649 Has anybody else had this problem or does anyone know a solution? Your help would be greatly appreciated, as I am currently pulling my hair out over this and getting no where. Tom Hogarth
I suggest reading CSocket Considered Harmful[^]. I generally work with Windows CE devices, so I typically run all my socket code as blocking code on a separate thread and use
PostMessageto post custom notifications back to a window for progress updates.Stability. What an interesting concept. -- Chris Maunder
-
Hi I have a realy stange problem with a mfc networking application I am writing (I couldn't see a netwoking message board, and I think it's more of an mfc problem) Basically I have your standard central server and multiple clients. Clients can connect and run happily doing what they do for hours on end (tests have run for 15 hours no worries) but quite frequently the appliction will freeze at any random time(when this happens all connected instances server and clients also freeze) the cpu usage drops to zero and they do nothing. When I break the app in debug mode (server or client) the code is always waiting at the waitmessage point in the pumpmessage function //sockcore.cpp, PumpMessage function else { // no work to do -- allow CPU to sleep WaitMessage(); //STOPS HERE bPeek = TRUE; } The pumpMessage function is called when a non blocking socket is going to block. I've read a few articles about the pumpmessage function causing a freeze but they all say its for older versions (im using vs 2005). http://support.microsoft.com/kb/154649 Has anybody else had this problem or does anyone know a solution? Your help would be greatly appreciated, as I am currently pulling my hair out over this and getting no where. Tom Hogarth
I've written quite a few networking applications using MFC and found two unbreakable rules:
- Never use
CSocket! UseCAsyncSocket. - If the application is multithreaded, all threads that create sockets must be UI-threads since it has to pump messages.
While Matthew and Mike recommends a complete rewrite, I think it would be sufficient to go by the guidelines above and it will probably save a lot of time. The article Mike linked to is very good and points out important flaws in the design of the socket wrapper classes of MFC. In my experience though, if you adhere to the above, your biggest problem would be a slow DNS lookup. The part in the article about deriving from both
CWndandCAsyncSocketdoes not, in my opinion, make any sense. What kind of object is both a window and a socket? However, you may have a window that contains a socket, or in my case at least a UI-thread. Another interesting article about MFC socket implementation can be found here[^]. It points out serious flaws in the way MSDN advices developers to write networking applications.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown - Never use
-
I've written quite a few networking applications using MFC and found two unbreakable rules:
- Never use
CSocket! UseCAsyncSocket. - If the application is multithreaded, all threads that create sockets must be UI-threads since it has to pump messages.
While Matthew and Mike recommends a complete rewrite, I think it would be sufficient to go by the guidelines above and it will probably save a lot of time. The article Mike linked to is very good and points out important flaws in the design of the socket wrapper classes of MFC. In my experience though, if you adhere to the above, your biggest problem would be a slow DNS lookup. The part in the article about deriving from both
CWndandCAsyncSocketdoes not, in my opinion, make any sense. What kind of object is both a window and a socket? However, you may have a window that contains a socket, or in my case at least a UI-thread. Another interesting article about MFC socket implementation can be found here[^]. It points out serious flaws in the way MSDN advices developers to write networking applications.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknownRoger Stoltz wrote:
While Matthew and Mike recommends a complete rewrite
Roger Stoltz wrote:
it will probably save a lot of time.
Now or later? See "Technical Debt[^]" The Microsoft documentation recommends using the Winsock2 library for Socket development. I would heed that advice. It doesn't take much work to write a class that encapsulates the socket handle and the Winsock2 API. Then for async operations you can use Overlapped IO which is also the recommended method for handling async operations. I mean I know it's only 2007 and this article[^] is brand new, only written in 2000 :rolleyes:
- Never use
-
Hi I have a realy stange problem with a mfc networking application I am writing (I couldn't see a netwoking message board, and I think it's more of an mfc problem) Basically I have your standard central server and multiple clients. Clients can connect and run happily doing what they do for hours on end (tests have run for 15 hours no worries) but quite frequently the appliction will freeze at any random time(when this happens all connected instances server and clients also freeze) the cpu usage drops to zero and they do nothing. When I break the app in debug mode (server or client) the code is always waiting at the waitmessage point in the pumpmessage function //sockcore.cpp, PumpMessage function else { // no work to do -- allow CPU to sleep WaitMessage(); //STOPS HERE bPeek = TRUE; } The pumpMessage function is called when a non blocking socket is going to block. I've read a few articles about the pumpmessage function causing a freeze but they all say its for older versions (im using vs 2005). http://support.microsoft.com/kb/154649 Has anybody else had this problem or does anyone know a solution? Your help would be greatly appreciated, as I am currently pulling my hair out over this and getting no where. Tom Hogarth
-
Roger Stoltz wrote:
While Matthew and Mike recommends a complete rewrite
Roger Stoltz wrote:
it will probably save a lot of time.
Now or later? See "Technical Debt[^]" The Microsoft documentation recommends using the Winsock2 library for Socket development. I would heed that advice. It doesn't take much work to write a class that encapsulates the socket handle and the Winsock2 API. Then for async operations you can use Overlapped IO which is also the recommended method for handling async operations. I mean I know it's only 2007 and this article[^] is brand new, only written in 2000 :rolleyes:
led mike wrote:
Now or later? See "Technical Debt[^]"
You're pulling my leg, right?
led mike wrote:
The Microsoft documentation recommends using the Winsock2 library for Socket development.
:confused: :~ I haven't found any statement in MSDN that says something like "don't use CSocket or CAsyncSocket". There are multiple ways of how to write networking applications; using raw sockets or MFC wrapper classes are two of them. Microsoft may provide documentation and examples of how to do it in either way, but I haven't found either of them endorsed by Microsoft. It could be as simple as I haven't looked in the right document yet... ;) My point was that the way Microsoft recommends their own MFC wrapper classes to be used in KB192570 with surroundings does not do the trick, which should be fairly obvious if one reads the article I linked to.
led mike wrote:
It doesn't take much work to write a class that encapsulates the socket handle and the Winsock2 API.
:-D Sorry, but my experience tells me that whenever someone put it like that, they are almost always wrong. If they are right it has to be a developer who left the beginner state a long time ago. That doesn't mean you couldn't do it in a heartbeat. :rose: The article you linked to looks great at the first glimpse. I will read it carefully when I have the time and try the concept out. Thanks a lot.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown -
led mike wrote:
Now or later? See "Technical Debt[^]"
You're pulling my leg, right?
led mike wrote:
The Microsoft documentation recommends using the Winsock2 library for Socket development.
:confused: :~ I haven't found any statement in MSDN that says something like "don't use CSocket or CAsyncSocket". There are multiple ways of how to write networking applications; using raw sockets or MFC wrapper classes are two of them. Microsoft may provide documentation and examples of how to do it in either way, but I haven't found either of them endorsed by Microsoft. It could be as simple as I haven't looked in the right document yet... ;) My point was that the way Microsoft recommends their own MFC wrapper classes to be used in KB192570 with surroundings does not do the trick, which should be fairly obvious if one reads the article I linked to.
led mike wrote:
It doesn't take much work to write a class that encapsulates the socket handle and the Winsock2 API.
:-D Sorry, but my experience tells me that whenever someone put it like that, they are almost always wrong. If they are right it has to be a developer who left the beginner state a long time ago. That doesn't mean you couldn't do it in a heartbeat. :rose: The article you linked to looks great at the first glimpse. I will read it carefully when I have the time and try the concept out. Thanks a lot.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknownRoger Stoltz wrote:
You're pulling my leg, right?
Ummm No, what do you find humorous about that?
Roger Stoltz wrote:
I haven't found any statement in MSDN that says something like "don't use CSocket or CAsyncSocket".
That's not what I said.
led mike wrote:
The Microsoft documentation recommends using the Winsock2 library for Socket development.
Roger Stoltz wrote:
my experience tells me that whenever someone put it like that, they are almost always wrong.
Then I find your experience lacking
Roger Stoltz wrote:
If they are right it has to be a developer who left the beginner state a long time ago. That doesn't mean you couldn't do it in a heartbeat.
First, if you look at my profile you will see I am not a beginner. Second, IMHO, a person should not be writing production socket code if they can't perform the simple task of authoring a Socket class that encapsulates the Winsock2 API and a socket handle.
-
Roger Stoltz wrote:
You're pulling my leg, right?
Ummm No, what do you find humorous about that?
Roger Stoltz wrote:
I haven't found any statement in MSDN that says something like "don't use CSocket or CAsyncSocket".
That's not what I said.
led mike wrote:
The Microsoft documentation recommends using the Winsock2 library for Socket development.
Roger Stoltz wrote:
my experience tells me that whenever someone put it like that, they are almost always wrong.
Then I find your experience lacking
Roger Stoltz wrote:
If they are right it has to be a developer who left the beginner state a long time ago. That doesn't mean you couldn't do it in a heartbeat.
First, if you look at my profile you will see I am not a beginner. Second, IMHO, a person should not be writing production socket code if they can't perform the simple task of authoring a Socket class that encapsulates the Winsock2 API and a socket handle.
Respectfully: Seems like we have a small communication problem, try not to make it worse. You urge me to look at your profile to find that you're not a beginner, yet you seem to have assumed that I am one. Furthermore you "find my experience lacking". :rolleyes: I tried hard not to offend you and make assumptions about your skills and I did not imply that you are a beginner. You also seem to make the same statement I did, or at least similar, when you write "a person should not be writing production socket code if they can't perform the simple task of authoring a Socket class that encapsulates the Winsock2 API and a socket handle". I agree, but I don't assume that the OP is that experienced regarding this since he asked the question. Regarding what Microsoft recommends or not, your wrote that "recommends using the Winsock2 library for Socket development" which I, in my most humble way, claimed I haven't found. Not yet, at least. I don't say that you are neither right or wrong.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown -
Respectfully: Seems like we have a small communication problem, try not to make it worse. You urge me to look at your profile to find that you're not a beginner, yet you seem to have assumed that I am one. Furthermore you "find my experience lacking". :rolleyes: I tried hard not to offend you and make assumptions about your skills and I did not imply that you are a beginner. You also seem to make the same statement I did, or at least similar, when you write "a person should not be writing production socket code if they can't perform the simple task of authoring a Socket class that encapsulates the Winsock2 API and a socket handle". I agree, but I don't assume that the OP is that experienced regarding this since he asked the question. Regarding what Microsoft recommends or not, your wrote that "recommends using the Winsock2 library for Socket development" which I, in my most humble way, claimed I haven't found. Not yet, at least. I don't say that you are neither right or wrong.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknownRoger Stoltz wrote:
I tried hard not to offend you and make assumptions about your skills and I did not imply that you are a beginner.
Roger Stoltz wrote:
when you write "a person should not be writing production socket code if they can't perform the simple task of authoring a Socket class that encapsulates the Winsock2 API and a socket handle". I agree, but I don't assume that the OP is that experienced regarding this since he asked the question.
My comments were directed towards the OP, since his project is the subject, with the single exception of the reply to your "they are almost always wrong" comment.
Roger Stoltz wrote:
I tried hard not to offend you
I took no offense to anything you said, I just disagree with some of it.
-
Hi I have a realy stange problem with a mfc networking application I am writing (I couldn't see a netwoking message board, and I think it's more of an mfc problem) Basically I have your standard central server and multiple clients. Clients can connect and run happily doing what they do for hours on end (tests have run for 15 hours no worries) but quite frequently the appliction will freeze at any random time(when this happens all connected instances server and clients also freeze) the cpu usage drops to zero and they do nothing. When I break the app in debug mode (server or client) the code is always waiting at the waitmessage point in the pumpmessage function //sockcore.cpp, PumpMessage function else { // no work to do -- allow CPU to sleep WaitMessage(); //STOPS HERE bPeek = TRUE; } The pumpMessage function is called when a non blocking socket is going to block. I've read a few articles about the pumpmessage function causing a freeze but they all say its for older versions (im using vs 2005). http://support.microsoft.com/kb/154649 Has anybody else had this problem or does anyone know a solution? Your help would be greatly appreciated, as I am currently pulling my hair out over this and getting no where. Tom Hogarth
Hi again guys Your debate seems to be coming along nicely :). Using CAsyncSocket seems to have done the trick (although I still need to sort the asynchronous sending) It's still quite annoying that the CSocket seems unstable. It's possible it was my fault but all the debugging I did only lead to the conclusion it was a problem with CSocket. Think when I get the time I'll sort a proper wrapper for raw sockets. I did one long ago at university but time is of the essence at the moment. Keep the debate moving, it's the best way for people to learn. Cheers Tom
-
Hi again guys Your debate seems to be coming along nicely :). Using CAsyncSocket seems to have done the trick (although I still need to sort the asynchronous sending) It's still quite annoying that the CSocket seems unstable. It's possible it was my fault but all the debugging I did only lead to the conclusion it was a problem with CSocket. Think when I get the time I'll sort a proper wrapper for raw sockets. I did one long ago at university but time is of the essence at the moment. Keep the debate moving, it's the best way for people to learn. Cheers Tom
-
PS I am (the OP) quite experienced but you guys fell off the trail, the question was about the CSocket WaitMessage problem, NOT about how I can encapsulate an existing class. Keep it easy Tom
Well, Tom...
tomitron wrote:
I am (the OP) quite experienced
Yes, you may very well be experienced. But since this is a forum other readers will seek guidance from the forum threads even though they don't post in them. So I try to assume as little as possible about the skills of the people asking questions, without leaving the boundaries of the question. I have made the mistake of assuming people to be more experienced than they actually were. That started discussions or suggestions which lead them into more trouble than necessary and it was even harder to get them out of it. That is also why I suggested you to use
CAsyncSocketsince you seemed to be familiar withCSocket. I believe that the step fromCSockettoCAsyncSocketis smaller (and will give you a solution "good enough") than using raw sockets, even if the latter can be considered to be more technically correct in certain ways.tomitron wrote:
you guys fell off the trail, the question was about the CSocket WaitMessage problem
Well, it's quite common that someone else than the OP replies to a post that was posted as a reply to the OP. That could be to "debate" something or exchange ideas and opinions that may not necessarily be related to the OP's question. If they were related I would expect it to generate a reply to the OP in some way as I've seen in a lot of forum threads. Regarding your
WaitMessage()problem, I stand by my first post and recommend you to read the article I linked to. Off topic: I stumbled upon your post by accident, otherwise I wouldn't have known that you posted again since you have replied to yourself. If you would have replied to me I would have gotten an email.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown -
Well, Tom...
tomitron wrote:
I am (the OP) quite experienced
Yes, you may very well be experienced. But since this is a forum other readers will seek guidance from the forum threads even though they don't post in them. So I try to assume as little as possible about the skills of the people asking questions, without leaving the boundaries of the question. I have made the mistake of assuming people to be more experienced than they actually were. That started discussions or suggestions which lead them into more trouble than necessary and it was even harder to get them out of it. That is also why I suggested you to use
CAsyncSocketsince you seemed to be familiar withCSocket. I believe that the step fromCSockettoCAsyncSocketis smaller (and will give you a solution "good enough") than using raw sockets, even if the latter can be considered to be more technically correct in certain ways.tomitron wrote:
you guys fell off the trail, the question was about the CSocket WaitMessage problem
Well, it's quite common that someone else than the OP replies to a post that was posted as a reply to the OP. That could be to "debate" something or exchange ideas and opinions that may not necessarily be related to the OP's question. If they were related I would expect it to generate a reply to the OP in some way as I've seen in a lot of forum threads. Regarding your
WaitMessage()problem, I stand by my first post and recommend you to read the article I linked to. Off topic: I stumbled upon your post by accident, otherwise I wouldn't have known that you posted again since you have replied to yourself. If you would have replied to me I would have gotten an email.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknownAll fixed, A great thanks goes out for the info. I had been thinking switching methods was an option but thought I was just bailing out on what could have been a simple bug. At least CAsyncSocket was simple to change to and I can't see any further issuses occuring. One last question what does OP mean? (Original Poster?). I'm quite new to actually posting on forums. I normally find my answer on someone else’s thread. Once again Thanks Tom
-
All fixed, A great thanks goes out for the info. I had been thinking switching methods was an option but thought I was just bailing out on what could have been a simple bug. At least CAsyncSocket was simple to change to and I can't see any further issuses occuring. One last question what does OP mean? (Original Poster?). I'm quite new to actually posting on forums. I normally find my answer on someone else’s thread. Once again Thanks Tom
tomitron wrote:
One last question what does OP mean? (Original Poster?).
It could mean "original poster" or "original post" depending on the context, i.e. either the post or the person behind it. I'm happy that it worked out for you. One other thing though: it would be a nice touch if you rate posts, either good or bad. Of course you're not obligated to do so and no feelings are hurt if you don't.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown -
Hi again guys Your debate seems to be coming along nicely :). Using CAsyncSocket seems to have done the trick (although I still need to sort the asynchronous sending) It's still quite annoying that the CSocket seems unstable. It's possible it was my fault but all the debugging I did only lead to the conclusion it was a problem with CSocket. Think when I get the time I'll sort a proper wrapper for raw sockets. I did one long ago at university but time is of the essence at the moment. Keep the debate moving, it's the best way for people to learn. Cheers Tom
You might have solved your problem by now, but one other reason that CSocket sometimes appears to "freeze" is that another one of the "golden rules" of sockets is broken: Don't call Receive() multiple times inside of OnReceive(). The correct code will make exactly one single call to Receive() inside OnReceive(). MSDN advises that multiple calls to Receive() can cause the application to freeze. The same rule applies to CAsyncSocket() too. See "Mfcsocs.exe sample demonstrates how to communicate in a TCP connection in Visual C++" at http://support.microsoft.com/kb/185728[^], which talks about a situation in which there are no more FD_READs. The simple little word about the application "hanging" is so important that it should be in large red bold letters, but it's not. Mike
-
You might have solved your problem by now, but one other reason that CSocket sometimes appears to "freeze" is that another one of the "golden rules" of sockets is broken: Don't call Receive() multiple times inside of OnReceive(). The correct code will make exactly one single call to Receive() inside OnReceive(). MSDN advises that multiple calls to Receive() can cause the application to freeze. The same rule applies to CAsyncSocket() too. See "Mfcsocs.exe sample demonstrates how to communicate in a TCP connection in Visual C++" at http://support.microsoft.com/kb/185728[^], which talks about a situation in which there are no more FD_READs. The simple little word about the application "hanging" is so important that it should be in large red bold letters, but it's not. Mike