ASIO ssl::stream read/write_some question.
Could someone please shed some light on ASIO SSL reads and writes for me? The names of the read and write functions for the ssl::stream (read_some and write_some) imply to me that the buffer(s) may not be completely filled/sent with a read/write. Do I need to have some intermediate handler that will begin another async_read/write_some until my buffer is filled/flushed? The documentation doesn't seem to indicate that this is necessary. It makes sense from the example that the reads may not fill the provided buffer before invoking the handler. So it may be necessary to call read_some multiple times until the expected number of bytes is received. But is this also the case with writes, and if so, how do I manage multiple writes if I provide a vector of buffers to be written with and async_write_some? Thanks in advance. Derrick
Derrick Hathaway wrote:
Could someone please shed some light on ASIO SSL reads and writes for me? The names of the read and write functions for the ssl::stream (read_some and write_some) imply to me that the buffer(s) may not be completely filled/sent with a read/write. Do I need to have some intermediate handler that will begin another async_read/write_some until my buffer is filled/flushed? The documentation doesn't seem to indicate that this is necessary. It makes sense from the example that the reads may not fill the provided buffer before invoking the handler. So it may be necessary to call read_some multiple times until the expected number of bytes is received. But is this also the case with writes, and if so, how do I manage multiple writes if I provide a vector of buffers to be written with and async_write_some? I have no authority to give a definite answer, but my experience with it indicates that what you assume is indeed right. All read_some/write_some methods may read or write fewer bytes than requested, and you need to check the num_transferred placeholder and invoke read_some/write_some again as necessary.
I remember seeing an adapter method that does this for you in some other class, but I forgot exactly where it is (didn't need/want to use it in my program). Cheers, Eugene
On 2/26/08, Eugene M. Kim
Derrick Hathaway wrote:
Could someone please shed some light on ASIO SSL reads and writes for me? The names of the read and write functions for the ssl::stream (read_some and write_some) imply to me that the buffer(s) may not be completely filled/sent with a read/write. Do I need to have some intermediate handler that will begin another async_read/write_some until my buffer is filled/flushed? The documentation doesn't seem to indicate that this is necessary. It makes sense from the example that the reads may not fill the provided buffer before invoking the handler. So it may be necessary to call read_some multiple times until the expected number of bytes is received. But is this also the case with writes, and if so, how do I manage multiple writes if I provide a vector of buffers to be written with and async_write_some?
I have no authority to give a definite answer, but my experience with it indicates that what you assume is indeed right. All read_some/write_some methods may read or write fewer bytes than requested, and you need to check the num_transferred placeholder and invoke read_some/write_some again as necessary.
I remember seeing an adapter method that does this for you in some other class, but I forgot exactly where it is (didn't need/want to use it in my program).
Cheers,
Eugene
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Thanks for your reply, Eugene. I guess I just didn't read the documentation and or experiment enough. I naively assumed that it had to be done the way the example SSL code does it (by calling ssl socket's async_read/write_some methods). I didn't know that boost::asio::async_read/write could be called with an ssl_stream, which according to documentation will read or write until an error occurs or the provided buffer(s) are filled/written. Derrick
participants (2)
-
Derrick Hathaway -
Eugene M. Kim