ਇੱਕ ਲੂਪ SOCKS ਜਵਾਬ ਦੇ ਅੱਠ ਬਾਈਟ ਚਾਹੁੰਦਾ ਹੈ। ਇਸਨੂੰ ਤਿੰਨ ਮਿਲ ਚੁੱਕੇ ਹਨ। ਅਗਲੀ ਪੜ੍ਹਤ b'' ਵਾਪਸ ਕਰਦੀ ਹੈ, ਲੂਪ ਇਸਨੂੰ ਜੋੜਦਾ ਹੈ, ਲੰਬਾਈ ਜਾਂਚਦਾ ਹੈ ਅਤੇ ਹਮੇਸ਼ਾ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ।

ਇਹ EOF ਸੰਭਾਲਣ ਦੀ ਬੱਗ ਹੈ, ਲੰਮੇ ਟਾਈਮਆਉਟ ਵਾਲਾ ਹੌਲੀ ਪ੍ਰੌਕਸੀ ਨਹੀਂ। ਆਮ ਸਟ੍ਰੀਮ-ਸਾਕਟ ਰਿਸੀਵ ਵਿੱਚ, ਖਾਲੀ ਬਾਈਟ ਸਟਰਿੰਗ ਦਾ ਮਤਲਬ ਹੈ ਸਾਥੀ ਨੇ ਕਨੈਕਸ਼ਨ ਤੋੜ ਦਿੱਤਾ। ਬਾਕੀ ਪੰਜ ਬਾਈਟ ਉਸ ਕਨੈਕਸ਼ਨ ਉੱਤੇ ਨਹੀਂ ਆਉਣਗੇ।

ਸਹੀ-ਪੜ੍ਹਨ ਸਹਾਇਕ ਨੂੰ ਤਿੰਨ ਵੱਖਰੇ ਨਤੀਜੇ ਚਾਹੀਦੇ ਹਨ: ਖਾਲੀ ਨਾ ਹੋਣ ਵਾਲੇ ਟੁਕੜੇ ਇਕੱਠੇ ਕਰਨਾ, ਲੋੜੀਂਦੀ ਲੰਬਾਈ ਤੋਂ ਪਹਿਲਾਂ EOF ਉੱਤੇ ਫੇਲ ਹੋਣਾ, ਅਤੇ ਟਾਈਮਆਉਟ ਜਾਂ ਹੋਰ ਸਾਕਟ ਗਲਤੀ ਅੱਗੇ ਭੇਜਣਾ। ਉਹ ਕੇਸ ਇੱਕ ਆਮ ਦੁਬਾਰਾ-ਕੋਸ਼ਿਸ਼ ਲੂਪ ਵਿੱਚ ਨਹੀਂ ਮਿਲਣੇ ਚਾਹੀਦੇ।

ਕਾਰਵਾਈ ਤੋਂ ਪਹਿਲਾਂ ਸਾਕਟ ਦਾ ਇੱਛਤ ਟਾਈਮਆਉਟ ਸੈੱਟ ਕਰੋ, ਅਤੇ ਪ੍ਰੌਕਸੀ ਪ੍ਰੋਟੋਕੋਲ ਵੱਲੋਂ ਦਿੱਤੀ ਫੀਲਡ ਲੰਬਾਈ ਪੜ੍ਹੋ। ਇੱਕ ਰਿਸੀਵ ਸਿਰਫ਼ ਜਵਾਬ ਦਾ ਇੱਕ ਹਿੱਸਾ ਵਾਪਸ ਕਰ ਸਕਦਾ ਹੈ। ਇਸਦੇ ਉਲਟ, ਵੱਡਾ ਸਥਿਰ ਬਫਰ ਮੰਗਣ ਨਾਲ ਹਰ SOCKS ਪਤਾ ਉਸ ਲੰਬਾਈ ਦਾ ਨਹੀਂ ਹੋ ਜਾਂਦਾ।

ਪੁਰਾਣਾ MSG_WAITALL ਸਨਿੱਪਟ ਇਸਦੇ ਸਰੋਤ ਵਿੱਚ ਪੇਸਟ ਕਰਕੇ ਅਤੇ ਇਹ ਮੰਨ ਕੇ ਕਿ ਇਹ EOF, ਸਿਗਨਲ ਅਤੇ ਪਲੇਟਫਾਰਮ ਵਿਵਹਾਰ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ, ਨਿਰਭਰਤਾ ਦੀ ਮੁਰੰਮਤ ਨਾ ਕਰੋ। ਸੰਭਾਲੇ ਗਏ ਲਾਗੂਕਰਨ ਦੇ ਸਮਰਥਿਤ ਸੁਧਾਰ ਨੂੰ ਤਰਜੀਹ ਦਿਓ, ਜਾਂ ਜਦੋਂ ਪਾਰਸਰ ਤੁਹਾਡਾ ਕੋਡ ਹੈ ਤਾਂ ਸਹਾਇਕ ਦੇ ਇਕਰਾਰਨਾਮੇ ਨੂੰ ਜਾਣਬੁੱਝ ਕੇ ਲਾਗੂ ਕਰੋ।

ਕਿੰਨੇ ਬਾਈਟ ਉਮੀਦ ਅਤੇ ਪ੍ਰਾਪਤ ਹੋਏ, ਇਹ ਰੱਖੋ, ਪ੍ਰਮਾਣ-ਪੱਤਰ ਪੇਲੋਡ ਲੌਗ ਨਾ ਕਰਕੇ। “ਅੱਠ ਜਵਾਬ ਬਾਈਟਾਂ ਵਿੱਚੋਂ ਤਿੰਨ ਤੋਂ ਬਾਅਦ EOF” ਟੁੱਟੇ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਨੂੰ “ਪ੍ਰੌਕਸੀ ਫਿਰ ਅਟਕ ਗਈ” ਨਾਲੋਂ ਬਹੁਤ ਵਧੀਆ ਸਮਝਾਉਂਦਾ ਹੈ।

ਸੰਬੰਧਿਤ ਲੇਖ