OpenVPN ਖਾਤੇ ਪਿੱਛੇ ਮਹੀਨਾਵਾਰ ਡੇਟਾ ਕੋਟਾ ਕਿੱਥੇ ਆਉਂਦਾ ਹੈ

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

ਕੋਟਾ ਟਨਲ ਨਾਲ ਨਹੀਂ, ਖਾਤੇ ਨਾਲ ਬੰਨ੍ਹੋ

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

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

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

ਇਕਾਈ, ਦਿਸ਼ਾ ਅਤੇ ਰੀਸੈਟ ਸੀਮਾ ਤੈਅ ਕਰੋ

ਕੋਈ ਵੀ ਸੰਗ੍ਰਹਿ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਚਾਰ ਪਰਿਭਾਸ਼ਾਵਾਂ ਲਿਖਤੀ ਰੂਪ ਵਿੱਚ ਤੈਅ ਕਰਨੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਕੀ ਕੋਟਾ ਕਲਾਇੰਟ ਵੱਲੋਂ ਭੇਜੇ ਬਾਈਟ, ਪ੍ਰਾਪਤ ਕੀਤੇ ਬਾਈਟ, ਜਾਂ ਦੋਵਾਂ ਦਾ ਜੋੜ ਗਿਣਦਾ ਹੈ? ਕੀ ਇੱਕ ਗੀਗਾਬਾਈਟ 10^9 ਬਾਈਟ ਹੈ ਜਾਂ 2^30? ਕਿਸ ਸਥਾਨਕ ਘੰਟੇ ਅਤੇ ਕਿਸ ਸਮਾਂ ਖੇਤਰ ਵਿੱਚ ਅਵਧੀ ਬਦਲਦੀ ਹੈ? ਅਤੇ ਕਾਊਂਟਰ ਠੀਕ ਕੀ ਮਾਪਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਟਨਲ ਓਵਰਹੈੱਡ ਅਤੇ ਮੁੜ-ਪ੍ਰਸਾਰਣ ਸ਼ਾਮਲ ਹਨ ਪਰ ਐਪਲੀਕੇਸ਼ਨ ਫਾਈਲ ਦਾ ਆਕਾਰ ਅਤੇ ਪ੍ਰਦਾਤਾ ਦਾ ਬਿੱਲ ਨਹੀਂ?

ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਚੋਣ ਗਲਤ ਨਹੀਂ ਹੈ, ਪਰ ਲਾਗੂਆਣ ਅਤੇ ਗਾਹਕ ਵੱਲੋਂ ਦੇਖੀ ਜਾਣ ਵਾਲੀ ਸੰਖਿਆ ਮਿਲਣੀ ਚਾਹੀਦੀ ਹੈ। ਇੱਕੋ ਸਿਸਟਮ ਦੇ ਦੋ ਅੱਧੇ GiB ਬਾਰੇ, ਜਾਂ ਸਥਾਨਕ ਸਮੇਂ ਦੀ ਥਾਂ UTC ਅੱਧੀ ਰਾਤ ਨੂੰ ਹੋਣ ਵਾਲੇ ਬਦਲਾਅ ਬਾਰੇ ਸਹਿਮਤ ਨਾ ਹੋਣ ਤਾਂ ਠੀਕ ਉਸੇ ਕਿਸਮ ਦਾ ਟਿਕਟ ਬਣਦਾ ਹੈ ਜੋ ਪੂਰੇ ਕੋਟੇ 'ਤੇ ਭਰੋਸਾ ਘਟਾਉਂਦਾ ਹੈ।

ਬਾਈਟ ਕੁੱਲ ਨੂੰ ਇੱਕ ਲੱਗੇ ਹੋਏ ਅੰਤਰ ਵਿੱਚ ਬਦਲੋ

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

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

rx_delta = sample.rx_now - session.prev_rx
tx_delta = sample.tx_now - session.prev_tx
charge  = rx_delta + tx_delta
# same transaction:
ledger.total += charge
session.prev_rx, session.prev_tx = sample.rx_now, sample.tx_now

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

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

ਖ਼ਤਮ ਹੋਣਾ ਦਾਖਲਾ ਰੋਕੇ, ਸਿਰਫ਼ ਟਨਲ ਨਾ ਮਾਰੇ

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

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

ਟੋਕਨ-ਆਧਾਰਿਤ ਮੁੜ-ਕਨੈਕਸ਼ਨ ਆਪਣੀ ਵੱਖਰੀ ਪਰਖ ਦੇ ਹੱਕਦਾਰ ਹਨ। OpenVPN 2.6 auth-gen-token ਨਾਲ ਸੈਸ਼ਨ ਟੋਕਨ ਨੂੰ ਅੰਦਰੋਂ ਪ੍ਰਮਾਣਿਤ ਕਰ ਸਕਦਾ ਹੈ, ਤੁਹਾਡੇ ਕੰਟਰੋਲਰ ਵੱਲੋਂ ਸੀਮਾ ਲਾਗੂ ਕਰਨ ਲਈ ਵਰਤੀ ਜਾਂਦੀ ਬਾਹਰੀ ਪ੍ਰਮਾਣੀਕਰਨ ਕਾਲ ਛੱਡ ਕੇ। ਇਸ ਲਈ ਹਾਲੇ ਵੈਧ ਟੋਕਨ ਪਛਾਣ ਸਾਬਤ ਕਰਦਾ ਹੈ, ਬਚਿਆ ਕੋਟਾ ਨਹੀਂ, ਅਤੇ ਹਰ ਨਵੇਂ ਕਲਾਇੰਟ ਇੰਸਟੈਂਸ ਨੂੰ ਫਿਰ ਵੀ ਖਾਤਾ-ਵਹੀ ਨਾਲ ਸਲਾਹ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਇਸਦੀ ਥਾਂ management-client-auth ਚਾਲੂ ਕਰੋ, ਤਾਂ ਕੰਟਰੋਲਰ ਹੀ ਪ੍ਰਮਾਣਕ ਬਣ ਜਾਂਦਾ ਹੈ ਅਤੇ ਸੈਸ਼ਨ ਸਥਿਤੀ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਕੇ ਮਿਆਦ ਪੁੱਗੇ ਜਾਂ ਅਵੈਧ ਟੋਕਨ ਖੁਦ ਰੱਦ ਕਰਨ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਵਿਰਾਸਤ ਵਿੱਚ ਲੈਂਦਾ ਹੈ।

ਨਮੂਨਾਕਰਨ ਜੋ ਵਾਧੂ ਖਪਤ ਪੈਦਾ ਕਰਦਾ ਹੈ, ਸਵੀਕਾਰ ਕਰੋ

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

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

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