एक लूप SOCKS प्रतिसादाचे आठ बाइट मागतो. त्याला तीन मिळाले आहेत. पुढील वाचन b'' परत करते, लूप ते जोडतो, लांबी तपासतो आणि कायम पुन्हा प्रयत्न करतो.

ही EOF हाताळणीची बग आहे, जास्त टाइमआउट लागणारा संथ प्रॉक्सी नाही. सामान्य स्ट्रीम-सॉकेट रिसीव्हमध्ये, रिकामी बाइट स्ट्रिंग म्हणजे समवेताने डिस्कनेक्ट केले आहे. उर्वरित पाच बाइट त्या कनेक्शनवर येणार नाहीत.

अचूक-वाचन सहाय्यकाला तीन वेगळे परिणाम हवेत: रिकामे नसलेले तुकडे जमा करणे, आवश्यक लांबीपूर्वी EOF वर अपयशी होणे, आणि टाइमआउट किंवा इतर सॉकेट त्रुटी पुढे पाठवणे. ती प्रकरणे एका सामान्य पुनःप्रयत्न लूपमध्ये विलीन होऊ नयेत.

क्रियेपूर्वी सॉकेटचा इच्छित टाइमआउट सेट करा, आणि प्रॉक्सी प्रोटोकॉलने निर्दिष्ट केलेल्या फील्ड लांबी वाचा. एकाच रिसीव्हमध्ये प्रतिसादाचा फक्त एक भाग परत येऊ शकतो. उलट, मोठा स्थिर बफर मागण्याने प्रत्येक SOCKS पत्ता त्या लांबीचा होत नाही.

जुना MSG_WAITALL स्निपेट त्याच्या स्रोतात पेस्ट करून ते EOF, सिग्नल आणि प्लॅटफॉर्म वर्तन व्यापते असे गृहीत धरून अवलंबित्व दुरुस्त करू नका. देखभाल केलेल्या अंमलबजावणीच्या समर्थित दुरुस्तीला प्राधान्य द्या, किंवा पार्सर तुमचा कोड असल्यास सहाय्यकाचा करार जाणूनबुजून लागू करा.

किती बाइट अपेक्षित होते आणि किती मिळाले ते ठेवा, क्रेडेन्शियल पेलोड लॉग न करता. “आठ प्रतिसाद बाइटपैकी तीननंतर EOF” तुटलेल्या देवघेवीला “प्रॉक्सी पुन्हा अडकले” पेक्षा खूप चांगले स्पष्ट करते.

संबंधित लेख