Python SOCKS పఠన లూప్లో EOF నిర్వహణ
మూసిన కనెక్షన్ను ఎప్పుడూ రాని సమయ పరిమితిగా పరిగణించడం బదులు SOCKS ఖచ్చిత పఠన లూప్లో EOFని స్పష్టంగా నిర్వహించండి.
ఒక లూప్ SOCKS ప్రతిస్పందనలోని ఎనిమిది బైట్లను కోరుతుంది. మూడు పొందింది. తదుపరి పఠనం b''ని తిరిగి ఇస్తుంది, లూప్ దానిని జోడిస్తుంది, పొడవును తనిఖీ చేస్తుంది మరియు శాశ్వతంగా మళ్లీ ప్రయత్నిస్తుంది.
ఇది EOF నిర్వహణ బగ్, ఎక్కువ సమయ పరిమితి అవసరమయ్యే నెమ్మది ప్రాక్సీ కాదు. సాధారణ స్ట్రీమ్-సాకెట్ స్వీకరణలో, ఖాళీ బైట్ స్ట్రింగ్ అంటే సహచరుడు డిస్కనెక్ట్ అయ్యాడు. మిగిలిన ఐదు బైట్లు ఆ కనెక్షన్లో రావు.
ఖచ్చిత పఠన సహాయకానికి మూడు వేర్వేరు ఫలితాలు కావాలి: ఖాళీ కాని భాగాలను సేకరించడం, అవసరమైన పొడవుకు ముందు EOF వద్ద విఫలం కావడం, మరియు సమయ పరిమితి లేదా ఇతర సాకెట్ లోపాన్ని ప్రసారం చేయడం. ఆ సందర్భాలు ఒకే సాధారణ పునఃప్రయత్న లూప్లో కలిసిపోకూడదు.
కార్యకలాపానికి ముందు సాకెట్ యొక్క ఉద్దేశిత సమయ పరిమితిని సెట్ చేయండి, మరియు ప్రాక్సీ ప్రోటోకాల్ పేర్కొన్న ఫీల్డ్ పొడవులను చదవండి. ఒకే స్వీకరణ ప్రతిస్పందనలో కొంత భాగాన్ని మాత్రమే తిరిగి ఇవ్వగలదు. దీనికి విరుద్ధంగా, పెద్ద స్థిర బఫర్ను అడగడం ప్రతి SOCKS చిరునామా ఆ పొడవు కావడానికి కారణం కాదు.
పాత MSG_WAITALL స్నిపెట్ను దాని మూలంలో అతికించి అది EOF, సిగ్నల్స్ మరియు ప్లాట్ఫారమ్ ప్రవర్తనను కవర్ చేస్తుందని ఊహించి ఆధారాన్ని బాగు చేయవద్దు. నిర్వహించబడే అమలు యొక్క మద్దతు ఉన్న సవరణను ఇష్టపడండి, లేదా పార్సర్ మీ కోడ్ అయితే సహాయకి ఒప్పందాన్ని ఉద్దేశపూర్వకంగా అమలు చేయండి.
ఎన్ని బైట్లు ఆశించబడ్డాయి మరియు స్వీకరించబడ్డాయి అనేది ఉంచండి, ఆధారాల పేలోడ్లను లాగ్ చేయకుండా. “ఎనిమిది ప్రతిస్పందన బైట్లలో మూడు తర్వాత EOF” విరిగిన మార్పిడిని “ప్రాక్సీ మళ్లీ నిలిచిపోయింది” కంటే చాలా బాగా వివరిస్తుంది.