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

यह EOF-प्रबंधन की बग है, लंबे टाइमआउट की ज़रूरत वाला धीमा प्रॉक्सी नहीं। सामान्य स्ट्रीम-सॉकेट रिसीव में, खाली बाइट स्ट्रिंग का अर्थ है कि सहकर्मी डिस्कनेक्ट हो गया। शेष पाँच बाइट उस कनेक्शन पर नहीं आएँगे।

सटीक-रीड हेल्पर को तीन अलग परिणाम चाहिए: गैर-खाली खंड जमा करना, आवश्यक लंबाई से पहले EOF पर विफल होना, और टाइमआउट या अन्य सॉकेट त्रुटि आगे बढ़ाना। वे मामले एक सामान्य पुनःप्रयास लूप में नहीं समाहित होने चाहिए।

ऑपरेशन से पहले सॉकेट का इच्छित टाइमआउट सेट करें, और प्रॉक्सी प्रोटोकॉल द्वारा निर्दिष्ट फ़ील्ड लंबाइयाँ पढ़ें। एक ही रिसीव प्रतिक्रिया का केवल एक भाग लौटा सकता है। इसके विपरीत, बड़ा निश्चित बफ़र माँगने से हर SOCKS पता उस लंबाई का नहीं हो जाता।

किसी निर्भरता को उसके स्रोत में पुराना MSG_WAITALL स्निपेट चिपकाकर और यह मानकर मत ठीक करें कि वह EOF, सिग्नल और प्लेटफ़ॉर्म व्यवहार को कवर करता है। रखरखाव किए गए कार्यान्वयन के समर्थित सुधार को प्राथमिकता दें, या जब पार्सर आपका कोड हो तो हेल्पर का अनुबंध जानबूझकर लागू करें।

कितने बाइट अपेक्षित थे और कितने प्राप्त हुए, यह रखें, बिना क्रेडेंशियल पेलोड लॉग किए। “आठ प्रतिक्रिया बाइट में से तीन के बाद EOF” टूटी अदला-बदली को “प्रॉक्सी फिर अटक गया” से कहीं बेहतर समझाता है।

संबंधित लेख