مدیریت EOF در حلقه خواندن SOCKS پایتون

یک حلقه هشت بایت از پاسخ SOCKS می‌خواهد. سه بایت دریافت کرده است. خواندن بعدی b'' را برمی‌گرداند، حلقه آن را اضافه می‌کند، طول را بررسی می‌کند و برای همیشه دوباره تلاش می‌کند.

این یک اشکال در مدیریت EOF است، نه پروکسی کندی که به مهلت طولانی‌تری نیاز دارد. در دریافت معمول از سوکت جریانی، رشته بایت خالی یعنی همتا قطع شده است. پنج بایت باقی‌مانده روی آن اتصال نخواهند رسید.

یک کمک‌تابع خواندن دقیق به سه نتیجه متمایز نیاز دارد: انباشتن قطعات ناتهی، شکست در EOF پیش از طول لازم، و انتقال مهلت یا خطای دیگر سوکت. این موارد نباید در یک حلقه تلاش مجدد عمومی ادغام شوند.

مهلت موردنظر سوکت را پیش از عملیات تنظیم کنید و طول فیلدهایی را که پروتکل پروکسی تعیین می‌کند بخوانید. یک دریافت واحد می‌تواند فقط بخشی از یک پاسخ را برگرداند. برعکس، درخواست یک بافر ثابت بزرگ باعث نمی‌شود هر نشانی SOCKS آن طول را داشته باشد.

یک وابستگی را با چسباندن قطعه قدیمی MSG_WAITALL در منبعش و فرض اینکه EOF، سیگنال‌ها و رفتار پلتفرم را پوشش می‌دهد تعمیر نکنید. اصلاح پشتیبانی‌شده پیاده‌سازی نگه‌داری‌شده را ترجیح دهید، یا وقتی تجزیه‌گر کد شماست، قرارداد کمک‌تابع را آگاهانه پیاده کنید.

نگه دارید چند بایت انتظار می‌رفت و چند بایت دریافت شد، بدون ثبت بارهای اعتبارنامه. «EOF پس از سه بایت از هشت بایت پاسخ» تبادل خراب را بسیار بهتر از «پروکسی دوباره گیر کرد» توضیح می‌دهد.