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

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

ਆਮ ਤੌਰ 'ਤੇ, ਨੈੱਟਵਰਕ ਆਰਕੀਟੈਕਚਰ ਦੀਆਂ ਦੋ ਮੁੱਖ ਕਿਸਮਾਂ ਹਨ: ਪੀਅਰ-ਟੂ-ਪੀਅਰ ਅਤੇ ਕਲਾਇੰਟ-ਸਰਵਰ। ਇੱਕ ਪੀਅਰ-ਟੂ-ਪੀਅਰ (ਪੀ2ਪੀ) ਆਰਕੀਟੈਕਚਰ ਵਿੱਚ, ਕਿਸੇ ਵੀ ਜੋੜੇ ਨਾਲ ਜੁੜੇ ਖਿਡਾਰੀਆਂ ਦੇ ਵਿਚਕਾਰ ਡੇਟਾ ਟ੍ਰਾਂਸਫਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਇੱਕ ਕਲਾਇੰਟ-ਸਰਵਰ ਆਰਕੀਟੈਕਚਰ ਵਿੱਚ, ਡੇਟਾ ਸਿਰਫ ਪਲੇਅਰਾਂ ਅਤੇ ਸਰਵਰ ਵਿਚਕਾਰ ਟ੍ਰਾਂਸਫਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

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

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

ਨੈੱਟਵਰਕ ਗੇਮਿੰਗ ਸਿਸਟਮ ਦੇ ਤਿੰਨ ਮੁੱਖ ਭਾਗ ਹਨ:

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

ਹਰੇਕ ਹਿੱਸੇ ਦੀ ਭੂਮਿਕਾ ਅਤੇ ਉਨ੍ਹਾਂ ਨਾਲ ਜੁੜੀਆਂ ਚੁਣੌਤੀਆਂ ਨੂੰ ਸਮਝਣਾ ਬਹੁਤ ਜ਼ਰੂਰੀ ਹੈ।

ਟ੍ਰਾਂਸਪੋਰਟ ਪ੍ਰੋਟੋਕੋਲ

ਪਹਿਲਾ ਕਦਮ ਹੈ ਸਰਵਰ ਅਤੇ ਗਾਹਕਾਂ ਵਿਚਕਾਰ ਡੇਟਾ ਟ੍ਰਾਂਸਪੋਰਟ ਕਰਨ ਲਈ ਇੱਕ ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਚੋਣ ਕਰਨਾ. ਇਸਦੇ ਲਈ ਦੋ ਇੰਟਰਨੈਟ ਪ੍ਰੋਟੋਕੋਲ ਹਨ: TCP и UDP. ਪਰ ਤੁਸੀਂ ਉਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਦੇ ਅਧਾਰ ਤੇ ਆਪਣਾ ਖੁਦ ਦਾ ਟ੍ਰਾਂਸਪੋਰਟ ਪ੍ਰੋਟੋਕੋਲ ਬਣਾ ਸਕਦੇ ਹੋ ਜਾਂ ਉਹਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲੀ ਲਾਇਬ੍ਰੇਰੀ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ।

TCP ਅਤੇ UDP ਦੀ ਤੁਲਨਾ

TCP ਅਤੇ UDP ਦੋਵੇਂ ਆਧਾਰਿਤ ਹਨ IP. IP ਇੱਕ ਪੈਕੇਟ ਨੂੰ ਇੱਕ ਸਰੋਤ ਤੋਂ ਪ੍ਰਾਪਤਕਰਤਾ ਤੱਕ ਪ੍ਰਸਾਰਿਤ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ, ਪਰ ਇਹ ਗਾਰੰਟੀ ਨਹੀਂ ਦਿੰਦਾ ਹੈ ਕਿ ਭੇਜਿਆ ਗਿਆ ਪੈਕੇਟ ਜਲਦੀ ਜਾਂ ਬਾਅਦ ਵਿੱਚ ਪ੍ਰਾਪਤਕਰਤਾ ਤੱਕ ਪਹੁੰਚ ਜਾਵੇਗਾ, ਕਿ ਇਹ ਘੱਟੋ ਘੱਟ ਇੱਕ ਵਾਰ ਇਸ ਤੱਕ ਪਹੁੰਚੇਗਾ, ਅਤੇ ਇਹ ਕਿ ਪੈਕੇਟ ਦਾ ਕ੍ਰਮ ਸਹੀ ਵਿੱਚ ਆਵੇਗਾ। ਆਰਡਰ ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇੱਕ ਪੈਕੇਟ ਵਿੱਚ ਮੁੱਲ ਦੁਆਰਾ ਦਿੱਤੇ ਗਏ ਡੇਟਾ ਦੀ ਇੱਕ ਸੀਮਤ ਮਾਤਰਾ ਹੀ ਹੋ ਸਕਦੀ ਹੈ MTU.

