Caching the iterator of async_resolve()?
Hi everybody, Just to be on the safe side: I assume that I can cache the iterator returned by async_resolvehttp://www.boost.org/doc/libs/1_49_0/doc/html/boost_asio/reference/ip__basic...'s handler, correct? The fact that it's a forward iterator suggests so... Thanks! Kaspar
On 18/12/2013 11:44, Quoth Kaspar Fischer:
Just to be on the safe side: I assume that I can cache the iterator returned by async_resolve http://www.boost.org/doc/libs/1_49_0/doc/html/boost_asio/reference/ip__basic...'s handler, correct?
I'm not an expert, but I would be surprised if that were safe. You should probably iterate it and save the resulting objects from within your handler only.
The fact that it's a forward iterator suggests so...
I don't know why you think that follows. The iterator type just tells you what the interface is, not what the lifetime of the underlying collection is. In this case, it's possible that the collection has the same lifetime as the socket, or of the iterators (which would make caching it somewhat safe) but I would think it far more likely that it has the lifetime of the resolve operation itself instead (which would make caching it unsafe, as it would be deleted as soon as the handler returns).
Gavin, thanks for your answer.
So the way to go is to copy the values of the iterator and cache these,
that makes sense.
Have others had any experiences with this? I want to avoid making a DNS
lookup every time I perform a (HTTP) request.
Also – and not strictly related to this question – why are DNS lookups in
Boost Asio tied to a service, as in resolve(query(host, "http"))?
Thanks for any pointers, much appreciated.
Kaspar
On Tue, Dec 17, 2013 at 3:31 PM, Gavin Lambert
On 18/12/2013 11:44, Quoth Kaspar Fischer:
Just to be on the safe side: I assume that I can cache the iterator returned by async_resolve <http://www.boost.org/doc/libs/1_49_0/doc/html/boost_ asio/reference/ip__basic_resolver/async_resolve/overload1.html>'s handler, correct?
I'm not an expert, but I would be surprised if that were safe. You should probably iterate it and save the resulting objects from within your handler only.
The fact that it's a forward iterator suggests so...
I don't know why you think that follows. The iterator type just tells you what the interface is, not what the lifetime of the underlying collection is.
In this case, it's possible that the collection has the same lifetime as the socket, or of the iterators (which would make caching it somewhat safe) but I would think it far more likely that it has the lifetime of the resolve operation itself instead (which would make caching it unsafe, as it would be deleted as soon as the handler returns).
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On 18/12/2013 14:21, Quoth Kaspar Fischer:
Have others had any experiences with this? I want to avoid making a DNS lookup every time I perform a (HTTP) request.
Typically you should. The OS has its own cache of recently queried domains and the corresponding Time-To-Live value (ie. "how long this is valid for") provided by the actual DNS server, and larger networks will often have a secondary DNS cache on the LAN that also respects this. So a resolve doesn't always hit the Internet, but it's important to respect the TTL policy set by the target server to properly handle load balancing and dynamic addressing.
Also – and not strictly related to this question – why are DNS lookups in Boost Asio tied to a service, as in resolve(query(host,"http"))?
Because the underlying getaddrinfo expects a service name/port. I think it's just a convenience to obtain the port number at the same time as the hostname, assuming both were provided as strings, rather than having to make two separate calls to resolve each. Personally, I think it's better to use the actual numeric port instead of using a service name, unless you're obtaining the service name from user input (such as an URL) -- and even then typically a given app will only support specific service types anyway, so there isn't really much call for being able to look them up by name. Maybe there are historic reasons for it. (I know each client has a config file that contains the name->port mappings, but I can't think of any scenario in which editing this file to produce different results is useful.)
Thank you, Gavin, for the detailed explanations, helped me a lot.
I will follow your advice and not cache.
Best,
Kaspar
On Tue, Dec 17, 2013 at 6:42 PM, Gavin Lambert
On 18/12/2013 14:21, Quoth Kaspar Fischer:
Have others had any experiences with this? I want to avoid making a DNS
lookup every time I perform a (HTTP) request.
Typically you should. The OS has its own cache of recently queried domains and the corresponding Time-To-Live value (ie. "how long this is valid for") provided by the actual DNS server, and larger networks will often have a secondary DNS cache on the LAN that also respects this.
So a resolve doesn't always hit the Internet, but it's important to respect the TTL policy set by the target server to properly handle load balancing and dynamic addressing.
Also – and not strictly related to this question – why are DNS lookups
in Boost Asio tied to a service, as in resolve(query(host,"http"))?
Because the underlying getaddrinfo expects a service name/port. I think it's just a convenience to obtain the port number at the same time as the hostname, assuming both were provided as strings, rather than having to make two separate calls to resolve each.
Personally, I think it's better to use the actual numeric port instead of using a service name, unless you're obtaining the service name from user input (such as an URL) -- and even then typically a given app will only support specific service types anyway, so there isn't really much call for being able to look them up by name. Maybe there are historic reasons for it. (I know each client has a config file that contains the name->port mappings, but I can't think of any scenario in which editing this file to produce different results is useful.)
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (2)
-
Gavin Lambert -
Kaspar Fischer