|
As I see you just get some data somewhere and send it over to another place, your app is a transmitter between 2 endpoints. This is quite simple fortunately. If you are not allowed to drop data then your send speed must be at least as big as your receive speed. A buffer helps only in smoothing away jitter in the incoming data to maintain a better average throughput. If your incoming data is more than what you can send then the problem can not be solved. If you are able to reach the required send speed with blocking you should be able to do the same with async as well. Anyway, why do you want to use async sockets?
|
|
|
|
|
Hello pasztorpisti,
Re: Anyway, why do you want to use async sockets?
Async makes the application easier to deal with. First, when the client has not connected the main application can still capture data from the source and provide feedback as to how it is performing. Once the Listen() is posted, the app is stuck there and can do nothing.
Second, if the client closes the connection before my app closes, the app is stuck and must be killed. That causes some resource loss eventually requiring a computer boot.
I have mitigated that quite a bit by writing my own client application that can be fired up and release the main application. But I am not always the user and that is a real pain to require someone else to do. (BTW: Writing the client application was indeed a learning experience.)
I suspect that both of these problems can be resolved by using a separate thread for the TCP/IP part of the application. I found a tutorial and will be working on that aspect.
However, I have a working version and do not have unlimited time to devote to this project.
pasztorpisti, Richard M, and others,
Thank you very much for the time you have spent answering my questions and making suggestions. I am very gratefull.
Thanks for your time
-- modified 28-Dec-12 9:15am.
|
|
|
|
|
You are welcome! If you have limited time (as I suspected) then choose a working solution of yours if you already have one. You can later experiment on better solutions if you are interested in threading/sockets. 
|
|
|
|
|
RE: I highly recommend using dedicated threads that do just the transfer between your memory buffers and the socket buffers.
Do you have a favorite tutorial or discussion on how to implement a dedicated thread such as this? Something for someone that has never tried multiple threads.
Thanks for your time
|
|
|
|
|
Unfortunately I don't know about any good tutorials because I'm not in need of one. I learnt from teammates and from my own experiments. You dont always benefit from dedicated threads, that depends on the scenario but you can not find that out without trying.
|
|
|
|
|
 This is a great answer, I really wish I could vote on it.