UDP IP ਦੇ ਸਿਖਰ 'ਤੇ ਸਿਰਫ਼ ਇੱਕ ਪਤਲੀ ਪਰਤ ਹੈ। ਇਸ ਲਈ, ਇਸ ਦੀਆਂ ਉਹੀ ਸੀਮਾਵਾਂ ਹਨ. ਇਸਦੇ ਉਲਟ, TCP ਵਿੱਚ ਬਹੁਤ ਸਾਰੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਹਨ। ਇਹ ਗਲਤੀ ਦੀ ਜਾਂਚ ਦੇ ਨਾਲ ਦੋ ਨੋਡਾਂ ਦੇ ਵਿਚਕਾਰ ਇੱਕ ਭਰੋਸੇਮੰਦ, ਕ੍ਰਮਬੱਧ ਕੁਨੈਕਸ਼ਨ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਇਸ ਲਈ, TCP ਬਹੁਤ ਸੁਵਿਧਾਜਨਕ ਹੈ ਅਤੇ ਕਈ ਹੋਰ ਪ੍ਰੋਟੋਕੋਲਾਂ ਵਿੱਚ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ HTTP ਨੂੰ, FTP, и SMTP. ਪਰ ਇਹ ਸਾਰੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਇੱਕ ਕੀਮਤ 'ਤੇ ਆਉਂਦੀਆਂ ਹਨ: ਦੇਰੀ.

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

ਪਰ ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਸ਼ਾਇਦ ਕਲਪਨਾ ਕਰ ਸਕਦੇ ਹੋ, ਮਲਟੀਪਲੇਅਰ ਗੇਮਾਂ ਵਿੱਚ ਲੇਟੈਂਸੀ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਖਾਸ ਕਰਕੇ ਐਕਸ਼ਨ-ਪੈਕ ਸ਼ੈਲੀਆਂ ਜਿਵੇਂ ਕਿ FPS ਵਿੱਚ। ਇਹੀ ਕਾਰਨ ਹੈ ਕਿ ਬਹੁਤ ਸਾਰੀਆਂ ਗੇਮਾਂ ਆਪਣੇ ਖੁਦ ਦੇ ਪ੍ਰੋਟੋਕੋਲ ਨਾਲ UDP ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ।

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

ਇਸ ਲਈ, ਜੇਕਰ TCP ਇੰਨਾ ਚੂਸਦਾ ਹੈ, ਤਾਂ ਅਸੀਂ UDP ਦੇ ਅਧਾਰ ਤੇ ਆਪਣਾ ਖੁਦ ਦਾ ਟ੍ਰਾਂਸਪੋਰਟ ਪ੍ਰੋਟੋਕੋਲ ਬਣਾਵਾਂਗੇ?

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

ਵਰਲਡ ਆਫ ਵਾਰਕਰਾਫਟ, ਮਾਇਨਕਰਾਫਟ ਅਤੇ ਟੈਰੇਰੀਆ ਸਮੇਤ ਕਈ ਸਫਲ ਗੇਮਾਂ, ਟੀਸੀਪੀ ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ। ਹਾਲਾਂਕਿ, ਜ਼ਿਆਦਾਤਰ FPSs ਆਪਣੇ ਖੁਦ ਦੇ UDP-ਅਧਾਰਿਤ ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ, ਇਸਲਈ ਅਸੀਂ ਹੇਠਾਂ ਉਹਨਾਂ ਬਾਰੇ ਹੋਰ ਗੱਲ ਕਰਾਂਗੇ।

