Hello all, I am developing a high-performance socket-based application using the boost asio library. The application implements a binary tcp-based protocol that a bi-directional exchange of fixed-size messages. To simplify the coding while not sacrificing flexibility or performance, I decided to use the TCP iostream classes. The approach seems to work well, and I like the fact that the streams are buffered and allow me control over when I flush them. There's one minor issue that I thought I would seek some guidance on: Diagnosing and reporting failures connecting to servers are problematic. Basically, if a connect fails, the only way to know about it is to check the fail bit of the iostream. It would be nice to know why a client is unable to connect. So, to that end, I thought I could construct the iostream object via the default constructor, grab its streambuf via the rdbuf() call and in turn grab a basic_socket object reference to the streambuf and then call connect() on it, i.e., tcp::iostream iStream ; boost::asio::basic_socket_streambuf<tcp>& buf(*(iStream.rdbuf())); boost::asio::basic_socket<tcp, stream_socket_service<tcp> >& mySock(buf) ; mySock.connect(endPoint, error) ; The call to connect() on mySock with the error_code argument enables me to the diagnose and report connection problems a bit better. Once the connection is established, we can resume using the iostream directly. I would like to hear from you as to whether this approach makes sense, and what the pitfalls might be. And, alternative approaches would be most welcome too! Thanks in advance, Prashanth Nandavanam -- View this message in context: http://www.nabble.com/Socket-iostream-Question-tp22805249p22805249.html Sent from the Boost - Users mailing list archive at Nabble.com.