|
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 PostMessage to post custom notifications back to a window for progress updates.
|
|
|
|
|
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
|
|
|
|
|
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 
|
|
|
|
|
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... 
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]](https://www.codeproject.com/script/Forums/Images/rose.gif)
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
|
|
|
|
|
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".
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
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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 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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
Thanks mate. I have solved it but it is true that microsoft sould be abit more open about what can go wrong with csocket. Especially since it is the default class when using wizards
|
|
|
|
|
I added Xp style to my application.According to the instruction of the following article(From www.CodeProject.com).
http://www.codeproject.com/w2k/xptheme.asp?df=100&forumid=2590&exp=0&select=1186683&mpp=50#xx1186683xx
But the problem was there was a border around the button i created using
CButton::Create().
So i need to get rid of that problem.pls reply me
bhw
|
|
|
|
|
please ask this on the dedicated forum at the bottom of the article... the author will certainly reply to you faster there.
|
|
|
|
|
Still Author did not reply my Question
bhw
|
|
|
|
|
You must wait he/she needs to read your question.;)
|
|
|
|
|
1>Linking...
1> Creating library Debug\Polygon.lib and object Debug\Polygon.exp
1>Embedding manifest...
1>Registering output...
1>Build Time 0:13
1>Build log was saved at "file://c:\CodeStation\Polygon\Debug\BuildLog.htm"
1>Polygon - 0 error(s), 0 warning(s)
2>------ Skipped Build: Project: PolygonPS, Configuration: Debug Win32 ------
2>Project not selected to build for this solution configuration
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 1 skipped ==========
In above ATL object compilation the output is a dll. What is the significance of a lib and an exp at the same time.
Secondly what is the intend of a manifest and why is it embedded?
|
|
|
|
|
Mr Groezer,
You seem to me to be a beginner. I have nothing against that, because I know some things are difficult to assimilate when we don't know them at first.
BUT
you also seem to me to be a bit too lazy, because your questions sound like interviews.
I now don't think anymore you are passing any interview, because it's been too long now since you first asked a question of that style. but sincerely, Google AND MSDN are your friends, especially in those matters, and you should not intend a programming forum to answer every of your question, even if everyone can answer them.
The forum is a place where you have to show a professional behavior. that means when you have a basic point to figure out, first search the web for it yourself, try to keep it fixed yourself, see the web if anyone already encountered that issue before you, and only then, you ask, providing all the infos that will permit us to help you (that is, all the steps you've done before asking the forum).
thanks for understanding that i am being indulgent by not blaming you much
|
|
|
|
|
Thanks Mr Toxcct. I was expecting some practical answer not bookish knowledge from google  
|
|
|
|
|
then, practically, a .lib file is used when linking a dll statically in your project. it is not needed if you link dynamically, but you'll have to know the dll exported symbols to use them.
about the .exp files, I don't know much, but i never used them, and it seems that they are only generated in debug mode, so they are certainly not worth it to think to much on them
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
). I've always resorted to direct socket API calls 
. At least you wont be hunting for this one for 18 months with any luck