5

I'm having a hard time understand the correct way I should structure a tcp client when using async_read and async_write. The examples seem to do a async_read after connecting and then have async_write in the handler.

In the case of my client and sever, when the client connects it needs to check a queue of messages to write and check to see if anything needs to be read. One of the things I'm having a hard time with is understanding how this would work asynchronously.

What I envision is in the async_connect handler, the thread would call async_write if anything is in the sendQueue and call async_read over and over. Or should it check if anything is available to be read before it does an async_read? Below is an example of what I'm talking about.

void BoostTCPConnection::connectHandler()
{
    setRunning(true);
    while (isRunning())
    {
        //If send Queue has messages
        if ( sendSize > 0)
        {
            //Calls to async_write
            send();
        }

        boost::shared_ptr<std::vector<char> > sizeBuffer(new std::vector<char>(4));
        boost::asio::async_read(socket_, boost::asio::buffer(data, size), boost::bind(&BoostTCPConnection::handleReceive, shared_from_this(), boost::asio::placeholders::error, sizeBuffer));

   }    
}

void BoostTCPConnection::handleReceive(const boost::system::error_code& error, boost::shared_ptr<std::vector<char> > sizeBuffer)
{

    if (error)
    {
        //Handle Error
        return;
    }

    size_t messageSize(0);
    memcpy((void*)(&messageSize),(void*)sizeBuffer.data(),4);

    boost::shared_ptr<std::vector<char> > message(new std::vector<char>(messageSize) );

    //Will this create a race condition with other reads?
    //Should a regular read happen here
    boost::asio::async_read(socket_, boost::asio::buffer(data, size), 
                    boost::bind(&BoostTCPConnection::handleReceiveMessage, shared_from_this(),
                    boost::asio::placeholders::error, message));

}

void BoostTCPConnection::handleReceiveMessage(const boost::system::error_code& error, boost::shared_ptr<std::vector<char> > rcvBuffer)
{
    if (error)
    {
        //Handle Error
        return;
    }

    boost::shared_ptr<std::string> message(new std::string(rcvBuffer.begin(),rcvBuffer.end())); 
    receivedMsgs_.push_back(message);
}

void BoostTCPConnection::handleWrite(const boost::system::error_code& error,size_t bytes_transferred)
{
    //Success
    if (error.value() == 0) 
        return;
    //else handleError


}
Mike Pennington
  • 41,899
  • 19
  • 136
  • 174
Thomas Lann
  • 1,124
  • 5
  • 17
  • 35

1 Answers1

6

Conceptually, async_read waits for data to be received. You should call it any time you want something to happen after data is received and a read isn't already pending. Similarly, async_write waits for data to be written. You should call it any time you need to write data and a write isn't already pending.

You should call async_read when you complete the connection. Before your async_read handler returns, it should probably call async_read again.

When you need to write to the connection, you should call async_write (if a write isn't already pending). In your async_write handler, if you still need to write more, you should call async_write again.

If no read is already pending, you can call async_read in your write handler, if you wish to resume reading after you finish writing. You can also just keep a read always pending. That's up to you.

You should not check if there's anything to read before calling async_read. The point of async_read is for it to complete when there's something to read. It's a smart way of waiting and doing other things in the meantime.

David Schwartz
  • 179,497
  • 17
  • 214
  • 278
  • @DavidSchwartz I'm having a hard time organizing the code. One reason is, a read or a write might need to be done at anytime. In a synchronous version of this I would just use a loop and check if any of it needed to be done and do it. I guess I'm having a hard time thinking asynchronously. – Thomas Lann Nov 09 '12 at 23:23
  • 1
    Well, read is easy. Call `async_read` when you complete the connection and then call it again before your read handler returns. Write is a bit more complex, but you can call it any time two things are the case: 1) You have data you want to write. 2) You don't have an async write already pending. – David Schwartz Nov 09 '12 at 23:26
  • @DavidSchwartz Thanks. I pretty much have async_read down. But calling async_write has me. Should I have a loop in the connect handler that sends if data is available and and an async_write isn't pending? Could I just use a strand to serialize writes to async_write? – Thomas Lann Nov 09 '12 at 23:54
  • 1
    If you have data to send, call `async_send` unless a send is already pending. In your send handler, call `async_send` again, unless you have nothing left to send. If you have your own send queue, you can make a "put message on send queue" function that does all this for you. – David Schwartz Nov 10 '12 at 00:34
  • @DavidSchwartz What if I don't have anything to send at that moment, but I will probably have it later. Wouldn't this neccesitate some sort of loop that checks the send queue? – Thomas Lann Nov 10 '12 at 04:02
  • 1
    @ThomasLann: For asynchronous programming, it may help to think of the functions as being chained together instead of a loop. [This](http://stackoverflow.com/questions/7754695/#7756894) answer shows how to implement a basic writer queue, maintain thread safety with a strand, and conditional start an asynchronous write call chain. The basic pattern remains the same, even for solutions with slightly more complex requirements, such those that do not copy the write buffer and propagate the handler callbacks. – Tanner Sansbury Nov 12 '12 at 16:07
  • 1
    @ThomasLann: You don't need a loop that checks the send queue. You need a function that puts something on the send queue and calls `async_write` if a write isn't already pending. – David Schwartz Nov 12 '12 at 17:39
  • @DavidSchwartz What outgoing messages weren't constant? This could cause some messages to be delayed for an indeterminate amount of time. – Thomas Lann Nov 12 '12 at 20:42
  • 1
    @ThomasLann How would it cause any messages to ever get delayed? You're always in either one of two states: 1) You have an empty send queue. 2) You have a write pending. -- Any time you put a message on an empty send queue and a write isn't pending, you call `async_send`. – David Schwartz Nov 12 '12 at 20:53
  • @twsansbury Thanks. That example fills in the mental hole I have. I now understand how to do this. Thank you a bunch. – Thomas Lann Nov 12 '12 at 21:03