ตัวตรวจสอบพร็อกซีตั้ง SendTimeout = 200 เรียก Connect และรอนานกว่าที่คาดไว้มาก timeout นั้นผูกอยู่กับการดำเนินการที่ตัวตรวจสอบยังไปไม่ถึง

Socket.SendTimeout ควบคุมการส่งแบบซิงโครนัส มันไม่ได้ให้กำหนดเวลา 200 ms แก่ความพยายามเชื่อมต่อแบบซิงโครนัส การเพิ่มการหน่วงก่อน Connect เพียงเพิ่มความล่าช้าอีกอย่าง

ยกเลิกการดำเนินการที่กำลังรออยู่

บนเป้าหมาย .NET สมัยใหม่ที่มี overload ที่ยกเลิกได้ การตรวจสอบแบบ async สามารถใช้เวลางบประมาณกับการสร้างการเชื่อมต่อได้:

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

ส่วนนี้อยู่ในเมธอด async โดยโฮสต์และพอร์ตของพร็อกซีนั้นผู้เรียกเป็นผู้ให้; ผู้สมัครสาธารณะจากรายการพร็อกซีสามารถให้ข้อมูลสองอย่างนั้นได้ จัดการการยกเลิกแยกจากข้อผิดพลาดของ socket หากตัวตรวจสอบรายงานสาเหตุความล้มเหลว การ dispose ไคลเอนต์ยังป้องกันไม่ให้การตรวจสอบที่เสร็จแล้วสะสม socket

โค้ด .NET Framework รุ่นเก่าไม่มี overload สมัยใหม่ครบทุกตัว ใช้การจัดเชื่อมต่อแบบ async ที่รองรับและปิด socket อย่างชัดเจนเมื่อละทิ้งความพยายาม การหยุดการรอของคุณเพียงอย่างเดียวไม่ได้พิสูจน์ว่าการดำเนินการเบื้องหลังหยุดแล้ว

ผลลัพธ์สีเขียวยังเป็นผลลัพธ์เล็ก ๆ

การเชื่อมต่อ TCP ที่สำเร็จพิสูจน์ว่าไคลเอนต์นี้ไปถึงปลายทางที่กำลังรับฟังแล้ว แต่ยังไม่ได้เจรจา SOCKS ไม่ได้ยืนยันตัวตนกับพร็อกซี HTTP ไม่ได้เปิด CONNECT และไม่ได้รับการตอบกลับของเว็บไซต์ที่ต้องการ

ให้ขั้นตอนต่อ ๆ ไปนั้นมีการจัดการแบบจำกัดของตัวเอง หรือส่งกำหนดเวลารวมที่ตั้งใจไว้ผ่านขั้นตอนเหล่านั้น มิฉะนั้นตัวจับเวลาการเชื่อมต่อที่ซ่อมแล้วอาจทำงานได้อย่างสมบูรณ์ในขณะที่ตัวตรวจสอบใช้เวลาอีกหนึ่งนาทีรอ handshake ของพร็อกซี

บทความที่เกี่ยวข้อง