Sprawdzanie listy proxy z ograniczoną współbieżnością

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

Użyj ograniczonej puli procesów roboczych zamiast uruchamiania osobnego zadania dla każdego punktu końcowego. Do sprawdzeń wobec dozwolonych celów publicznych darmowa lista proxy dostarcza wiersze kandydatów; zachowaj protokół każdego wpisu podczas budowania sondy. Ten fragment planowania .NET zakłada ProbeAsync świadome proxy i kolektor observations bezpieczny wątkowo. Osiem to granica poglądowa, a nie zmierzony optimum. Sonda nadal wymaga limitów na próbę i anulowania całego zadania.

Zachowuj każdy ukończony wynik razem z jego wejściem, nawet gdy kolejność ukończenia jest inna. Zapisuj protokół, punkt końcowy, cel, metodę, upływ czasu i wynik. Błąd połączenia, odrzucenie logowania do proxy, odrzucony CONNECT i otrzymana odpowiedź witryny to różne obserwacje.

Otwarty port TCP nie dowodzi negocjacji z proxy. Pobranie adresu proxy jako witryny również różni się od użycia go do żądania celu.

Wybierz cel i metodę stosownie do wymaganej możliwości. HEAD może oszczędzić ruch treści, ale nie dowodzi, że GET zwraca użyteczną treść; witryna może odrzucić jedno i pozwolić na drugie. HTTPS dodaje CONNECT i TLS celu, których brak w zwykłym HTTP. Adres wyjściowy to kolejna obserwacja po stronie celu, odrębna od skonfigurowanego wejścia.

Ograniczona praca chroni sprawdzający program przed wyczerpaniem własnych gniazd, pamięci lub harmonogramu, zanim oceni trasę. Wynik etapowy pozostaje użyteczny dla polityki wyboru bez udawania, że jeden udany cel czyni punkt końcowy uniwersalnie dobrym.