tags:

views:

74

answers:

4

Hi all

I have a dll written in C. I would like to send data to a socket and receive the answer in the same function.
e.g.:

BOOL SendToSocketAndRecv(...)  
{  
   // ...
   send(...);  
   retval = recv(...);  
   // ...
}  

In another word, my dll should not follow Client Server pattren.

Is this possible ?
any help ?
Thank you - Khayralla

A: 

Yes this is both possible and legal. The API itself isn't concerned about being used from the same function.

JaredPar
any other considerations ?
Khayralla
+1  A: 
  1. Yes
  2. You may work in either blocking (synchronous) or non-blocking (asynchronous) mode. Depending on this you may or may not send more data before you receive something from the peer.
  3. "Stream" sockets (like TCP) are "tunnels". If the peer sends several packets you may receive them in a single call to recv, and vice-versa - a sinle "message" from the peer may take several calls to recv. Hence you should read the message in a loop.
  4. You have a lot to learn about network programming.
valdo
Is there any web site explaning this Scenario ?
Khayralla
according to third point, if I use a loop to read all messages, then this wouldn't be a send and receive basis ? and may block the execution.
Khayralla
I meant - you may need to read in a loop to read a **single** message.
valdo
A: 

not only is this possible, it is a classic coding idiom for a client in a client server system. Usually the function is called something like ExecuteRequest

pm100
A: 

I am sending a commands to Robot and then wait to get answer

Yes, what you have will work.

But things start to get interesting when you factor in the chance that the robot will not respond for whatever reason. Then you need to provide for a timeout on the response. Soon other things start to creep in. For example, you may not want to be stuck in the read for the duration of the wait, because you may need to service other events (user input or other sources) as they comes in.

A common architecture to handle this is to use select() and make it the hub of all your incoming events. Then you drive a state machine (or machines) off these events. You end up with an event driven architecture. It would look something like this:

while(true)
{
    select(fds for event sources, timeout);

    if (timeout)
    {
        call robot state machine(timeout);
        continue;
    }

    iterate through fds
    {
        if (fd has data)
        {
            read data into buf

            if (fd is for robot)
            {
                call robot state machine(buf)
            }
            else if (fd is for source1)
            {
                call source1 state machine(buf)
            }
            ...
        }
    }
}

In this model, sends can be done from anywhere in the code. But you wind up sitting in the select() after, waiting for events. Also, you will have to figure out the details of doing the correct timeout and select in general, but there is enough of that out there.

Ziffusion
Thank you Ziffusion, this is a good help.
Khayralla