C / C++ / MFC

20-Jun-07 1:55

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

Matthew Faithfull20-Jun-07 2:53

Matthew Faithfull

20-Jun-07 2:53

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 Suspicious | :suss:

). I've always resorted to direct socket API calls send recv etc 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 Sniff | :^)

. At least you wont be hunting for this one for 18 months with any luck Wink | ;)

Nothing is exactly what it seems but everything with seems can be unpicked.

Mike Dimmick20-Jun-07 3:44

Mike Dimmick

20-Jun-07 3:44

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 PostMessage to post custom notifications back to a window for progress updates.

Stability. What an interesting concept. -- Chris Maunder

Roger Stoltz20-Jun-07 4:29

20-Jun-07 4:29

I've written quite a few networking applications using MFC and found two unbreakable rules:

Never use CSocket! Use CAsyncSocket.
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 CWnd and CAsyncSocket does 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

led mike20-Jun-07 5:28

led mike

20-Jun-07 5:28

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 Roll eyes | :rolleyes:

Roger Stoltz20-Jun-07 6:21

20-Jun-07 6:21

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.

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... Wink | ;)

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.

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 | [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 mike20-Jun-07 6:32

led mike

20-Jun-07 6:32

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.

Roger Stoltz20-Jun-07 6:57

20-Jun-07 6:57

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". Roll eyes | :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

led mike20-Jun-07 8:43

led mike

20-Jun-07 8:43

Roger 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.

tomitron20-Jun-07 5:44

20-Jun-07 5:44

Thanks guys, your adivse is will definatly be used. I think my best bet is to re write. I've started looking at casyncsocket and it seems like I wont need much modification so I'll try that first.

Thanks once again

I'll keep you posted

Tom

tomitron21-Jun-07 1:38

21-Jun-07 1:38

Hi again guys

Your debate seems to be coming along nicely Smile | :)

. 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

tomitron21-Jun-07 1:41

21-Jun-07 1:41

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

Roger Stoltz21-Jun-07 3:38

21-Jun-07 3:38

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 CAsyncSocket since you seemed to be familiar with CSocket. I believe that the step from CSocket to CAsyncSocket is 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

tomitron21-Jun-07 5:33

21-Jun-07 5:33

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

Roger Stoltz22-Jun-07 1:05

22-Jun-07 1:05

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

Mike O'Neill6-Jul-07 14:07

Mike O'Neill

6-Jul-07 14:07

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

tomitron6-Jul-07 14:52