Reputation: 1325
I'm trying to implement the following for arbitrary streams (with both read and write interfaces).
http://www.boost.org/doc/libs/1_39_0/doc/html/boost_asio/reference/AsyncReadStream.html
What I plan to do is to pass the stream to some client. The client async_writes to the stream and when there is no more data it then closes the stream.
The calling code async_reads from the stream until I assume that it gets some indication of the stream close state via the ReadHandler error_code. My questions are:
What will this error_code
be?
Can I guarantee to transmit all the data using this mechanism?
Is there a better way to do this?
Upvotes: 1
Views: 852
Reputation: 392979
The bottom line is: it depends on the implementation. If you want to abstract that interface away, I'd suggest abstracting the implementation details behind your own interface.
If you /want/ to expose the Asio interface (why?) then you could create a composed IO operation that translates all expectable errors to a common contract.
For specific implementations, a simple test would suffice of course.
For sockets, the usual error code is eof
(boost::asio::error::misc_errors::eof
). Depending on the circumstances boost::asio::error::basic_errors::connection_reset
or boost::asio::error::basic_errors::network_reset
could occur.
If the io_service
is halted, the service object is destructed or the socket is closed, boost::asio::error::basic_errors::operation_aborted
or boost::asio::error::basic_errors::bad_descriptor
could be expected.
All these are implementation dependent, of course. Different platforms may have different codes, different streams may have different codes.
Instead of error codes you could try to make sure the error condition maps onto the same "thing" so clients will have a consistent interface.
Upvotes: 3