Ei løkke vil ha åtte byte av eit SOCKS-svar. Ho har motteke tre. Neste lesing returnerer b'', og løkka legg det til, kontrollerer lengda og prøver igjen i det uendelege.

Det er ein EOF-handteringsfeil, ikkje ein treg proxy som treng eit lengre tidsavbrot. Ved vanleg mottak over ein straum-socket betyr ein tom bytestreng at motparten har kopla frå. Dei resterande fem byta kjem ikkje på den tilkoplinga.

Ein hjelpefunksjon for nøyaktig lesing treng tre ulike utfall: samle ikkje-tomme bitar, feile på EOF før den påkravde lengda og videresende eit tidsavbrot eller ein annan socket-feil. Desse tilfella bør ikkje smelte saman i éi generisk gjenfórsøksløkke.

Set det tiltenkte tidsavbrotet til socketen før operasjonen, og les feltlengdene som proxy-protokollen spesifiserer. Éin einaste mottak kan berre returnere ein del av eit svar. Omvendt gjer ei førespurnad om ein stor fast buffer ikkje at kvar SOCKS-adresse har den lengda.

Ikkje reparer ein avhengnad ved å lime eit gamalt MSG_WAITALL-utdrag inn i kjeldekoden og anta at det dekkjer EOF, signal og plattformåtferd. Føretrekk den støtta rettinga til den vedlikehaldne implementasjonen, eller implementer kontrakten til hjelparen med vilje når parsaren er din kode.

Hald på kor mange byte som var venta og mottekne, utan å logge påloggingsnyttelaster. «EOF etter tre av åtte svarbyte» forklarer den øydelagde utvekslinga mykje betre enn «proxyen heng igjen».

Relaterte artiklar