ਜੇਕਰ ਤੁਸੀਂ TCP ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕਰਦੇ ਹੋ, ਤਾਂ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਇਹ ਅਯੋਗ ਹੈ ਨਾਗਲੇ ਦਾ ਐਲਗੋਰਿਦਮ, ਕਿਉਂਕਿ ਇਹ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਪੈਕੇਟਾਂ ਨੂੰ ਬਫਰ ਕਰਦਾ ਹੈ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇਹ ਲੇਟੈਂਸੀ ਨੂੰ ਵਧਾਉਂਦਾ ਹੈ।

ਮਲਟੀਪਲੇਅਰ ਗੇਮਾਂ ਦੇ ਸੰਦਰਭ ਵਿੱਚ UDP ਅਤੇ TCP ਵਿੱਚ ਅੰਤਰ ਬਾਰੇ ਹੋਰ ਜਾਣਨ ਲਈ, ਤੁਸੀਂ ਗਲੇਨ ਫਿਡਲਰ ਦਾ ਲੇਖ ਪੜ੍ਹ ਸਕਦੇ ਹੋ UDP ਬਨਾਮ. ਟੀ.ਸੀ.ਪੀ.

ਆਪਣਾ ਪ੍ਰੋਟੋਕੋਲ

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

ਪਹਿਲਾ ਲੇਖ ਗੇਮ ਪ੍ਰੋਗਰਾਮਰਾਂ ਲਈ ਨੈੱਟਵਰਕਿੰਗ 2008, ਦੂਜੇ ਨਾਲੋਂ ਸੌਖਾ, ਇੱਕ ਗੇਮ ਨੈੱਟਵਰਕ ਪ੍ਰੋਟੋਕੋਲ ਬਣਾਉਣਾ 2016. ਮੈਂ ਸਿਫਾਰਸ਼ ਕਰਦਾ ਹਾਂ ਕਿ ਤੁਸੀਂ ਪੁਰਾਣੇ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ.

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

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

ਨੈੱਟਵਰਕ ਲਾਇਬ੍ਰੇਰੀਆਂ

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

• yojimbo ਗਲੇਨ ਫੀਡਲਰ
• RakNet, ਜੋ ਹੁਣ ਸਮਰਥਿਤ ਨਹੀਂ ਹੈ, ਪਰ ਇਸਦਾ ਇੱਕ ਫੋਰਕ ਹੈ SLikeNet ਇੰਝ ਲੱਗਦਾ ਹੈ ਕਿ ਇਹ ਅਜੇ ਵੀ ਕਿਰਿਆਸ਼ੀਲ ਹੈ।
• ENet ਮਲਟੀਪਲੇਅਰ FPS ਲਈ ਬਣਾਈ ਗਈ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ ਹੈ ਘਣ
• ਗੇਮਨੈੱਟਵਰਕਿੰਗ ਸਾਕਟ ਵਾਲਵ

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

ਟ੍ਰਾਂਸਪੋਰਟ ਪ੍ਰੋਟੋਕੋਲ: ਸਿੱਟਾ

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

TCP, UDP ਅਤੇ ਲਾਇਬ੍ਰੇਰੀ ਵਿਚਕਾਰ ਚੋਣ ਕਈ ਕਾਰਕਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ। ਪਹਿਲਾਂ, ਖੇਡ ਦੀਆਂ ਲੋੜਾਂ ਤੋਂ: ਕੀ ਇਸ ਨੂੰ ਘੱਟ ਲੇਟੈਂਸੀ ਦੀ ਲੋੜ ਹੈ? ਦੂਜਾ, ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰੋਟੋਕੋਲ ਦੀਆਂ ਜ਼ਰੂਰਤਾਂ ਤੋਂ: ਕੀ ਇਸ ਨੂੰ ਭਰੋਸੇਯੋਗ ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਲੋੜ ਹੈ? ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਅਗਲੇ ਭਾਗ ਵਿੱਚ ਦੇਖਾਂਗੇ, ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰੋਟੋਕੋਲ ਬਣਾਉਣਾ ਸੰਭਵ ਹੈ ਜਿਸ ਲਈ ਇੱਕ ਅਵਿਸ਼ਵਾਸ ਪ੍ਰੋਟੋਕੋਲ ਕਾਫ਼ੀ ਢੁਕਵਾਂ ਹੈ। ਅੰਤ ਵਿੱਚ, ਤੁਹਾਨੂੰ ਨੈੱਟਵਰਕ ਇੰਜਨ ਡਿਵੈਲਪਰ ਦੇ ਤਜ਼ਰਬੇ ਨੂੰ ਵੀ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣ ਦੀ ਲੋੜ ਹੈ।

