Resumo

  • Nas fontes examinadas de RIPE Atlas Tools, o ajuste HTTP de dez segundos chega ao geocodificador do Google, mas não à criação de medições Atlas por meio de Cousteau.
  • Um teste local com os valores 3, 10 e 30 confirmou essa fronteira sem rede, chaves, medições ou gasto de créditos. O resultado não comprova uma falha real nem descreve todas as instalações.

Antes de repetir, saber o que terminou

Encerrar um cliente e descobrir o resultado do pedido que ele enviou são tarefas diferentes. Essa distinção importa quando um operador automatiza medições. Em RIPE Atlas Tools, o ajuste http-timeout ajuda a controlar uma consulta de localização, mas não é transmitido ao caminho de criação de medições Atlas examinado nesta análise.

O histórico oficial data a versão 3.4.0 de 3 de junho de 2026 e apresenta o tempo limite HTTP configurável, com padrão de dez segundos, entre suas mudanças. A apuração de setembro examina esse trabalho já publicado. Não se trata de uma versão lançada agora.

O valor existe na configuração e tem um consumidor concreto. Na busca de sondas, a função que converte uma localização em coordenadas entrega o ajuste a Requests na consulta ao Google e trata exceções de tempo limite. Nesse trecho, a regra chega à chamada que deve executá-la.

O pedido para criar uma medição segue outro caminho. A ferramenta monta AtlasCreateRequest com servidor da API, chave de autorização, identificação do cliente, definições de medição, seleção de sondas e indicador de execução única. Não acrescenta o ajuste HTTP.

Na fonte verificada de Cousteau 2.3.0, a classe herda de AtlasRequest. A classe comum organiza parâmetros, cabeçalhos, verificação TLS e proxies; o POST acrescenta o corpo JSON. Ao final, Requests recebe esse conjunto sem parâmetro de tempo limite. A configuração do programa de linha de comando não passa a valer no SDK apenas porque ambos pertencem ao mesmo ambiente institucional.

Capturar argumentos, não criar trabalhos

Para testar essa passagem, foram extraídos da estrutura sintática das fontes fixadas os métodos reais de criação e geocodificação, além das classes de requisição e criação do SDK. A execução foi local. Definições, fontes de sondas e respostas de transporte eram objetos de teste; as funções de transporte apenas registravam argumentos.

Com o ajuste em 3, 10 e 30, a consulta geográfica recebeu exatamente 3, 10 e 30. Nos três POST destinados a Atlas, o dicionário capturado não continha tempo limite. Não havia função de conexão disponível ao código extraído. Nenhuma chave foi usada, nenhuma medição ou tarefa remota foi criada e nenhum crédito foi consumido.

O teste verifica a propagação de um valor nessas classes e métodos. Não executa toda a aplicação instalada, não integra todos os módulos e não interroga os servidores. Também não mede latência. Portanto, não demonstra que um operador ficou esperando trinta segundos nem que Atlas sofreu uma interrupção.

Essa diferença deve permanecer visível no relato. Uma omissão no argumento é evidência sobre o caminho do cliente. O que ela provoca em uma instalação depende de versões resolvidas, alterações locais e controles externos que esta investigação não inventariou.

O relógio da conexão não é o da campanha

A documentação de Requests diz que, sem um tempo limite explícito, suas chamadas não têm um tempo limite especificado. Mas esclarece também que o valor fornecido não limita a duração total do download da resposta. A regra de espera de uma conexão e o orçamento total de uma tarefa não são intercambiáveis.

Mesmo a consulta ao Google não promete terminar exatamente dez segundos depois de iniciar o comando. Da mesma forma, a falta do parâmetro no caminho Atlas não obriga toda instalação a esperar para sempre. Sistema operacional, conexão, proxy ou supervisão externa podem encerrar a espera. Não auditamos essas regras.

O tempo de espera de uma API tampouco mede a velocidade das sondas. O prazo de um pacote de medição e o período de escuta dos resultados são outros controles. Uma resposta tardia à criação pode dizer algo sobre a comunicação com a API, não sobre o desempenho do caminho de rede que se pretendia medir.

Deixar o resultado desconhecido como desconhecido

Considere a hipótese de um servidor aceitar a criação e a resposta se perder. Matar o processo local não prova que o trabalho remoto foi recusado. Essa hipótese não aconteceu no teste, que não fez conexão alguma.

Antes de decidir por outro envio, o operador precisa conferir um registro remoto ao qual tenha acesso autorizado ou conservar o resultado explicitamente como desconhecido. O limite local não certifica uma rejeição do servidor; parar o cliente não equivale automaticamente a cancelar a tarefa remota.

Uma descrição operacional útil separaria a consulta geográfica, a chamada Atlas do SDK e o prazo global da automação. Para cada uma, indicaria a camada responsável e como verificar o resultado quando a espera termina. Não é necessário impor dez segundos a tudo. É necessário tornar inteligível onde o número atua.

Fontes