ਪ੍ਰੌਕਸੀ ਕੀਤੇ WebSocket ਦੇ ਦੁਬਾਰਾ ਜੁੜਨ ਤੋਂ ਬਾਅਦ ਸੈਸ਼ਨ ਵੀ ਬਹਾਲ ਕਰੋ

ਦੁਬਾਰਾ ਜੁੜਨ ਵਾਲਾ ਕਾਲਬੈਕ ਚੱਲਦਾ ਹੈ ਅਤੇ ਨਵਾਂ ਸਾਕਟ ਖੁੱਲ੍ਹਦਾ ਹੈ। ਇਹ ਟਰਾਂਸਪੋਰਟ ਦੀ ਬਹਾਲੀ ਹੈ। ਇਸ ਦਾ ਇਹ ਮਤਲਬ ਨਹੀਂ ਕਿ ਤੁਹਾਡੀਆਂ ਸਦੱਸਤਾਵਾਂ, ਸੁਨੇਹਾ ਪੁਸ਼ਟੀਆਂ ਜਾਂ ਐਪਲੀਕੇਸ਼ਨ ਸੈਸ਼ਨ ਉੱਥੋਂ ਹੀ ਜਾਰੀ ਰਹੇ ਜਿੱਥੇ ਪਿਛਲਾ ਕਨੈਕਸ਼ਨ ਰੁਕਿਆ ਸੀ।

ਇੱਕੋ ਪ੍ਰੌਕਸੀ ਐਂਡਪੁਆਇੰਟ ਵੀ ਨਵਾਂ ਬਾਹਰੀ ਕਨੈਕਸ਼ਨ ਬਣਾ ਸਕਦਾ ਹੈ। ਬਦਲਿਆ ਐਗਜ਼ਿਟ IP ਮੰਜ਼ਿਲ ਦੀ ਆਪਣੀ ਸੈਸ਼ਨ ਨੀਤੀ ਵੀ ਸਰਗਰਮ ਕਰ ਸਕਦਾ ਹੈ। ਨਵੇਂ ਸਾਕਟ ਨੂੰ ਨਵਾਂ ਕਨੈਕਸ਼ਨ ਮੰਨੋ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਦਸਤਾਵੇਜ਼ੀ ਬਹਾਲੀ ਵਟਾਂਦਰੇ ਦੀ ਪਾਲਣਾ ਕਰੋ। ਦੁਬਾਰਾ ਜੁੜਦੇ ਸਮੇਂ ਕੀ ਵਰਕਫਲੋ ਨੂੰ ਆਪਣਾ ਪ੍ਰੌਕਸੀ ਰਸਤਾ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ ਇਹ ਤੈਅ ਕਰੋ।

ਆਖਰੀ URL ਤੋਂ ਥੋੜ੍ਹਾ ਵੱਧ ਰੱਖੋ

ਲਾਭਦਾਇਕ ਬਹਾਲੀ ਸਥਿਤੀ ਵਿੱਚ ਅਧਿਕਾਰਤ ਸੈਸ਼ਨ ਪਛਾਣ, ਲੋੜੀਂਦੀਆਂ ਸਦੱਸਤਾਵਾਂ, ਆਖਰੀ ਪੁਸ਼ਟੀ ਕੀਤੀ ਘਟਨਾ ਦਾ ਪਛਾਣਕਰਤਾ ਅਤੇ ਅਜੇ ਪੁਸ਼ਟੀ ਦੀ ਉਡੀਕ ਕਰ ਰਹੀਆਂ ਕਾਰਵਾਈਆਂ ਸ਼ਾਮਲ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਉਹ ਖੇਤਰ ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰੋਟੋਕੋਲ ਦੇ ਹਨ; WebSocket ਕੋਈ ਸਰਵਵਿਆਪੀ ਮੁੜ-ਸ਼ੁਰੂ ਟੋਕਨ ਪਰਿਭਾਸ਼ਿਤ ਨਹੀਂ ਕਰਦਾ।

ਕਰਸਰ ਤੋਂ ਮੁੜ ਸ਼ੁਰੂ ਕਰਨਾ, ਨਵਾਂ ਸਨੈਪਸ਼ਾਟ ਲੈਣਾ ਜਾਂ ਅੰਤਰਾਲ ਸਵੀਕਾਰ ਕਰਨਾ ਹੈ ਇਹ ਤੈਅ ਕਰੋ। ਜੇ ਘਟਨਾ ਸਰੋਤ ਕੋਈ ਰੀਪਲੇ ਇੰਟਰਫੇਸ ਨਹੀਂ ਦਿੰਦਾ, ਤਾਂ ਤੇਜ਼ੀ ਨਾਲ ਦੁਬਾਰਾ ਜੁੜਨਾ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰ ਸਕਦਾ ਕਿ ਕੋਈ ਸੁਨੇਹਾ ਖੁੰਝਿਆ ਨਹੀਂ।

ਦੋ ਵਾਰ ਭੇਜਣਾ ਦੋ ਵਾਰ ਕਰਨਾ ਹੋ ਸਕਦਾ ਹੈ

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

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

ਦੁਬਾਰਾ ਜੁੜਨ ਦੀਆਂ ਕੋਸ਼ਿਸ਼ਾਂ ਸੀਮਤ ਰੱਖੋ ਅਤੇ ਰਫ਼ਤਾਰ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਨੀਤੀ ਅਨੁਸਾਰ ਰੱਖੋ। RFC 6455 ਅਸਧਾਰਨ ਬੰਦ ਹੋਣ ਤੋਂ ਬਾਅਦ ਪਿੱਛੇ ਹਟਣ ਦੀ ਸਿਫ਼ਾਰਸ਼ ਕਰਦਾ ਹੈ; ਤੁਰੰਤ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਵਾਲੇ ਕਲਾਇੰਟਾਂ ਦਾ ਸਮੂਹ ਰੁਕਾਵਟ ਦਾ ਭਾਰ ਵਧਾ ਸਕਦਾ ਹੈ।

ਹਰ ਕੋਸ਼ਿਸ਼ ਨੇ ਕਿਹੜਾ ਪ੍ਰੌਕਸੀ ਰਸਤਾ ਚੁਣਿਆ ਇਹ ਦਰਜ ਕਰੋ, ਪਰ ਰਸਤਾ ਬਹਾਲੀ ਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਬਹਾਲੀ ਤੋਂ ਵੱਖ ਰੱਖੋ। “ਦੁਬਾਰਾ ਜੁੜ ਗਏ” ਲਾਭਦਾਇਕ ਸਬੂਤ ਹੈ। “ਬਰਾਬਰ ਆ ਗਏ ਅਤੇ ਹੋਰ ਕੰਮ ਭੇਜਣ ਲਈ ਤਿਆਰ” ਲਈ ਉਹ ਵਾਧੂ ਐਪਲੀਕੇਸ਼ਨ ਵਟਾਂਦਰਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਇਹ ਸਥਾਪਤ ਕਰਦਾ ਹੈ।