views:

119

answers:

1

I have a C++ boost client that does a blocking connect and processes the message once it receives a response. I am facing a strange issue.

tcp::resolver::query query(tcp::v6(), this->host, port,tcp::resolver::query::v4_mapped);
iterator = resolver.resolve(query);
socket = new tcp::socket(io_service);
socket->connect(*iterator);

I tried to connect to a machine that was not reachable by ping6 (but was IPV6 enabled). Still, I didn't get any error while trying to resolve the query in line-2. As a result of this, it takes too much time while attempting a connection before giving an error. My questions:-

1) Is it possible to timeout on a blocking connect from asio? I cannot switch to async mode of operation.

2) How come I don't get an error while it resolves an unreachable host?

Any advice would be very much helpful

A: 

Timeouts are the wrong place for synchronous methods, there's a lengthy discussion in the asio ticket tracker.

I cannot switch to async mode of operation.

I find this highly unlikely given the timeout requirement, post the rest of your code and explain why you cannot use asynchronous operations.

Sam Miller
@Sam..Thanks for a quick response. Actually, timeout is not a requirement. The main issue is that I get an iterator without error while querying for an unreachable host. As a result, the socket takes about 5 minutes(blocking) before giving an error"A socket operation was attempted to an unreachable host"
confused
Oh and I forgot to add that I see this behavior when specifying hostname in an IPV6 format.
confused
Check the validity of the tcp::resolver::iterator after your resolve call by comparing it to a default constructed iterator.
Sam Miller
@Sam..I tried to compare it this way:- tcp::resolver::iterator defaultEnd;boost::system::error_code ec;iterator = resolver.resolve(query,ec);if (iterator == defaultEnd){ wcerr << L"V6 successful without errorcode, but possible unknown host" << endl; return;}So, I compared the resolved iterator with default constructed one. I assume this is the correct way of comparison. But, it didn't succeed. I still get a "valid" iterator, that fails when used in a socket.
confused
if you get a valid resolver::iterator then I suggest using async_connect with a timer if you don't like the synchronous connect behavior.
Sam Miller