ਮੇਰੇ ਕੋਲ ਸਲਾਹ ਦੇ ਦੋ ਟੁਕੜੇ ਹਨ:

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

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

ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰੋਟੋਕੋਲ

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

ਕਲਾਸਿਕ ਸਕੀਮ ਇਹ ਹੈ ਕਿ ਕਲਾਇੰਟ ਸਰਵਰ ਨੂੰ ਇਨਪੁਟ ਜਾਂ ਐਕਸ਼ਨ ਭੇਜਦੇ ਹਨ, ਅਤੇ ਸਰਵਰ ਕਲਾਇੰਟਸ ਨੂੰ ਮੌਜੂਦਾ ਗੇਮ ਸਟੇਟ ਭੇਜਦਾ ਹੈ।

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

ਸੀਰੀਅਲਾਈਜ਼ੇਸ਼ਨ

ਪਹਿਲਾ ਕਦਮ ਹੈ ਉਹ ਡੇਟਾ ਜਿਸ ਨੂੰ ਅਸੀਂ ਭੇਜਣਾ ਚਾਹੁੰਦੇ ਹਾਂ (ਇਨਪੁਟ ਜਾਂ ਗੇਮ ਸਟੇਟ) ਨੂੰ ਪ੍ਰਸਾਰਣ ਲਈ ਢੁਕਵੇਂ ਫਾਰਮੈਟ ਵਿੱਚ ਬਦਲਣਾ। ਇਸ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਕਿਹਾ ਜਾਂਦਾ ਹੈ ਸੀਰੀਅਲਾਈਜ਼ੇਸ਼ਨ.

ਇਹ ਵਿਚਾਰ ਜੋ ਤੁਰੰਤ ਮਨ ਵਿੱਚ ਆਉਂਦਾ ਹੈ ਇੱਕ ਮਨੁੱਖੀ-ਪੜ੍ਹਨ ਯੋਗ ਫਾਰਮੈਟ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਹੈ, ਜਿਵੇਂ ਕਿ JSON ਜਾਂ XML. ਪਰ ਇਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬੇਅਸਰ ਹੋ ਜਾਵੇਗਾ ਅਤੇ ਜ਼ਿਆਦਾਤਰ ਚੈਨਲ ਨੂੰ ਬਰਬਾਦ ਕਰੇਗਾ.

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

ਡੇਟਾ ਨੂੰ ਲੜੀਬੱਧ ਕਰਨ ਲਈ, ਤੁਸੀਂ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ, ਉਦਾਹਰਨ ਲਈ:

• ਫਲੈਟਬਰਫਰਸ ਗੂਗਲ
• ਕੈਪ'ਨ ਪ੍ਰੋਟੋ ਰੇਤ ਦਾ ਤੂਫਾਨ ਕੰਪਨੀ
• ਅਨਾਜ ਸ਼ੇਨ ਗ੍ਰਾਂਟ ਅਤੇ ਰੈਂਡੋਲਫ ਵੂਰਹੀਸ

ਬਸ ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਲਾਇਬ੍ਰੇਰੀ ਪੋਰਟੇਬਲ ਆਰਕਾਈਵਜ਼ ਬਣਾਉਂਦੀ ਹੈ ਅਤੇ ਅੰਤ ਦੀ ਪਰਵਾਹ ਕਰਦੀ ਹੈ।

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

