Verificar uma lista de proxies com concorrência limitada

var options = new ParallelOptions
{
    MaxDegreeOfParallelism = 8,
    CancellationToken = cancellationToken
};
await Parallel.ForEachAsync(endpoints, options,
    async (endpoint, token) =>
    {
        var result = await ProbeAsync(endpoint, target, token);
        observations.Add(result);
    });

Use um conjunto limitado de trabalhadores em vez de lançar uma tarefa para cada ponto de extremidade. Para verificações contra destinos públicos permitidos, a lista gratuita de proxies fornece linhas candidatas; preserve o protocolo de cada entrada ao construir a sonda. Este fragmento de agendamento .NET pressupõe um ProbeAsync ciente do proxy e um coletor observations seguro para threads. Oito é um limite ilustrativo, não um ótimo medido. A sonda ainda precisa de limites por tentativa e de cancelamento de todo o trabalho.

Guarde cada resultado concluído junto com a sua entrada, mesmo quando a ordem de conclusão é diferente. Registe protocolo, ponto de extremidade, destino, método, tempo decorrido e desfecho. A falha de ligação, a recusa do início de sessão no proxy, um CONNECT negado e uma resposta recebida do site são observações diferentes.

A abertura de uma porta TCP não prova a negociação com o proxy. Obter o endereço do proxy como se fosse um site também difere de o usar para pedir o destino.

Escolha o destino e o método conforme a capacidade necessária. O HEAD pode poupar tráfego de corpo, mas não prova que o GET devolva conteúdo útil; um site pode recusar um e permitir o outro. O HTTPS acrescenta CONNECT e TLS de destino ausentes no HTTP simples. Um endereço de saída é outra observação do lado do destino, separada da entrada configurada.

O trabalho limitado impede que o verificador esgote os seus próprios sockets, memória ou escalonador antes de poder avaliar a rota. Um resultado por etapas continua útil para a política de seleção sem fingir que um destino bem-sucedido torna um ponto de extremidade universalmente bom.