resultados de Boost.Asio resolver differ

Question

Tengo un reproductor en lata invocando boost::asio::ip::tcp::resolver::resolve() en localhost una vez cada 5 segundos. Cuenta el número de puntos finales devueltos y compara ese valor con la iteración anterior.

#include <boost/asio.hpp> 

#include <iostream> 

int main(int argc, char *argv[]) 
{ 
    if (argc < 3) { 
     std::cerr << argv[0] << " host port" << std::endl; 
     exit(EXIT_FAILURE); 
    } 
    const char* host = argv[1]; 
    const char* service = argv[2]; 

    boost::asio::io_service io_service; 
    boost::asio::ip::tcp::resolver resolver(io_service); 

    size_t previous = 0; 
    while (true) { 
     boost::asio::ip::tcp::resolver::iterator i(
       resolver.resolve(
        boost::asio::ip::tcp::resolver::query(host, service) 
        ) 
       ); 
     size_t count(0); 
     while (i != boost::asio::ip::tcp::resolver::iterator()) { 
      std::cout << i->endpoint() << std::endl; 
      ++i; 
      ++count; 
     } 

     std::cout << "got " << count << " addresses" << std::endl; 
     if (previous == 0) { 
      previous = count; 
     } 
     assert(count == previous); 

     sleep(5); 
    } 
} 

sesión de ejemplo

~> time ./addrinfo_asio localhost 80 

... 

127.0.0.1:80 
got 1 addresses 
[::1]:80 
127.0.0.1:80 
got 2 addresses 
addrinfo_asio: addrinfo_asio.cc:35: int main(int, char**): Assertion `count == previous' failed. 
Aborted (core dumped) 

real 216m20.515s 
user 0m0.181s 
sys  0m0.193s 
~> 

Se puede ver que encontró un punto final (127.0.0.1:80) durante aproximadamente 3,5 horas, luego encontró dos (127.0.0.1:80 y [:: 1] : 80). Me pregunto

1. ¿por qué el conteo de puntos finales cambia de uno a dos?
2. ¿qué podría causarlo?

Resolviendo las direcciones ipv4 e ipv6 es intencional, no quiero limitar la consulta a solo ipv4. Me doy cuenta de que este comportamiento probablemente no es específico de asio, también tengo un reproductor que invoca directamente al getaddrinfo que muestra el mismo comportamiento. Mi plataforma es ppc64 RHEL 6.2 si eso es relevante. No he intentado reproducir en otro lugar.

Answer 1

Puede limitar a resolver sólo con IPv4:
ip tcp :: :: :: resolución de consulta (ip tcp :: :: v4(), el anfitrión, el servicio)

Answer 2

Bueno, yo soy un experto impulso , pero una búsqueda rápida me dice que parece estar usando AI_ADDRCONFIG de manera predeterminada (lo cual es bueno, casi siempre debería usarse). Con ese indicador, solo devolverá las direcciones IPv6 si tiene configurada al menos una dirección IPv6 enrutable global. Tal vez su conexión IPv6 no siempre esté disponible?