Socket.SendTimeout ପ୍ରକ୍ସି ସଂଯୋଗ ପ୍ରଚେଷ୍ଟାକୁ ସୀମିତ କରେ ନାହିଁ
କେବଳ ଡାଟା ପଠାଇବାରେ ଲାଗୁଥିବା ଟାଇମଆଉଟ ଦେବା ପରିବର୍ତ୍ତେ ସଂଯୋଗ ସ୍ଥାପନ ସମୟରେ ପ୍ରକ୍ସି ପୋର୍ଟ ଯାଞ୍ଚକୁ ସୀମିତ କରନ୍ତୁ।
ପ୍ରକ୍ସି ଯାଞ୍ଚକର୍ତ୍ତା SendTimeout = 200 ସେଟ କରେ, Connect କଲ କରେ ଏବଂ ଆଶା କରାଯାଇଥିବା ଠାରୁ ବହୁତ ଅଧିକ ସମୟ ଅପେକ୍ଷା କରେ। ଟାଇମଆଉଟ ଏପରି ଏକ କାର୍ଯ୍ୟ ସହିତ ବନ୍ଧା ଯାହାକୁ ଯାଞ୍ଚକର୍ତ୍ତା ଏପର୍ଯ୍ୟନ୍ତ ପହଞ୍ଚି ନାହିଁ।
Socket.SendTimeout ସିଙ୍କ୍ରୋନସ ପଠାଇବାକୁ ନିୟନ୍ତ୍ରଣ କରେ। ଏହା ସିଙ୍କ୍ରୋନସ ସଂଯୋଗ ପ୍ରଚେଷ୍ଟାକୁ 200 ms ସମୟସୀମା ଦିଏ ନାହିଁ। Connect ପୂର୍ବରୁ ନିଦ୍ରା ଯୋଡିଲେ କେବଳ ଆଉ ଏକ ବିଳମ୍ବ ଯୋଡାଯାଏ।
ଅପେକ୍ଷା କରୁଥିବା କାର୍ଯ୍ୟ ବାତିଲ କରନ୍ତୁ
ବାତିଲ ଯୋଗ୍ୟ overload ପ୍ରଦାନ କରୁଥିବା ଆଧୁନିକ .NET ଲକ୍ଷ୍ୟରେ, 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 ପାଇଁ ଆଉ ଏକ ମିନିଟ ବିତାଏ।