ଏକ ଲୁପ SOCKS ପ୍ରତିକ୍ରିୟାର ଆଠ ବାଇଟ ଚାହେଁ। ଏହା ତିନି ପାଇଛି। ପରବର୍ତ୍ତୀ ପଠନ b'' ଫେରାଏ, ଲୁପ ଏହାକୁ ଯୋଡେ, ଲମ୍ବା ଯାଞ୍ଚ କରେ ଏବଂ ସର୍ବଦା ପୁନର୍ବାର ଚେଷ୍ଟା କରେ।

ଏହା EOF ପରିଚାଳନାର ବଗ, ଅଧିକ ଟାଇମଆଉଟ ଆବଶ୍ୟକ କରୁଥିବା ମନ୍ଥର ପ୍ରକ୍ସି ନୁହେଁ। ସାଧାରଣ ଷ୍ଟ୍ରିମ୍-ସକେଟ ଗ୍ରହଣରେ, ଖାଲି ବାଇଟ ଷ୍ଟ୍ରିଙ୍ଗର ଅର୍ଥ ସାଥୀ ବିଚ୍ଛିନ୍ନ ହୋଇଛି। ଅବଶିଷ୍ଟ ପାଞ୍ଚ ବାଇଟ ସେହି ସଂଯୋଗରେ ଆସିବ ନାହିଁ।

ସଠିକ୍-ପଠନ ସହାୟକକୁ ତିନି ଭିନ୍ନ ଫଳାଫଳ ଦରକାର: ଖାଲି ନଥିବା ଖଣ୍ଡ ସଂଗ୍ରହ କରିବା, ଆବଶ୍ୟକ ଲମ୍ବା ପୂର୍ବରୁ EOF ରେ ବିଫଳ ହେବା, ଏବଂ ଟାଇମଆଉଟ କିମ୍ବା ଅନ୍ୟ ସକେଟ ତ୍ରୁଟି ଆଗକୁ ପଠାଇବା। ସେହି କ୍ଷେତ୍ରଗୁଡ଼ିକ ଏକ ସାଧାରଣ ପୁନଃଚେଷ୍ଟା ଲୁପରେ ମିଶିଯିବା ଉଚିତ ନୁହେଁ।

କାର୍ଯ୍ୟ ପୂର୍ବରୁ ସକେଟର ଅଭିପ୍ରେତ ଟାଇମଆଉଟ ସେଟ କରନ୍ତୁ, ଏବଂ ପ୍ରକ୍ସି ପ୍ରୋଟୋକଲ ନିର୍ଦ୍ଦିଷ୍ଟ କରିଥିବା ଫିଲ୍ଡ ଲମ୍ବା ପଢନ୍ତୁ। ଗୋଟିଏ ଗ୍ରହଣ କେବଳ ପ୍ରତିକ୍ରିୟାର ଏକ ଅଂଶ ଫେରାଇପାରେ। ବିପରୀତରେ, ବଡ଼ ସ୍ଥିର ବଫର ମାଗିବା ଦ୍ୱାରା ପ୍ରତ୍ୟେକ SOCKS ଠିକଣା ସେହି ଲମ୍ବା ହୋଇଯାଏ ନାହିଁ।

ପୁରୁଣା MSG_WAITALL ସ୍ନିପେଟକୁ ଏହାର ଉତ୍ସରେ ଲଗାଇ ଏହା EOF, ସିଗନାଲ ଏବଂ ପ୍ଲାଟଫର୍ମ ଆଚରଣ ଆବୃତ କରେ ବୋଲି ଧରି ନିର୍ଭରତା ମରାମତି କରନ୍ତୁ ନାହିଁ। ରକ୍ଷଣାବେକ୍ଷଣ କରାଯାଉଥିବା କାର୍ଯ୍ୟାନ୍ୱୟନର ସମର୍ଥିତ ସଂଶୋଧନକୁ ପ୍ରାଥମିକତା ଦିଅନ୍ତୁ, କିମ୍ବା ପାର୍ସର ଆପଣଙ୍କ କୋଡ ହେଲେ ସହାୟକର ଚୁକ୍ତିନାମା ଜାଣିଶୁଣି ଲାଗୁ କରନ୍ତୁ।

କେତେ ବାଇଟ ଆଶା କରାଯାଇଥିଲା ଏବଂ ପ୍ରାପ୍ତ ହେଲା ତାହା ରଖନ୍ତୁ, ପ୍ରମାଣପତ୍ର ପେଲୋଡ ଲଗ ନକରି। “ଆଠ ପ୍ରତିକ୍ରିୟା ବାଇଟରୁ ତିନି ପରେ EOF” ଭଙ୍ଗା ଆଦାନପ୍ରଦାନକୁ “ପ୍ରକ୍ସି ପୁଣି ଅଟକିଗଲା” ଠାରୁ ବହୁତ ଭଲ ଭାବରେ ବ୍ୟାଖ୍ୟା କରେ।

ସମ୍ପର୍କିତ ପ୍ରବନ୍ଧ