«

Hello

I have written my own C++ class to handle winsock. It uses an asynchronous
programming model so basically you ask for something and then when network
has info it gets sent to my class and I can deal with it. Basically, a user
class derives from this networking class and overrides functions such as
OnCompleteMessage.

Sometimes, however, it is more convenient for the user class if it can call
a function which then provides the response on returning. Should I provide
synchronous functions in my class? Or is this bad design? Instead should
user class just work in same asynchronous manner? Or is there a good way to
deal with this sync function requirement some other way?

I know all this sounds vague but I am really looking for general design
guidance. I am happy to provide more details on the class or the class
itself if that would be useful.

Angus

Angus wrote:
> Hello
>
> I have written my own C++ class to handle winsock. It uses an asynchronous
> programming model so basically you ask for something and then when network
> has info it gets sent to my class and I can deal with it. Basically, a user
> class derives from this networking class and overrides functions such as
> OnCompleteMessage.
>
> Sometimes, however, it is more convenient for the user class if it can call
> a function which then provides the response on returning. Should I provide
> synchronous functions in my class? Or is this bad design? Instead should
> user class just work in same asynchronous manner? Or is there a good way to
> deal with this sync function requirement some other way?
>
That question depends on too many external considerations to have a
single answer. Can the application do useful work while it is waiting
for an asynchronous request to be processed? If so, it might as well
use one. If not, it should use a synchronous request.

Is the application event driven, or does it use threads?

Provide both if you are unsure of the usage pattern.

--
Ian Collins.

In answer to your question, sometimes the application can do useful work
while we wait. And the application is event driven.

But if, for example, I need a response from the server to start processing
something - eg:

1. Request a string from server

2. When we have string, do some string processing on the string.

I need to wait for 1. to finish before I can start on 2. I need a sort of
WaitForResponse function? Is that the way to do it?

I have a function in the network class called OnCompleteMessage. But how do
I know that the completemessage I get from this function is the particular
one I asked for here. Do I send a request asking for some sort of
requestid? Then wait until receive event that requestid x has completed?

I am still hazy about how to best do all this.

Angus



"Ian Collins" <ian-> wrote in message
news:...
> Angus wrote:
> > Hello
> >
> > I have written my own C++ class to handle winsock. It uses an
asynchronous
> > programming model so basically you ask for something and then when
network
> > has info it gets sent to my class and I can deal with it. Basically, a
user
> > class derives from this networking class and overrides functions such as
> > OnCompleteMessage.
> >
> > Sometimes, however, it is more convenient for the user class if it can
call
> > a function which then provides the response on returning. Should I
provide
> > synchronous functions in my class? Or is this bad design? Instead
should
> > user class just work in same asynchronous manner? Or is there a good
way to
> > deal with this sync function requirement some other way?
> >
> That question depends on too many external considerations to have a
> single answer. Can the application do useful work while it is waiting
> for an asynchronous request to be processed? If so, it might as well
> use one. If not, it should use a synchronous request.
>
> Is the application event driven, or does it use threads?
>
> Provide both if you are unsure of the usage pattern.
>
> --
> Ian Collins.

Angus wrote:

Please don't top post.

> "Ian Collins" <ian-> wrote in message
>>
>>That question depends on too many external considerations to have a
>>single answer. Can the application do useful work while it is waiting
>>for an asynchronous request to be processed? If so, it might as well
>>use one. If not, it should use a synchronous request.
>>
>>Is the application event driven, or does it use threads?
>>
>>Provide both if you are unsure of the usage pattern.
>>
> In answer to your question, sometimes the application can do useful work
> while we wait. And the application is event driven.
>
> But if, for example, I need a response from the server to start processing
> something - eg:
>
> 1. Request a string from server
>
> 2. When we have string, do some string processing on the string.
>
> I need to wait for 1. to finish before I can start on 2. I need a sort of
> WaitForResponse function? Is that the way to do it?
>
Fairly typical situation where you have to block. You can do this with
an async only interface, but it's clearer and safer to use a sync call.

> I have a function in the network class called OnCompleteMessage. But how do
> I know that the completemessage I get from this function is the particular
> one I asked for here. Do I send a request asking for some sort of
> requestid? Then wait until receive event that requestid x has completed?
>
> I am still hazy about how to best do all this.
>
Sounds like you have a long way to go. Restrict yourself to one
outstanding message, get that working then tackle the reply/response
matching issues.

--
Ian Collins.