انتخابهای تصادفی، گذرهای درهمشده و نقاط پایانی پروکسی تکراری
بهجای اینکه نقطه پایانی تکراری را یک چرخاننده خراب بدانید، بین انتخابهای تصادفی مستقل، یک گذر درهمشده و سیاستی بدون تکرار فوری یکی را برگزینید.
پروکسی B، دوباره پروکسی B، سپس پروکسی A. گزارش شما مشکوک به نظر میرسد، اما یک انتخابگر تصادفی مجاز است دقیقاً همین کار را بکند.
انتخاب از همان فهرست در هر درخواست، تکرار را مجاز میکند. با دو نقطه پایانی با احتمال برابر، انتخاب مستقل بعدی یک شانس از دو دارد که با انتخاب قبلی یکسان شود. یک دنباله کوتاه که تکرار دارد، شاهدی بر نادیده گرفتن فهرست توسط انتخابگر نیست.
رفتاری را انتخاب کنید که واقعاً به آن نیاز دارید
| الزام | قاعده انتخاب |
|---|---|
| هر انتخاب مستقل است | هر بار از فهرست واجد شرایط انتخاب کنید |
| هر نقطه پایانی را یک بار پیش از شروع دوباره استفاده کنید | یک نسخه را درهم بزنید، آن را مصرف کنید، سپس گذر دیگری را آغاز کنید |
| از نقطه پایانی بلافاصله قبلی دوری کنید | پیش از انتخاب، آن نقطه پایانی را کنار بگذارید |
برای سیاست آخر، حالت تکنقطهای را صریحاً مدیریت کنید:
candidates = [endpoint for endpoint in eligible if endpoint != previous]
if not candidates:
raise RuntimeError("No different eligible proxy is available")
selected = random.choice(candidates)
این قطعه فرض میکند که random وارد شده و فهرست نقاط پایانی از پیش اعتبارسنجی شده است. یک مخزن عمومی میتواند با فهرست رایگان پروکسی آغاز شود وقتی پروتکلهای آن با کلاینت نهایی سازگار است؛ این قاعده انتخاب همچنان تکرارها را کنترل میکند. اینکه صبر کنید، تنها نقطه پایانی را دوباره به کار ببرید یا متوقف شوید، سیاست برنامه است. حلقه بیپایانی که منتظر یک مقدار تصادفی متفاوت است نمیتواند فهرستی را که فقط یک گزینه متمایز دارد حل کند.
در یک توزیعکننده همزمان، انتخاب و ثبت نقطه پایانی قبلی هم به مالکیت هماهنگ نیاز دارد. در غیر این صورت دو کارگر میتوانند هر دو مقدار قدیمی را کنار بگذارند و مقدار بعدی یکسان را انتخاب کنند.
در پایان، این قاعده به هویت نقطه پایانی مربوط است. دو نقطه پایانی متفاوت میتوانند به یک خروجی عمومی برسند، و یک نقطه پایانی ارائهدهنده میتواند به چندین خروجی برسد. پیش از آنکه گردش را خراب بدانید، اینها را جداگانه ثبت کنید.