ਗਲੇਨ ਫੀਡਲਰ ਨੇ ਲੜੀਵਾਰਤਾ ਬਾਰੇ ਦੋ ਲੇਖ ਲਿਖੇ: ਪੈਕਟ ਪੜ੍ਹਨਾ ਅਤੇ ਲਿਖਣਾ и ਸੀਰੀਅਲਾਈਜ਼ੇਸ਼ਨ ਰਣਨੀਤੀਆਂ.

ਦਬਾਅ

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

ਬਿੱਟ ਪੈਕੇਜਿੰਗ

ਪਹਿਲੀ ਤਕਨੀਕ ਬਿੱਟ ਪੈਕਿੰਗ ਹੈ. ਇਸ ਵਿੱਚ ਬਿੱਟਾਂ ਦੀ ਬਿਲਕੁਲ ਸੰਖਿਆ ਦੀ ਵਰਤੋਂ ਸ਼ਾਮਲ ਹੁੰਦੀ ਹੈ ਜੋ ਲੋੜੀਂਦੇ ਮੁੱਲ ਦਾ ਵਰਣਨ ਕਰਨ ਲਈ ਜ਼ਰੂਰੀ ਹੁੰਦੇ ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਐਨਮ ਹੈ ਜਿਸ ਵਿੱਚ 16 ਵੱਖ-ਵੱਖ ਮੁੱਲ ਹੋ ਸਕਦੇ ਹਨ, ਤਾਂ ਪੂਰੇ ਬਾਈਟ (8 ਬਿੱਟ) ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਸਿਰਫ਼ 4 ਬਿੱਟਾਂ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ।

ਗਲੇਨ ਫੀਡਲਰ ਲੇਖ ਦੇ ਦੂਜੇ ਭਾਗ ਵਿੱਚ ਇਸ ਨੂੰ ਕਿਵੇਂ ਲਾਗੂ ਕਰਨਾ ਹੈ ਬਾਰੇ ਦੱਸਦਾ ਹੈ ਪੈਕਟ ਪੜ੍ਹਨਾ ਅਤੇ ਲਿਖਣਾ.

ਬਿੱਟ ਪੈਕਿੰਗ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਨਮੂਨੇ ਦੇ ਨਾਲ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦੀ ਹੈ, ਜੋ ਕਿ ਅਗਲੇ ਭਾਗ ਦਾ ਵਿਸ਼ਾ ਹੋਵੇਗਾ।

ਨਮੂਨਾ

ਨਮੂਨਾ ਇੱਕ ਨੁਕਸਾਨਦਾਇਕ ਕੰਪਰੈਸ਼ਨ ਤਕਨੀਕ ਹੈ ਜੋ ਕਿਸੇ ਮੁੱਲ ਨੂੰ ਏਨਕੋਡ ਕਰਨ ਲਈ ਸੰਭਵ ਮੁੱਲਾਂ ਦੇ ਸਿਰਫ ਇੱਕ ਉਪ ਸਮੂਹ ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ। ਵਿਵੇਕੀਕਰਨ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦਾ ਸਭ ਤੋਂ ਆਸਾਨ ਤਰੀਕਾ ਫਲੋਟਿੰਗ ਪੁਆਇੰਟ ਨੰਬਰਾਂ ਨੂੰ ਗੋਲ ਕਰਨਾ ਹੈ।

ਗਲੇਨ ਫੀਡਲਰ (ਦੁਬਾਰਾ!) ਆਪਣੇ ਲੇਖ ਵਿੱਚ ਨਮੂਨੇ ਨੂੰ ਅਭਿਆਸ ਵਿੱਚ ਕਿਵੇਂ ਲਿਆਉਣਾ ਹੈ, ਇਹ ਦਿਖਾਉਂਦਾ ਹੈ ਸਨੈਪਸ਼ਾਟ ਕੰਪਰੈਸ਼ਨ.

ਕੰਪਰੈਸ਼ਨ ਐਲਗੋਰਿਦਮ

ਅਗਲੀ ਤਕਨੀਕ ਨੁਕਸਾਨ ਰਹਿਤ ਕੰਪਰੈਸ਼ਨ ਐਲਗੋਰਿਦਮ ਹੋਵੇਗੀ।