Quote: Networking is always tricky
You are totally correct. It looks so simple and we use networking applications all the time, but as soon as you have to do a bit more than a basic chat sample, small surprises crop up all over and you start racking up on "experience points" as you try to solve them .
Soren Madsen
|
|
|
|
|
Soren,
You are quite right. It is easy for forget, and much easier to never even realize, just how much effort has gone into writing the core code within the Operating Systems that we use every day without realizing how much goes on that we do not see.
It is easy to complain about Microsoft or any other OS. The reality is that all of them do a quite difficult job very well.
Thanks for your time
|
|
|
|
|
Thank you! Pretty much all areas of programming can become tricky if you cross the line.  I've always considered myself a generalist programmer and I'm definitely not a network expert. I've just had the luck to work on some specialized networking apps.
|
|
|
|
|
Visual Studio 2008, MFC, CAsyncSocket
The programmer creates the overrides such as OnAccept(). Here is a fragment from elsewhere on this site:
void MyEchoSocket::OnAccept(int nErrorCode)
{
if(nErrorCode==0)
{
((CEchoServerDlg*)m_pDlg)->OnAccept();
}
CAsyncSocket::OnAccept(nErrorCode);
}
Note that the comment says and/or. The question is: Is there a need to have the call CAsyncSocket::OnAccept()? In the over-ride code can I just execute what I want done and forget that call to CAsyncSocket::OnAccept()?
Thanks for your time
|
|
|
|
|
Here is the implementation of CAsyncSocket::OnAccept():
void CAsyncSocket::OnAccept(int )
{
}
As you see it doesn't count whether you call it or not but in my opinion its always better to upcall base class methods when you are not sure what to do and the upcall doesn't do any harmful thing to your code. In this case its unlikely that MS changes the implementation of such a core class but generally when you use others' classes as a baseclass its better not to build anything on assumptions. Imagine what happens if you refactor your socket code and you change the baseclass of your socket class from CAsyncSocket to another socket class of yours that does something meaningful in OnAccept()... So here I recommend the upcall as I think its a good practice.
|
|
|
|
|
In general, you do want to call the base class method (be careful of when you call it, sometimes it's appropriate to do it before your code, sometimes you want to do it after your code).... in certain cases, it doesn't matter (it's an empty place holder) or you don't want the default behavior of the base class at all, in which case you don't call it at all.
If you don't call the base class method, be sure you know why you're not calling it because sometimes the methods will do things in the background that are important to the operation of the base class.
|
|
|
|
|
This is a telemetry application where data arrives in a continuous stream. My application breaks that data out into named parameters and sends it to a display device. It generates at least two packets per millisecond and often ten or more.
As a result I will check to see if I can find any operations performed by the base class. When there are none time is saved by not making the call.
I do worry that they may be things done by that call that I do not have visibility into, hence the question.
Thank you for your time.
|
|
|
|
|
So your real issue is how to process the data in the fastest way possible. When this is the issue it is usually best to avoid MFC classes and use the straight Win32 functions.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
Good point. I started a new thread to ask that question.
Thanks for your time
|
|
|
|
|
Windows XP and 7, Visual Studio 2008, MFC, C++
While working with some checkboxes I made an error and created the event handler in an incorrect class. I think I have recovered from that. But maybe not completely.
Now after creating a checkbox, the right click and Add Variable option is grayed out. I have tried deleting the following files: .ncb and .suo and .user and .aps, and deleted directory Debug. After a Clean and Rebuild the problem remains.
Does anyone have any suggestions as to how to resolve this problem?
Thanks for your time
|
|
|
|
|
There is no point in randomly deleting files unless you understand their purpose. It may be that you have left some unconnected data that is confusing the class wizard, which holds its information in the .clw file. However, make sure you keep a backup copy of this file before deleting it.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
Those were not random deletions. They were named in anaother forum. I have collected a list of files that have become corrupt and caused problems.
In the meantime I think I have figured out how to add control variable manually. The jury is still deliberating, but so far it appears to work.
Thanks for your time
|
|
|
|
|
Visual Studio 2008, MFC, C++
Is there a determine if, as a program starts, it is already running one or more times. Not has run, but is currently already running?
Thanks for your time
|
|
|
|
|
There's a really good example here[^].
|
|
|
|
|
Yes, that is a good article. I just wanted to know how many copies have already been started so the code could avoid putting all the opwninf dialogs on top of each other. I will elect to not add that complexity and let the user deal with it.
Thanks for taking the time to reply.
Thanks for your time
|
|
|
|
|
If you want to be able to count instance hits, have a look at the shared memory option here.[^]
This article also shows some other techniques which I think fix some of the problems described in Joe Newcomer's article first referenced above. I have used the shared memory technique to inhibit multiple instances of a program as well as manage some common data in a program where I allow multiple instances.
[I have a lot of respect for the technical output of both of these authors.]
--
Harvey
|
|
|
|
|
Visual Studio 2008, Windows 7
I create the basic MFP application with Single or Multiple documents, then immediately compile and run it. Using the File -> Open option I can navigate to and open a file.
However, when looking through the code I do not recognize any variable that might be the handle to a file. How do I acces that file I just opened?
Thanks for your time
|
|
|
|
|
It's a while since I used MFC but I think the actual handle is held internally by the CDocument object. When you open the file the framework should call your OpenFile() method (I think that's its name) and you then load the data from the file using the CArchive object. The skeleton code should be there in your document class.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
A search for OpenFile returned nothing. I looked around for CDocument and CArchive but did not recognize anything that looked like code to open a file.
Thanks for your time
|
|
|
|
|
I don't know where you were looking, but MSDN details CDocument::OnOpenDocument[^] and CArchive::Read[^] along with all the various other member functions of each class.
One of these days I'm going to think of a really clever signature.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
