ਬਾਕੀ ਬਚੇ ਬਾਈਟ ਖਾਲੀ ਕਰਨ ਤੋਂ ਬਾਅਦ TCP ਹਾਫ-ਕਲੋਜ਼ ਅੱਗੇ ਭੇਜਣਾ
TCP ਪ੍ਰੌਕਸੀ ਵਿੱਚ ਕਤਾਰ ਵਾਲਾ ਡੇਟਾ ਗੁਆਏ ਬਿਨਾਂ ਅਤੇ ਦੂਜੇ ਪਾਸੇ ਜਵਾਬ ਕੱਟੇ ਬਿਨਾਂ EOF ਸੰਭਾਲੋ।
ਕਲਾਇੰਟ ਭੇਜਣਾ ਮੁਕਾ ਦਿੰਦਾ ਹੈ, ਪ੍ਰੌਕਸੀ EOF ਦੇਖਦੀ ਹੈ, ਅਤੇ ਜਵਾਬ ਗਾਇਬ ਹੋ ਜਾਂਦਾ ਹੈ। ਪ੍ਰੌਕਸੀ ਦੇ ਦੋਵੇਂ ਸਾਕਟ ਤੁਰੰਤ ਬੰਦ ਕਰਨ ਨਾਲ ਬਿਲਕੁਲ ਉਹੀ ਕ੍ਰਮ ਹੋ ਸਕਦਾ ਹੈ। TCP ਰੀਲੇ ਵਿੱਚ ਇੱਕ ਪਾਸੇ ਦਾ ਸੁਵਿਵਸਥ ਅੰਤ ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ ਦੂਜਾ ਪਾਸਾ ਮੁੱਕ ਗਿਆ ਹੈ।
ਇੱਕ ਕਲਾਇੰਟ ਬਾਰੇ ਸੋਚੋ ਜੋ ਬੇਨਤੀ ਭੇਜਦਾ ਹੈ, ਆਪਣਾ ਭੇਜਣ ਵਾਲਾ ਪਾਸਾ ਬੰਦ ਕਰਦਾ ਹੈ ਅਤੇ ਜਵਾਬ ਦੀ ਉਡੀਕ ਕਰਦਾ ਹੈ:
client -- request, then FIN --> proxy --> service
client <-------- reply ------- proxy <-- service
ਪ੍ਰੌਕਸੀ ਕੋਲ ਦੋ TCP ਕਨੈਕਸ਼ਨ ਅਤੇ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਚੱਲਦੀਆਂ ਦੋ ਬਾਈਟ ਸਟ੍ਰੀਮਾਂ ਹਨ। ਇਸਨੂੰ ਆਪਣੇ ਤੋਂ ਪਹਿਲਾਂ ਆਉਣ ਵਾਲੇ ਬਾਈਟ ਭੇਜਣ ਤੋਂ ਬਾਅਦ ਇਨਪੁਟ ਦੇ ਅੰਤ ਦਾ ਸੰਕੇਤ ਵੀ ਅੱਗੇ ਲੈ ਜਾਣਾ ਹੈ।
EOF ਅੱਗੇ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਕਤਾਰ ਖਾਲੀ ਕਰੋ
TCP ਸਟ੍ਰੀਮ ਉੱਤੇ ਗੈਰ-ਜ਼ੀਰੋ ਆਕਾਰ ਦੀ ਪ੍ਰਾਪਤੀ ਵਿੱਚ, ਜ਼ੀਰੋ ਦਾ ਮੁੜਨਾ ਉਸ ਆਉਂਦੀ ਸਟ੍ਰੀਮ ਦੇ ਸੁਵਿਵਸਥ ਅੰਤ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ। ਉਸ ਪੜ੍ਹਨ ਵਾਲੇ ਪਾਸੇ ਨੂੰ ਪੂਰਾ ਹੋਇਆ ਚਿੰਨ੍ਹਿਤ ਕਰੋ। ਉਸ ਤੋਂ ਹੋਰ ਇਨਪੁਟ ਦੀ ਉਡੀਕ ਕਰਨਾ ਬੰਦ ਕਰੋ, ਪਰ ਉਲਟ ਸਾਕਟ ਲਈ ਪਹਿਲਾਂ ਹੀ ਕਤਾਰ ਵਿੱਚ ਪਏ ਬਾਈਟ ਰੱਖੋ।
ਕਲਾਇੰਟ ਤੋਂ ਸੇਵਾ ਵੱਲ ਕਤਾਰ ਖਾਲੀ ਹੋਣ ਤੋਂ ਬਾਅਦ, POSIX ਸਾਕਟ ਉੱਤੇ shutdown(service_socket, SHUT_WR) ਕਾਲ ਕਰੋ। ਇਹ ਸੇਵਾ ਵੱਲ ਹੋਰ ਪ੍ਰਸਾਰਣ ਮੁਕਾ ਦਿੰਦਾ ਹੈ ਜਦੋਂ ਕਿ ਸੇਵਾ ਤੋਂ ਕਲਾਇੰਟ ਵੱਲ ਪਾਸਾ ਉਪਲਬਧ ਰਹਿੰਦਾ ਹੈ। ਜਦੋਂ ਸੇਵਾ ਆਪਣਾ ਜਵਾਬ ਮੁਕਾ ਲਵੇ, ਤਾਂ ਜਵਾਬ ਦੀ ਕਤਾਰ ਖਾਲੀ ਕਰਨ ਤੋਂ ਬਾਅਦ ਸ਼ੀਸ਼ੇ ਵਾਲੀ ਕਾਰਵਾਈ ਲਾਗੂ ਕਰੋ।
ਡਿਸਕ੍ਰਿਪਟਰ ਬੰਦ ਕਰਨਾ ਉਸ ਬਿੰਦੂ ਨਾਲ ਸੰਬੰਧਿਤ ਹੈ ਜਿੱਥੇ ਦੋਵੇਂ ਪਾਸੇ ਅਤੇ ਉਨ੍ਹਾਂ ਦੇ ਬਾਕੀ ਬਫਰ ਮੁੱਕ ਗਏ ਹਨ, ਜਾਂ ਜਿੱਥੇ ਕਿਸੇ ਗਲਤੀ ਜਾਂ ਰੱਦ ਕਰਨ ਲਈ ਸਮਾਪਤੀ ਲੋੜੀਂਦੀ ਹੈ। ਆਪਣਾ ਬਾਕੀ ਅੱਧਾ ਹਿੱਸਾ ਕਦੇ ਪੂਰਾ ਨਾ ਕਰਨ ਵਾਲੇ ਸਾਥੀ ਲਈ ਸੀਮਤ ਸਮਾਂ-ਸੀਮਾ ਰੱਖੋ।
ਤਿਆਰੀ ਪੜ੍ਹਨ ਦਾ ਸੱਦਾ ਹੈ
ਪੜ੍ਹਨਯੋਗ ਸਾਕਟ ਵਿੱਚ ਡੇਟਾ ਜਾਂ EOF ਹਾਲਤ ਹੋ ਸਕਦੀ ਹੈ। recv ਕਾਲ ਕਰੋ ਅਤੇ ਇਸਦੇ ਨਤੀਜੇ ਦੀ ਵਿਆਖਿਆ ਕਰੋ। ਧਨਾਤਮਕ ਸੰਖਿਆਵਾਂ ਅੱਗੇ ਭੇਜਣ ਵਾਲੇ ਬਾਈਟ ਹਨ; ਜ਼ੀਰੋ ਪਾਸੇ ਦਾ ਅੰਤ ਹੈ। ਨਾਨ-ਬਲੌਕਿੰਗ ਸਾਕਟ ਉੱਤੇ, EAGAIN ਜਾਂ EWOULDBLOCK ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਹੁਣ ਹੋਰ ਇਨਪੁਟ ਨਹੀਂ, ਜਦੋਂ ਕਿ EINTR ਨੂੰ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ। ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ EOF ਵਰਗੀ ਉਹੀ ਘਟਨਾ ਨਹੀਂ ਹੈ।
ਮੁੜੇ ਹੋਏ ਬਾਈਟ ਬਫਰ ਵਿੱਚ FIN ਝੰਡਾ ਨਾ ਲੱਭੋ। TCP ਇਸ API ਨੂੰ ਕ੍ਰਮਬੱਧ ਬਾਈਟ ਸਟ੍ਰੀਮ ਦਿੰਦਾ ਹੈ; ਪੈਕੇਟ ਸੀਮਾਵਾਂ ਅਤੇ FIN ਹਿੱਸਾ ਆਮ ਐਪਲੀਕੇਸ਼ਨ ਪੇਲੋਡ ਨਹੀਂ ਹਨ।
ਇਹ ਕੱਚੀ ਬਾਈਟ ਸੁਰੰਗ ਦਾ ਜੀਵਨ ਚੱਕਰ ਹੈ। ਸੁਨੇਹੇ ਪਾਰਸ ਕਰਨ ਵਾਲੀ HTTP ਪ੍ਰੌਕਸੀ ਨੂੰ ਅਜੇ ਵੀ HTTP ਫਰੇਮਿੰਗ ਦਾ ਸਤਿਕਾਰ ਕਰਨਾ ਪੈਂਦਾ ਹੈ, ਅਤੇ TLS ਖ਼ਤਮ ਕਰਨ ਵਾਲੀ ਪ੍ਰੌਕਸੀ ਕੋਲ ਵੀ TLS ਸ਼ਟਡਾਊਨ ਪ੍ਰੋਟੋਕਾਲ ਹੁੰਦਾ ਹੈ। ਉਹ ਪ੍ਰੋਟੋਕਾਲ ਫੈਸਲੇ ਦਿਸ਼ਾਤਮਕ TCP ਰੀਲੇ ਤੋਂ ਉੱਪਰ ਰੱਖੋ।