Detect aborted connection during ASIO request

Question

Is there an established way to determine whether the other end of a TCP connection is closed in the asio framework without sending any data?

Using Boost.asio for a server process, if the client times out or otherwise disconnects before the server has responded to a request, the server doesn't find this out until it has finished the request and generated a response to send, when the send immediately generates a connection-aborted error.

For some long-running requests, this can lead to clients canceling and retrying over and over, piling up many instances of the same request running in parallel, making them take even longer and "snowballing" into an avalanche that makes the server unusable. Essentially hitting F5 over and over is a denial-of-service attack.

Unfortunately I can't start sending a response until the request is complete, so "streaming" the result out is not an option, I need to be able to check at key points during the request processing and stop that processing if the client has given up.

Answer 1

If the connection has went through an orderly shutdown, i.e. the client called close or shutdown on the socket, then you can do a non-blocking one byte read from the socket to determine if it's still connected:

int ret = recv(sockfd, buf, 1, MSG_DONTWAIT | MSG_PEEK);

1. If it's connected but there's no data in the buffer you'll get a return of -1 with errno == EAGAIN
2. If it's connected and there's data you'll get back 1, and the MSG_PEEK flag will leave the data in the socket buffer.
3. otherwise ret will equal 0 indicating a graceful shutdown of the connection.

Now this technique isn't full proof, but it's work a significant portion of the time, as long as the FIN packet from the client has arrived.

You should be able to adapt this for use with Boost.Asio as long as it lets you pass socket flags to it's recv function.

Answer 2

The key to this problem is to avoid doing request processing in the receive handler. Previously, I was doing something like this:

async_receive(..., recv_handler)

void recv_handler(error) {
    if (!error) {
        parse input
        process input
        async_send(response, ...)

Instead, the appropriate pattern is more like this:

async_receive(..., recv_handler)

void async_recv(error) {
    if (error) {
        canceled_flag = true;
    } else {
        // start a processing event
        if (request_in_progress) {
            capture input from input buffer
            io_service.post(process_input)
        }
        // post another read request
        async_receive(..., recv_handler)
    }
}

void process_input() {
    while (!done && !canceled_flag) {
        process input
    }
    async_send(response, ...)
}

Obviously I have left out lots of detail, but the important part is to post the processing as a separate "event" in the io_service thread pool so that an additional receive can be run concurrently. This allows the "connection aborted" message to be received while processing is in progress. Be aware, however, that this means two threads must necessarily communicate with each other requiring some kind of synchronization and the input that's being processed must be kept separately from the input buffer into which the receive call is being placed, since more data may arrive due to the additional read call.