ਇੱਥੇ, ਮੇਰੀ ਰਾਏ ਵਿੱਚ, ਤਿੰਨ ਸਭ ਤੋਂ ਦਿਲਚਸਪ ਐਲਗੋਰਿਦਮ ਹਨ ਜੋ ਤੁਹਾਨੂੰ ਜਾਣਨ ਦੀ ਲੋੜ ਹੈ:

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

ਡੈਲਟਾ ਕੰਪਰੈਸ਼ਨ

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

ਇਹ ਸਭ ਤੋਂ ਪਹਿਲਾਂ Quake3 ਨੈੱਟਵਰਕ ਇੰਜਣ ਵਿੱਚ ਵਰਤਿਆ ਗਿਆ ਸੀ। ਇੱਥੇ ਦੋ ਲੇਖ ਦੱਸੇ ਗਏ ਹਨ ਕਿ ਇਸਨੂੰ ਕਿਵੇਂ ਵਰਤਣਾ ਹੈ:

• Quake3 ਨੈੱਟਵਰਕਿੰਗ ਮਾਡਲ ਬ੍ਰਾਇਨ ਹੁੱਕ
• ਭੂਚਾਲ 3 ਸਰੋਤ ਕੋਡ ਸਮੀਖਿਆ: ਨੈੱਟਵਰਕ ਮਾਡਲ ਫੈਬੀਅਨ ਸੰਗਲਰਸ [ਅਨੁਵਾਦ ਹੈਬਰੇ 'ਤੇ ਲੇਖ, ਭਾਗ "ਨੈੱਟਵਰਕ ਮਾਡਲ" ਦੇਖੋ]

ਗਲੇਨ ਫੀਡਲਰ ਨੇ ਵੀ ਆਪਣੇ ਲੇਖ ਦੇ ਦੂਜੇ ਭਾਗ ਵਿੱਚ ਇਸਦੀ ਵਰਤੋਂ ਕੀਤੀ ਹੈ ਸਨੈਪਸ਼ਾਟ ਕੰਪਰੈਸ਼ਨ.

ਇਨਕ੍ਰਿਪਸ਼ਨ

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਤੁਹਾਨੂੰ ਕਲਾਇੰਟਸ ਅਤੇ ਸਰਵਰ ਵਿਚਕਾਰ ਜਾਣਕਾਰੀ ਦੇ ਟ੍ਰਾਂਸਫਰ ਨੂੰ ਐਨਕ੍ਰਿਪਟ ਕਰਨ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ। ਇਸਦੇ ਕਈ ਕਾਰਨ ਹਨ:

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

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

ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰੋਟੋਕੋਲ: ਸਿੱਟਾ

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

ਐਪਲੀਕੇਸ਼ਨ ਤਰਕ

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

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਦੋ ਰਾਜ ਅਪਡੇਟਾਂ ਦੇ ਵਿਚਕਾਰ, ਸੰਸਾਰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਥਿਰ ਹੈ. ਜੇ ਸਟੇਟ ਅਪਡੇਟ ਰੇਟ ਘੱਟ ਹੈ, ਤਾਂ ਅੰਦੋਲਨ ਬਹੁਤ ਝਟਕੇਦਾਰ ਹੋਣਗੇ.

ਇਸ ਸਮੱਸਿਆ ਦੇ ਪ੍ਰਭਾਵ ਨੂੰ ਘਟਾਉਣ ਲਈ ਕਈ ਤਕਨੀਕਾਂ ਹਨ, ਅਤੇ ਮੈਂ ਉਹਨਾਂ ਨੂੰ ਅਗਲੇ ਭਾਗ ਵਿੱਚ ਕਵਰ ਕਰਾਂਗਾ।

ਲੇਟੈਂਸੀ ਸਮੂਥਿੰਗ ਤਕਨੀਕਾਂ

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

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

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

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

ਗਲੇਨ ਫੀਡਲਰ (ਹਮੇਸ਼ਾ ਵਾਂਗ!) ਨੇ 2004 ਵਿੱਚ ਇੱਕ ਲੇਖ ਲਿਖਿਆ ਸੀ ਨੈੱਟਵਰਕ ਭੌਤਿਕ ਵਿਗਿਆਨ (2004), ਜਿਸ ਵਿੱਚ ਉਸਨੇ ਸਰਵਰ ਅਤੇ ਕਲਾਇੰਟ ਵਿਚਕਾਰ ਭੌਤਿਕ ਵਿਗਿਆਨ ਸਿਮੂਲੇਸ਼ਨਾਂ ਨੂੰ ਸਮਕਾਲੀ ਕਰਨ ਦੀ ਨੀਂਹ ਰੱਖੀ। 2014 ਵਿੱਚ ਉਸਨੇ ਲੇਖਾਂ ਦੀ ਇੱਕ ਨਵੀਂ ਲੜੀ ਲਿਖੀ ਨੈੱਟਵਰਕਿੰਗ ਭੌਤਿਕ ਵਿਗਿਆਨ, ਜਿਸ ਨੇ ਭੌਤਿਕ ਵਿਗਿਆਨ ਦੇ ਸਿਮੂਲੇਸ਼ਨਾਂ ਨੂੰ ਸਮਕਾਲੀ ਕਰਨ ਲਈ ਹੋਰ ਤਕਨੀਕਾਂ ਦਾ ਵਰਣਨ ਕੀਤਾ ਹੈ।

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

ਧੋਖਾਧੜੀ ਨੂੰ ਰੋਕਣਾ

ਧੋਖਾਧੜੀ ਨੂੰ ਰੋਕਣ ਲਈ ਦੋ ਮੁੱਖ ਤਕਨੀਕਾਂ ਹਨ।

ਪਹਿਲਾ: ਧੋਖੇਬਾਜ਼ਾਂ ਲਈ ਖਤਰਨਾਕ ਪੈਕੇਟ ਭੇਜਣਾ ਹੋਰ ਵੀ ਔਖਾ ਬਣਾਉਣਾ। ਜਿਵੇਂ ਕਿ ਉੱਪਰ ਦੱਸਿਆ ਗਿਆ ਹੈ, ਇਸ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦਾ ਇੱਕ ਵਧੀਆ ਤਰੀਕਾ ਏਨਕ੍ਰਿਪਸ਼ਨ ਹੈ।

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

ਐਪਲੀਕੇਸ਼ਨ ਤਰਕ: ਸਿੱਟਾ

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

ਹੋਰ ਮਦਦਗਾਰ ਸਰੋਤ

ਜੇਕਰ ਤੁਸੀਂ ਨੈੱਟਵਰਕ ਮਾਡਲਾਂ 'ਤੇ ਹੋਰ ਸਰੋਤਾਂ ਦੀ ਪੜਚੋਲ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਇੱਥੇ ਲੱਭ ਸਕਦੇ ਹੋ:

• ਗਲੇਨ ਫਿਡਲਰ ਦਾ ਬਲੌਗ - ਉਸਦਾ ਪੂਰਾ ਬਲੌਗ ਪੜ੍ਹਨ ਯੋਗ ਹੈ, ਉੱਥੇ ਬਹੁਤ ਸਾਰੇ ਵਧੀਆ ਲੇਖ ਹਨ. ਇਹ ਇਸ ਲਈ ਹੈ ਨੈੱਟਵਰਕ ਤਕਨੀਕਾਂ ਦੇ ਸਾਰੇ ਲੇਖ ਇਕੱਠੇ ਕੀਤੇ ਗਏ ਹਨ।
• ਸ਼ਾਨਦਾਰ ਗੇਮ ਨੈੱਟਵਰਕਿੰਗ M. Fatih MAR ਦੁਆਰਾ ਔਨਲਾਈਨ ਵੀਡੀਓ ਗੇਮ ਇੰਜਣਾਂ 'ਤੇ ਲੇਖਾਂ ਅਤੇ ਵੀਡੀਓਜ਼ ਦੀ ਇੱਕ ਵਿਆਪਕ ਸੂਚੀ ਹੈ।
• В r/gamedev subreddit ਦਾ ਵਿਕੀ ਬਹੁਤ ਸਾਰੇ ਉਪਯੋਗੀ ਲਿੰਕ ਵੀ ਹਨ.

ਸਰੋਤ: www.habr.com