تريد حلقة ما ثمانية بايتات من رد SOCKS. وقد استلمت ثلاثة. تعيد القراءة التالية b''، فتضيفه الحلقة، وتفحص الطول، وتحاول مرة أخرى إلى الأبد.

هذا خطأ في معالجة EOF، وليس وكيلاً بطيئًا يحتاج إلى مهلة أطول. في الاستقبال العادي عبر مقبس تدفق، تعني سلسلة البايتات الفارغة أن الطرف الآخر قد انقطع. ولن تصل البايتات الخمسة المتبقية عبر ذلك الاتصال.

يحتاج مساعد القراءة الدقيقة إلى ثلاث نتائج متمايزة: تجميع المقاطع غير الفارغة، والفشل عند EOF قبل الطول المطلوب، وتمرير المهلة أو أي خطأ آخر في المقبس. ولا ينبغي أن تنهار هذه الحالات في حلقة إعادة محاولة عامة واحدة.

اضبط المهلة المقصودة للمقبس قبل العملية، واقرأ أطوال الحقول التي تحددها بروتوكول الوكيل. يمكن لعملية استقبال واحدة أن تعيد جزءًا من الرد فقط. وعلى العكس، فإن طلب مخزن مؤقت كبير ثابت لا يجعل كل عنوان SOCKS بهذا الطول.

لا تصلح اعتمادًا بلصق مقتطف MSG_WAITALL قديم في مصدره وافتراض أنه يغطي EOF والإشارات وسلوك المنصة. فضّل الإصلاح المدعوم في التنفيذ الذي تتم صيانته، أو نفّذ عقد المساعد عمدًا عندما يكون المحلل من كودك.

احتفظ بعدد البايتات المتوقعة والمستلمة، دون تسجيل حمولات بيانات الاعتماد. فـ«EOF بعد ثلاثة من ثمانية بايتات رد» يفسر التبادل المعطوب أفضل بكثير من «تعلّق الوكيل مرة أخرى».

مقالات ذات صلة