0

I'm coding multiple servers who have to listen from multiple clients and process the data asynchronously.

I did a Server base class, that i derive for adding the packethandling functions, as well as some notifiers that i call from my session class.

    void TcpSession::handle_read(const boost::system::error_code& e, std::size_t bytes_transferred)
{
    if (!e)
    {
        if (bytes_transferred < 4 || bytes_transferred >= 65535)
            return;

        ptrServer->NotifyPacketReceive(this, *(MPacketBody*)&buffer_);

        socket_.async_read_some(boost::asio::buffer(buffer_),
            strand_.wrap(boost::bind(&TcpSession::handle_read, shared_from_this(),
            boost::asio::placeholders::error,
            boost::asio::placeholders::bytes_transferred)));
    }
}

My NotifyPacketReceive is in the derived class, it will check for one identifier of the packet and will process the data. All of the functions executed after contains a packet to send, i do it like that

    void DerivatedServerClass::Request(TcpSession* session, MPacketBody packet)
// called from DerivatedServerClass::NotifyPacketReceive
    {    
    MOutPacket response(12);
        // fill response with data
        session->send(response);
    }

        void TcpSession::send(MOutPacket p)
        {
            boost::asio::async_write(socket_, boost::asio::buffer(p.packet(), p.size()),
                strand_.wrap(boost::bind(&TcpSession::handle_write, shared_from_this(),
                boost::asio::placeholders::error)));
        }

Problem is that my write function seems to "collapse" with async_write from others sessions, resulting the response is not sent and my client is in infinite waiting state. I tried to apply the "strand"/thread pool like in the HTTP Server 3 Example from Asio documentation, but nothing changed at all.

I also tried the example from here with the Outbox : boost asio async_write : how to not interleaving async_write calls?

Same problem, so i guess it comes from somewhere else. The buffer must remains intact, but my MOutPacket is allocated "on the stack", should i make a pointer to the MOutPacket then call "delete pointer;" after sent the packet ? Is that even possible, and if so, will this not cause problems ?

I don't really know what to do, does anyone got an idea ? Thanks

Community
  • 1
  • 1
Tim ROBA
  • 1
  • 1
  • What is `MOutPacket p`? How long does the return value of `p.packet()` live? – Igor R. Sep 02 '13 at 11:36
  • MOutPacket is a class, it's called on the stack and directly sent to the send function of my session, but since async_send return immediatly, i guess it is destroyed directly after. What could i do to avoid that ? – Tim ROBA Sep 02 '13 at 13:59
  • Your buffer should live at least as long as the async operation. Note that `buffer` function doesn't copy its argument but just adapts its type to `ConstBufferSequence` concept. So, re-design the way you manage this buffer. – Igor R. Sep 02 '13 at 20:14
  • Here is what i did now : In send() function, i create a pointer that copies the MOutPacket as parameter, then in my bind to handle_write, i put the same pointer, so i can clear it at the end of the async operation. Yet, there is a problem at handle_read() now, should i create also a pointer to a copy of the read_buffer for my post-receive operations ? Cause it seems to have a problem. – Tim ROBA Sep 02 '13 at 21:19
  • *All* the buffers should outlive their async operations. But your read `buffer_` looks like an object member, so it lives as long as the object does. What problem do you have with it? – Igor R. Sep 03 '13 at 05:27
  • When multiple requests comes from different clients at the same time, the server will ignore the reading of some clients, resulting in a client infinite waiting. I don't know where that comes from. – Tim ROBA Sep 03 '13 at 06:13
  • 1
    I see. This issue seems to be unrelated to the code you posted - perhaps the problem is in some other place. Ensure that you always chain `async_read`/`read_handler` correctly, put some message when `handle_error` receives error. – Igor R. Sep 03 '13 at 07:49

0 Answers0