एउटा लूपले SOCKS प्रतिक्रियाको आठ बाइट चाहन्छ। उसले तीन पाइसकेको छ। अर्को पढाइले b'' फर्काउँछ, लूपले त्यसलाई थप्छ, लम्बाइ जाँच्छ र सधैं फेरि प्रयास गर्छ।

यो EOF सम्हाल्ने बग हो, लामो टाइमआउट चाहिने ढिलो प्रोक्सी होइन। सामान्य स्ट्रिम-सकेट रिसिभमा, खाली बाइट स्ट्रिङको अर्थ साथीले जडान विच्छेद गरेको हो। बाँकी पाँच बाइट त्यो जडानमा आउने छैनन्।

सटीक-पढाइ सहायकलाई तीन फरक नतिजा चाहिन्छ: खाली नभएका टुक्रा जम्मा गर्नु, आवश्यक लम्बाइअघि EOF मा असफल हुनु, र टाइमआउट वा अन्य सकेट त्रुटि अगाडि पठाउनु। ती केसहरू एउटै सामान्य पुनःप्रयास लूपमा मिसिनु हुँदैन।

क्रियाअघि सकेटको इच्छित टाइमआउट सेट गर्नुहोस्, र प्रोक्सी प्रोटोकलले निर्दिष्ट गरेका फिल्ड लम्बाइ पढ्नुहोस्। एउटै रिसिभले प्रतिक्रियाको एउटा भाग मात्र फर्काउन सक्छ। यसको विपरीत, ठूलो स्थिर बफर माग्नाले प्रत्येक SOCKS ठेगाना त्यो लम्बाइको हुँदैन।

पुरानो MSG_WAITALL स्निपेट त्यसको स्रोतमा टाँसेर यसले EOF, सिग्नल र प्लेटफर्म व्यवहार समेट्छ भनी ठानी निर्भरता सुधार्नु हुँदैन। मर्मत गरिएको कार्यान्वयनको समर्थित सुधारलाई प्राथमिकता दिनुहोस्, वा पार्सर तपाईंको कोड भए सहायकको सम्झौता जानाजान लागू गर्नुहोस्।

कति बाइट अपेक्षित र प्राप्त भए राख्नुहोस्, क्रेडेन्सियल पेलोड लग नगरी। “आठ प्रतिक्रिया बाइटमध्ये तीनपछि EOF” ले टुटेको आदानप्रदानलाई “प्रोक्सी फेरि अड्कियो” भन्दा धेरै राम्रोसँग व्याख्या गर्छ।

सम्बन्धित लेखहरू