[Boost-users] Asio SSL & short read error

Subject: [Boost-users] Asio SSL & short read error
From: Jason Nye (jnye_at_[hidden])
Date: 2012-04-05 18:34:09

Hi all,

I've run into a strange problem with reading data using an SSL socket stream (client-side). The code we've got essentially does the following on each read:

system::error_code ec;
auto result = _source->read_some(buffer(buf, n), ec);  // buf and n are defined as char* and size_t.

// here is where the occasional strangeness occurs.

I understand that during any streaming operation may return fewer bytes than requested - this is something we handle gracefully. However occasionally after read_some() above, we may get 0 bytes read and ec set to an internal ssl error code indicating a "short read".  My understanding is that this particular error is benign and the software should just continue to try reading. In fact, when I change our code to deal with this error specifically and just continue reading, everything works nicely.

The part I don't feel comfortable with is that it doesn't seem clear at all how to differentiate this particular error from a potentially fatal error other than comparing the error code's lower 8 bits against SSL_R_SHORT_READ (which I found by browsing the asio code and it is an OpenSSL constant). There doesn't seem to be any publicly facing constant that helps determine this situation.

Here is the basic logic for how we handle this specifically (which I do not like at all because it puts SSL-specific error handling logic where it doesn't belong):

// Loosely C++ code:
if (result == 0)
{
    if (EOF)
    {
        // Okay, end of the stream
    }
    else if (ec)
    {
        if ((ec.value() & 0xff) == SSL_R_SHORT_READ)
        {
            // Not a big deal - just retry the operation.
        }
        else
        {
            // Throw!
        }
    }
}

One other thing of interest is that the client-side code is using asio in a rather synchronous manner. I am not sure if this problem arises when using asio asynchronously.

Is this the only way to handle this situation reliably? Did I miss something obvious?

Thanks in advance,
Jason.

______________________________________________________________________________________________

[cid:image003.png_at_01CD1352.4ED8A7C0]

Jason Nye  |  Principal Software Engineer
5850 Opus Parkway, Suite 300  l  Minnetonka, MN  55343
952.487.9693 l  866.433.4624    l  www.vitalimages.com<http://www.vitalimages.com/>

A Toshiba Medical Systems Group Company

______________________________________________________________________________________________