VPN ਕਨੈਕਸ਼ਨ ਸੀਮਾਵਾਂ: ਲਾਈਵ ਸਥਿਤੀ ਬਨਾਮ ਸੰਭਾਲਿਆ ਇਤਿਹਾਸ

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

ਤੰਤਰ: ਸਲਾਟ ਸਾਰਣੀ, ਲਾਗ ਨਹੀਂ

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

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

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

ਲਾਈਵ ਮਾਡਲ ਨੂੰ ਅਜੇ ਵੀ ਤਾਲਮੇਲ ਕਿਉਂ ਚਾਹੀਦਾ ਹੈ

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

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

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

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

ਉਹ ਸਥਿਤੀ ਅੱਗੇ ਕਿੱਥੇ ਜਾਂਦੀ ਹੈ

ਗੋਪਨੀਯਤਾ ਦਾ ਸਵਾਲ ਇਹ ਨਹੀਂ ਕਿ ਸਰਵਰ ਗਿਣ ਸਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਪੁੱਛੋ ਕਿ ਖ਼ਤਮ ਹੋਏ ਸੈਸ਼ਨ ਦਾ ਕੀ ਹੁੰਦਾ ਹੈ: ਰਿਕਾਰਡ ਹਟਾਇਆ ਜਾਂਦਾ ਹੈ, ਜਾਂ ਉਹ ਨਿਗਰਾਨੀ ਲੜੀ ਵਿੱਚ ਘਟਨਾ ਬਣ ਜਾਂਦਾ ਹੈ? ਫਿਰ ਪੁੱਛੋ ਕਿ ਉਹੀ ਘਟਨਾ ਕਿਹੜੇ ਹੋਰ ਹਿੱਸਿਆਂ ਨੇ ਵੇਖੀ, ਕਿਉਂਕਿ ਪ੍ਰਮਾਣੀਕਰਨ ਲਾਗ, ਲੇਖਾ ਰਿਕਾਰਡ ਅਤੇ ਬੈਕਅਪ ਹਰ ਇੱਕ ਉਹ ਨਕਲ ਰੱਖ ਸਕਦੇ ਹਨ ਜੋ ਲਾਗੂ ਕਰਨ ਦੇ ਰਾਹ ਨੇ ਛੱਡ ਦਿੱਤੀ ਸੀ।

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

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

ਸਵਾਲ ਨੂੰ ਖੇਤਰਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਪੁੱਛੋ

RFC 6973 ਦੀ ਡੇਟਾ-ਘਟਾਓ ਸੇਧ ਇਕੱਠਾ ਕੀਤਾ ਅਤੇ ਸੰਭਾਲਿਆ ਡੇਟਾ ਸੇਵਾ ਦਿੱਤੇ ਜਾਂਦੇ ਉਦੇਸ਼ ਨਾਲ ਜੋੜਦੀ ਹੈ। ਇੱਥੇ ਲਾਗੂ ਕਰਨ 'ਤੇ, ਲਾਭਦਾਇਕ ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਇੱਕੋ ਸਮੇਂ ਦਾਖਲੇ ਦੇ ਕੰਮ ਨੂੰ ਅਸਲ ਵਿੱਚ ਕਿਹੜੇ ਖੇਤਰ ਚਾਹੀਦੇ ਹਨ, ਅਤੇ ਉਹ ਕੰਮ ਖ਼ਤਮ ਹੋਣ ਮਗਰੋਂ ਹਰ ਇੱਕ ਨੂੰ ਰੱਖਣ ਦਾ ਕਿਹੜਾ ਉਦੇਸ਼ ਜਾਇਜ਼ ਠਹਿਰਾਉਂਦਾ ਹੈ।

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

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