[Boost-users] Socket iostream Question

Subject: [Boost-users] Socket iostream Question
From: Anthrope (pn_at_[hidden])
Date: 2009-03-31 13:33:45

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.