CODEWITHSUNDEEP
c++socketsboosttcp
Alex Young
Alex Young

Reputation: 75

calling boost::asio::tcp::socket methods after async_read handler returned an error in server

For log output i am calling tcp::socket::remote_endpoint() from a shared_ptr Session object when the Session is created and when it is destroyed. If an async_read is called and the client has sent a FIN before the server sends a reply and then an RST packet after the server has sent the reply (write doesn't return any errors), the async_read function returns error code system::54 (not_connected - with a message of "Connection reset by peer") and then when i call the remote_endpoint method again (in the Session object destructor) it throws a exception:

libc++abi.dylib: terminating with uncaught exception of type boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::system::system_error> >: remote_endpoint: Invalid argument

Does the async_read error invalidate the socket or is there another cause of this? I can't see anything in the boost::asio 1.59.0 docs.

I should probably add that this socket is the socket underlying a boost::asio::ssl::stream<tcp::socket&>

An example of the above occurs in this code:

void read() {
    auto self(shared_from_this());
    boost::asio::async_read(ssl_stream_, boost::asio::buffer(buffer_),
    [this, self](const boost::system::error_code &ec, std::size_t) {
        if (!ec) {
            processBuffer();
        } else {
            /* system:54 error occurs see here */
            std::cout << "read ec: " << ec << " " << ec.message() << std::endl;

            /* This will throw an exception (Invalid argument) */
            auto endpoint = socket_.remote_endpoint();
        }
    });
}

Upvotes: 1

Views: 1127

Answers (1)

sehe
sehe

Reputation: 392833

Is boost::asio::ssl::stream<tcp::socket&> correct? I think I've only ever seen boost::asio::ssl::stream<tcp::socket> before

Also

I should probably add that this socket is the socket underlying a boost::asio::ssl::stream

You should be async_read-ing from the stream (after handshake). If the stream is in an SSL session, reading/writing from it directly will cause the SSL session to fail, and it might be closed down.

Upvotes: 2

Related Questions