בודק פרוקסי מגדיר SendTimeout = 200, קורא ל-Connect וממתין זמן רב בהרבה מהצפוי. פסק הזמן תלוי בפעולה שהבודק טרם הגיע אליה.

Socket.SendTimeout שולט בשליחות סינכרוניות. הוא אינו נותן לניסיון התחברות סינכרוני מועד של 200 ms. הוספת שינה לפני Connect רק מוסיפה השהיה נוספת.

בטלו את הפעולה שממתינה

ביעד .NET מודרני שמציע את ה-overload הניתן לביטול, בדיקה אסינכרונית יכולה להחיל את התקציב שלה על הקמת החיבור:

using var budget = new CancellationTokenSource(TimeSpan.FromSeconds(2));
using var client = new TcpClient();
await client.ConnectAsync(proxyHost, proxyPort, budget.Token);

הקטע שייך למתודת async, כאשר מארח הפרוקסי והפורט מסופקים על ידי הקורא; מועמד ציבורי מרשימת פרוקסי יכול לספק את שתי הקלטות הללו. טפלו בביטול בנפרד משגיאת socket אם הבודק מדווח על סיבות כשל. שחרור הלקוח גם מונע מבדיקות שהושלמו להצטבר sockets.

קוד .NET Framework ישן יותר אינו כולל כל overload מודרני. השתמשו בסידור חיבור אסינכרוני נתמך וסגרו את ה-socket במפורש כשאתם נוטשים את הניסיון. עצירת ההמתנה שלכם בלבד אינה מוכיחה שפעולה בסיסית נעצרה.

התוצאה הירוקה היא עדיין תוצאה קטנה

חיבור TCP מוצלח מוכיח שהלקוח הזה הגיע לנקודת קצה שמקשיבה. הוא לא ניהל משא ומתן על SOCKS, לא אימת את עצמו מול פרוקסי HTTP, לא פתח CONNECT ולא קיבל את תגובת האתר הרצויה.

תנו לאותם שלבים מאוחרים טיפול מוגבל משלהם, או העבירו דרכם מועד כולל מכוון. אחרת טיימר החיבור המתוקן עשוי לעבוד באופן מושלם בזמן שהבודק מבלה דקה נוספת בהמתנה ל-handshake של פרוקסי.

מאמרים קשורים