بررسی فهرست پروکسی با هم‌روندی محدود

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

به‌جای اجرای یک وظیفه برای هر نقطه پایانی، از یک استخر کارگر محدود استفاده کنید. برای بررسی‌های روی هدف‌های عمومی مجاز، فهرست رایگان پروکسی سطرهای کاندید را فراهم می‌کند؛ هنگام ساختن کاوشگر، پروتکل هر ورودی را حفظ کنید. این قطعه زمان‌بندی .NET فرض می‌کند ProbeAsync از پروکسی آگاه است و گردآورنده observations برای ریسه‌ها ایمن است. عدد هشت یک کران نمونه است، نه بهینه اندازه‌گیری‌شده. کاوشگر هنوز به محدودیت هر تلاش و لغو کل کار نیاز دارد.

هر نتیجه کامل‌شده را همراه با ورودی‌اش نگه دارید، حتی اگر ترتیب تکمیل متفاوت باشد. پروتکل، نقطه پایانی، هدف، روش، زمان سپری‌شده و نتیجه را ثبت کنید. شکست اتصال، رد ورود به پروکسی، رد شدن CONNECT و پاسخ دریافتی از وب‌سایت، مشاهده‌های متفاوتی هستند.

باز شدن یک درگاه TCP، مذاکره با پروکسی را اثبات نمی‌کند. واکشی نشانی پروکسی به‌عنوان یک وب‌سایت هم با استفاده از آن برای درخواست هدف متفاوت است.

هدف و روش را بر اساس توانایی موردنیاز انتخاب کنید. HEAD می‌تواند ترافیک بدنه را کم کند، اما اثبات نمی‌کند که GET محتوای مفیدی برمی‌گرداند؛ یک سایت می‌تواند یکی را رد و دیگری را بپذیرد. HTTPS، CONNECT و TLS مقصد را اضافه می‌کند که در HTTP ساده نیست. نشانی خروجی مشاهده‌ای دیگر از سمت مقصد است، جدا از ورودی پیکربندی‌شده.

کار محدود مانع می‌شود بررسی‌کننده پیش از ارزیابی مسیر، سوکت‌ها، حافظه یا زمان‌بند خود را تمام کند. نتیجه مرحله‌ای برای سیاست انتخاب سودمند می‌ماند، بدون آنکه چنین القا کند یک مقصد موفق، نقطه پایانی را در همه حال خوب می‌کند.