2012-06-12 11 views
5

Ho un riproduttore in scatola che invoca boost::asio::ip::tcp::resolver::resolve() su localhost una volta ogni 5 secondi. Conta il numero di endpoint restituiti e confronta tale valore con l'iterazione precedente.risultati da Boost.Asio resolver differ

#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); 
    } 
} 

sessione campione

~> 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 
~> 

Si può vedere ha trovato un endpoint (127.0.0.1:80) per circa 3,5 ore, poi trovato due (127.0.0.1:80 e [:: 1] : 80). Mi chiedo

  1. perché il conteggio degli endpoint cambia da uno a due?
  2. cosa potrebbe causarlo?

La risoluzione di entrambi gli indirizzi IPv4 e IPv6 è intenzionale, non voglio limitare la query solo a ipv4. Mi rendo conto che questo comportamento probabilmente non è specifico di asio, ho anche un riproduttore che invoca direttamente lo getaddrinfo che presenta lo stesso comportamento. La mia piattaforma è ppc64 RHEL 6.2 se ciò è rilevante. Non ho provato a riprodurre altrove.

+0

L'indirizzo ':: 1' è l'indirizzo IPv6 localhost. Forse ci vuole così tanto tempo affinché il sistema operativo capisca che è abilitato IPv6? –

+0

qual è il sistema operativo su cui stai lavorando? – gda2004

+0

@ gda2004 vedere l'ultima frase della domanda, ppc64 RHEL 6.2 –

risposta

3

È possibile limitare resolver a solo IPv4:
ip :: tcp :: :: resolver query (ip :: tcp :: v4(), di accoglienza, di servizio)

+1

AFAIU la domanda non è come limitare gli indirizzi restituiti da getaddrinfo, ma perché l'indirizzo IPv6 compare dopo un certo periodo di tempo è trascorso. – Ralf

+0

Bene, ho avuto l'impressione che l'argomento starter non fosse a conoscenza del fatto che la sua query resolver conteneva sia ipv4 che ipv6, così ha ottenuto * query ipogee * indesiderate *. D'altra parte, è risaputo che le query DNS di ipv6 potrebbero essere dolorosamente lente ... –

+0

@IgorR. Sono consapevole che l'indirizzo ':: 1' è' ipv6-localhost', ho modificato la mia domanda per riflettere questo. Non voglio limitare le mie query di risoluzione solo a ipv4. –

1

Beh, io non sono un esperto spinta , ma una rapida navigazione mi dice che sembra che stia usando AI_ADDRCONFIG per impostazione predefinita (il che è buono, dovrebbe essere quasi sempre usato). Con questo flag verranno restituiti solo gli indirizzi IPv6 se è configurato almeno un indirizzo IPv6 instradabile globale. Forse la tua connessione IPv6 non è sempre disponibile?

+0

** Avvertenza specifica per Windows: ** AI_ADDRCONFIG può causare problemi di localhost. Vedi [Boost ticket 8503] (https://svn.boost.org/trac/boost/ticket/8503) per i dettagli. –

Problemi correlati