Руковање EOF-ом у Python SOCKS петљи читања
Рукујте EOF-ом експлицитно у SOCKS петљи тачног читања уместо да затворену везу третирате као тајмаут који никада не долази.
Петља жели осам бајтова SOCKS одговора. Примила је три. Следеће читање враћа b'', петља га додаје, проверава дужину и поново покушава заувек.
То је грешка у руковању EOF-ом, а не спор прокси коме треба дужи тајмаут. Код нормалног примања преко стрим сокета, празан низ бајтова значи да се друга страна одспојила. Преосталих пет бајтова неће стићи том везом.
Помоћник за тачно читање треба три различита исхода: акумулирати непразне делове, пасти на EOF пре потребне дужине и проследити тајмаут или другу грешку сокета. Ти случајеви не смеју да се стопе у једну генеричку петљу поновних покушаја.
Поставите предвиђени тајмаут сокета пре операције и читајте дужине поља које прописује прокси протокол. Једно примање може вратити само део одговора. Супротно томе, захтев за великим фиксним бафером не чини сваку SOCKS адресу те дужине.
Не поправљајте зависност лепљењем старог MSG_WAITALL исечка у њен изворни код и претпоставком да покрива EOF, сигнале и понашање платформе. Преферирајте подржани поправак у одржаваној имплементацији или намерно имплементирајте уговор помоћника када је парсер ваш код.
Задржите колико је бајтова очекивано и примљено, без логовања корисних оптерећења акредитива. „EOF након три од осам бајтова одговора“ објашњава покварену размену много боље од „прокси се поново замрзнуо“.