ਜਾਣ ਪਛਾਣ

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

ਇਸਦੀ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਇੱਕ ਉਦਾਹਰਣ ਵਜੋਂ, ਅਸੀਂ ਇੱਕ ਮਲਟੀਪਲੇਅਰ ਗੇਮ ਨੂੰ ਵੈੱਬ 'ਤੇ ਪੋਰਟ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਅਤੇ ਚੁਣਿਆ Teeworlds. Teeworlds ਇੱਕ ਮਲਟੀਪਲੇਅਰ 2D ਰੈਟਰੋ ਗੇਮ ਹੈ ਜਿਸ ਵਿੱਚ ਖਿਡਾਰੀਆਂ ਦੇ ਇੱਕ ਛੋਟੇ ਪਰ ਕਿਰਿਆਸ਼ੀਲ ਭਾਈਚਾਰੇ (ਮੇਰੇ ਸਮੇਤ!) ਹਨ। ਇਹ ਡਾਊਨਲੋਡ ਕੀਤੇ ਸਰੋਤਾਂ ਅਤੇ CPU ਅਤੇ GPU ਲੋੜਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਛੋਟਾ ਹੈ - ਇੱਕ ਆਦਰਸ਼ ਉਮੀਦਵਾਰ।

Teeworlds ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਚੱਲ ਰਿਹਾ ਹੈ

ਅਸੀਂ ਇਸ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਪ੍ਰਯੋਗ ਕਰਨ ਲਈ ਵਰਤਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ ਨੈੱਟਵਰਕ ਕੋਡ ਨੂੰ ਵੈੱਬ 'ਤੇ ਪੋਰਟ ਕਰਨ ਲਈ ਆਮ ਹੱਲ. ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਹੇਠ ਲਿਖੇ ਤਰੀਕਿਆਂ ਨਾਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ:

• XMLHttpRequest/fatch, ਜੇਕਰ ਨੈੱਟਵਰਕ ਭਾਗ ਵਿੱਚ ਸਿਰਫ਼ HTTP ਬੇਨਤੀਆਂ ਸ਼ਾਮਲ ਹੁੰਦੀਆਂ ਹਨ, ਜਾਂ
• ਵੈਬਸੌਕੇਟ.

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

ਇੱਕ ਤੀਜਾ ਤਰੀਕਾ ਹੈ - ਬ੍ਰਾਊਜ਼ਰ ਤੋਂ ਨੈੱਟਵਰਕ ਦੀ ਵਰਤੋਂ ਕਰੋ: WebRTC.

RTCDataChannel ਇਹ ਭਰੋਸੇਮੰਦ ਅਤੇ ਗੈਰ-ਭਰੋਸੇਯੋਗ ਪ੍ਰਸਾਰਣ ਦੋਨਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ (ਬਾਅਦ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਜਦੋਂ ਵੀ ਸੰਭਵ ਹੋਵੇ ਇੱਕ ਟਰਾਂਸਪੋਰਟ ਪ੍ਰੋਟੋਕੋਲ ਵਜੋਂ UDP ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ), ਅਤੇ ਇੱਕ ਰਿਮੋਟ ਸਰਵਰ ਅਤੇ ਬ੍ਰਾਊਜ਼ਰਾਂ ਦੇ ਵਿਚਕਾਰ ਦੋਵਾਂ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਅਸੀਂ ਸਰਵਰ ਕੰਪੋਨੈਂਟ ਸਮੇਤ, ਪੂਰੀ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਪੋਰਟ ਕਰ ਸਕਦੇ ਹਾਂ!

ਹਾਲਾਂਕਿ, ਇਹ ਇੱਕ ਵਾਧੂ ਮੁਸ਼ਕਲ ਨਾਲ ਆਉਂਦਾ ਹੈ: ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਦੋ WebRTC ਸਾਥੀ ਸੰਚਾਰ ਕਰ ਸਕਣ, ਉਹਨਾਂ ਨੂੰ ਕਨੈਕਟ ਕਰਨ ਲਈ ਇੱਕ ਮੁਕਾਬਲਤਨ ਗੁੰਝਲਦਾਰ ਹੈਂਡਸ਼ੇਕ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਜਿਸ ਲਈ ਕਈ ਥਰਡ-ਪਾਰਟੀ ਸੰਸਥਾਵਾਂ (ਇੱਕ ਸਿਗਨਲ ਸਰਵਰ ਅਤੇ ਇੱਕ ਜਾਂ ਵੱਧ ਸਰਵਰ) ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ STUN/ਟਰਨ).

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

ਇਹ ਸਾਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਕੋਡ ਵਿੱਚ ਗੁੰਝਲਦਾਰ ਵੇਰਵਿਆਂ ਦਾ ਖੁਲਾਸਾ ਕੀਤੇ ਬਿਨਾਂ WebRTC ਦਾ ਲਾਭ ਲੈਣ ਦੀ ਇਜਾਜ਼ਤ ਦੇਵੇਗਾ (ਜਿਸ ਨੂੰ ਅਸੀਂ ਆਪਣੇ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਘੱਟ ਤੋਂ ਘੱਟ ਬਦਲਣਾ ਚਾਹੁੰਦੇ ਸੀ)।

ਘੱਟੋ-ਘੱਟ WebRTC

WebRTC ਬ੍ਰਾਊਜ਼ਰਾਂ ਵਿੱਚ ਉਪਲਬਧ API ਦਾ ਇੱਕ ਸਮੂਹ ਹੈ ਜੋ ਆਡੀਓ, ਵੀਡੀਓ ਅਤੇ ਮਨਮਾਨੇ ਡੇਟਾ ਦਾ ਪੀਅਰ-ਟੂ-ਪੀਅਰ ਟ੍ਰਾਂਸਮਿਸ਼ਨ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

ਆਈਸੀਈ ਨਾਮਕ ਇੱਕ ਵਿਧੀ ਰਾਹੀਂ STUN ਅਤੇ/ਜਾਂ ਟਰਨ ਸਰਵਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਸਾਥੀਆਂ ਵਿਚਕਾਰ ਸਬੰਧ ਸਥਾਪਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (ਭਾਵੇਂ ਇੱਕ ਜਾਂ ਦੋਵੇਂ ਪਾਸੇ NAT ਹੋਵੇ)। ਸਾਥੀ SDP ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਪੇਸ਼ਕਸ਼ ਅਤੇ ਜਵਾਬ ਦੁਆਰਾ ICE ਜਾਣਕਾਰੀ ਅਤੇ ਚੈਨਲ ਪੈਰਾਮੀਟਰਾਂ ਦਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ।

ਵਾਹ! ਇੱਕ ਸਮੇਂ ਵਿੱਚ ਕਿੰਨੇ ਸੰਖੇਪ ਰੂਪ? ਆਓ ਸੰਖੇਪ ਵਿੱਚ ਦੱਸੀਏ ਕਿ ਇਹਨਾਂ ਸ਼ਬਦਾਂ ਦਾ ਕੀ ਅਰਥ ਹੈ:

• NAT ਲਈ ਸੈਸ਼ਨ ਟਰਾਵਰਸਲ ਉਪਯੋਗਤਾਵਾਂ (STUN) — NAT ਨੂੰ ਬਾਈਪਾਸ ਕਰਨ ਅਤੇ ਹੋਸਟ ਨਾਲ ਸਿੱਧੇ ਡੇਟਾ ਦਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਕਰਨ ਲਈ ਇੱਕ ਜੋੜਾ (IP, ਪੋਰਟ) ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਇੱਕ ਪ੍ਰੋਟੋਕੋਲ। ਜੇ ਉਹ ਆਪਣਾ ਕੰਮ ਪੂਰਾ ਕਰਨ ਦਾ ਪ੍ਰਬੰਧ ਕਰਦਾ ਹੈ, ਤਾਂ ਸਾਥੀ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਇਕ ਦੂਜੇ ਨਾਲ ਡੇਟਾ ਦਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਕਰ ਸਕਦੇ ਹਨ.
• NAT ਦੇ ਆਲੇ-ਦੁਆਲੇ ਰੀਲੇਅ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਟ੍ਰੈਵਰਸਲ (ਟਰਨ) NAT ਟ੍ਰੈਵਰਸਲ ਲਈ ਵੀ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਪਰ ਇਹ ਇੱਕ ਪ੍ਰੌਕਸੀ ਦੁਆਰਾ ਡੇਟਾ ਨੂੰ ਅੱਗੇ ਭੇਜ ਕੇ ਇਸਨੂੰ ਲਾਗੂ ਕਰਦਾ ਹੈ ਜੋ ਦੋਨਾਂ ਸਾਥੀਆਂ ਨੂੰ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ। ਇਹ ਲੇਟੈਂਸੀ ਨੂੰ ਜੋੜਦਾ ਹੈ ਅਤੇ STUN ਨਾਲੋਂ ਲਾਗੂ ਕਰਨਾ ਵਧੇਰੇ ਮਹਿੰਗਾ ਹੈ (ਕਿਉਂਕਿ ਇਹ ਪੂਰੇ ਸੰਚਾਰ ਸੈਸ਼ਨ ਦੌਰਾਨ ਲਾਗੂ ਹੁੰਦਾ ਹੈ), ਪਰ ਕਈ ਵਾਰ ਇਹ ਇੱਕੋ ਇੱਕ ਵਿਕਲਪ ਹੁੰਦਾ ਹੈ।
• ਇੰਟਰਐਕਟਿਵ ਕਨੈਕਟੀਵਿਟੀ ਸਥਾਪਨਾ (ICE) ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਕਨੈਕਟ ਕਰਨ ਵਾਲੇ ਸਾਥੀਆਂ ਤੋਂ ਪ੍ਰਾਪਤ ਜਾਣਕਾਰੀ ਦੇ ਨਾਲ-ਨਾਲ STUN ਅਤੇ TURN ਸਰਵਰਾਂ ਦੀ ਕਿਸੇ ਵੀ ਸੰਖਿਆ ਦੁਆਰਾ ਪ੍ਰਾਪਤ ਜਾਣਕਾਰੀ ਦੇ ਆਧਾਰ 'ਤੇ ਦੋ ਸਾਥੀਆਂ ਨੂੰ ਜੋੜਨ ਦਾ ਸਭ ਤੋਂ ਵਧੀਆ ਸੰਭਵ ਤਰੀਕਾ ਚੁਣਨ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ।
• ਸੈਸ਼ਨ ਵਰਣਨ ਪ੍ਰੋਟੋਕੋਲ (ਐਸ.ਡੀ.ਪੀ.) ਕਨੈਕਸ਼ਨ ਚੈਨਲ ਪੈਰਾਮੀਟਰਾਂ ਦਾ ਵਰਣਨ ਕਰਨ ਲਈ ਇੱਕ ਫਾਰਮੈਟ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ICE ਉਮੀਦਵਾਰ, ਮਲਟੀਮੀਡੀਆ ਕੋਡੇਕਸ (ਇੱਕ ਆਡੀਓ/ਵੀਡੀਓ ਚੈਨਲ ਦੇ ਮਾਮਲੇ ਵਿੱਚ), ਆਦਿ... ਸਾਥੀਆਂ ਵਿੱਚੋਂ ਇੱਕ ਇੱਕ SDP ਪੇਸ਼ਕਸ਼ ਭੇਜਦਾ ਹੈ, ਅਤੇ ਦੂਜਾ ਇੱਕ SDP ਉੱਤਰ ਨਾਲ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। . ਇਸ ਤੋਂ ਬਾਅਦ, ਇੱਕ ਚੈਨਲ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ।

ਅਜਿਹਾ ਕੁਨੈਕਸ਼ਨ ਬਣਾਉਣ ਲਈ, ਸਾਥੀਆਂ ਨੂੰ STUN ਅਤੇ ਟਰਨ ਸਰਵਰਾਂ ਤੋਂ ਪ੍ਰਾਪਤ ਜਾਣਕਾਰੀ ਨੂੰ ਇਕੱਠਾ ਕਰਨ ਅਤੇ ਇੱਕ ਦੂਜੇ ਨਾਲ ਇਸ ਦਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਉਹਨਾਂ ਕੋਲ ਅਜੇ ਤੱਕ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਸੰਚਾਰ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਨਹੀਂ ਹੈ, ਇਸਲਈ ਇਸ ਡੇਟਾ ਨੂੰ ਐਕਸਚੇਂਜ ਕਰਨ ਲਈ ਇੱਕ ਆਊਟ-ਆਫ-ਬੈਂਡ ਵਿਧੀ ਮੌਜੂਦ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ: ਇੱਕ ਸਿਗਨਲ ਸਰਵਰ।

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

ਸਰਲੀਕ੍ਰਿਤ WebRTC ਹੈਂਡਸ਼ੇਕ ਕ੍ਰਮ ਚਿੱਤਰ

Teeworlds ਨੈੱਟਵਰਕ ਮਾਡਲ ਸੰਖੇਪ ਜਾਣਕਾਰੀ

Teeworlds ਨੈੱਟਵਰਕ ਆਰਕੀਟੈਕਚਰ ਬਹੁਤ ਸਧਾਰਨ ਹੈ:

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

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

ਸਰਵਰਾਂ ਤੋਂ ਛੁਟਕਾਰਾ ਪਾਓ

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

ਹਾਲਾਂਕਿ, ਸਿਸਟਮ ਦੇ ਕੰਮ ਕਰਨ ਲਈ, ਸਾਨੂੰ ਅਜੇ ਵੀ ਇੱਕ ਬਾਹਰੀ ਆਰਕੀਟੈਕਚਰ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਪਵੇਗੀ:

• ਇੱਕ ਜਾਂ ਵੱਧ STUN ਸਰਵਰ: ਸਾਡੇ ਕੋਲ ਚੁਣਨ ਲਈ ਕਈ ਮੁਫਤ ਵਿਕਲਪ ਹਨ।
• ਘੱਟੋ-ਘੱਟ ਇੱਕ ਟਰਨ ਸਰਵਰ: ਇੱਥੇ ਕੋਈ ਮੁਫ਼ਤ ਵਿਕਲਪ ਨਹੀਂ ਹਨ, ਇਸਲਈ ਅਸੀਂ ਜਾਂ ਤਾਂ ਆਪਣਾ ਸੈਟ ਅਪ ਕਰ ਸਕਦੇ ਹਾਂ ਜਾਂ ਸੇਵਾ ਲਈ ਭੁਗਤਾਨ ਕਰ ਸਕਦੇ ਹਾਂ। ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ, ਜ਼ਿਆਦਾਤਰ ਸਮਾਂ STUN ਸਰਵਰਾਂ ਦੁਆਰਾ ਕਨੈਕਸ਼ਨ ਸਥਾਪਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ (ਅਤੇ ਸਹੀ p2p ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ), ਪਰ ਇੱਕ ਫਾਲਬੈਕ ਵਿਕਲਪ ਵਜੋਂ ਟਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
• ਸਿਗਨਲਿੰਗ ਸਰਵਰ: ਦੂਜੇ ਦੋ ਪਹਿਲੂਆਂ ਦੇ ਉਲਟ, ਸਿਗਨਲਿੰਗ ਨੂੰ ਮਾਨਕੀਕ੍ਰਿਤ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ। ਸਿਗਨਲ ਸਰਵਰ ਅਸਲ ਵਿੱਚ ਕਿਸ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੋਵੇਗਾ ਇਹ ਕੁਝ ਹੱਦ ਤੱਕ ਐਪਲੀਕੇਸ਼ਨ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਇੱਕ ਕੁਨੈਕਸ਼ਨ ਸਥਾਪਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਥੋੜ੍ਹੇ ਜਿਹੇ ਡੇਟਾ ਦਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ.
• Teeworlds Master Server: ਇਸਦੀ ਵਰਤੋਂ ਦੂਜੇ ਸਰਵਰਾਂ ਦੁਆਰਾ ਆਪਣੀ ਹੋਂਦ ਦਾ ਇਸ਼ਤਿਹਾਰ ਦੇਣ ਲਈ ਅਤੇ ਗਾਹਕਾਂ ਦੁਆਰਾ ਜਨਤਕ ਸਰਵਰਾਂ ਨੂੰ ਲੱਭਣ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਹਾਲਾਂਕਿ ਇਹ ਲੋੜੀਂਦਾ ਨਹੀਂ ਹੈ (ਗਾਹਕ ਹਮੇਸ਼ਾਂ ਇੱਕ ਸਰਵਰ ਨਾਲ ਜੁੜ ਸਕਦੇ ਹਨ ਜਿਸ ਬਾਰੇ ਉਹ ਹੱਥੀਂ ਜਾਣਦੇ ਹਨ), ਇਹ ਚੰਗਾ ਹੋਵੇਗਾ ਤਾਂ ਜੋ ਖਿਡਾਰੀ ਬੇਤਰਤੀਬ ਲੋਕਾਂ ਨਾਲ ਖੇਡਾਂ ਵਿੱਚ ਹਿੱਸਾ ਲੈ ਸਕਣ।

ਅਸੀਂ Google ਦੇ ਮੁਫਤ STUN ਸਰਵਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ, ਅਤੇ ਇੱਕ ਟਰਨ ਸਰਵਰ ਨੂੰ ਖੁਦ ਤੈਨਾਤ ਕੀਤਾ ਹੈ।

ਪਿਛਲੇ ਦੋ ਬਿੰਦੂਆਂ ਲਈ ਅਸੀਂ ਵਰਤੇ ਫਾਇਰਬੇਜ:

• Teeworlds ਮਾਸਟਰ ਸਰਵਰ ਨੂੰ ਬਹੁਤ ਹੀ ਅਸਾਨੀ ਨਾਲ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਹੈ: ਹਰੇਕ ਕਿਰਿਆਸ਼ੀਲ ਸਰਵਰ ਦੀ ਜਾਣਕਾਰੀ (ਨਾਮ, IP, ਨਕਸ਼ਾ, ਮੋਡ, ...) ਰੱਖਣ ਵਾਲੀਆਂ ਵਸਤੂਆਂ ਦੀ ਸੂਚੀ ਦੇ ਰੂਪ ਵਿੱਚ। ਸਰਵਰ ਆਪਣੀ ਖੁਦ ਦੀ ਵਸਤੂ ਨੂੰ ਪ੍ਰਕਾਸ਼ਿਤ ਅਤੇ ਅਪਡੇਟ ਕਰਦੇ ਹਨ, ਅਤੇ ਕਲਾਇੰਟ ਪੂਰੀ ਸੂਚੀ ਲੈਂਦੇ ਹਨ ਅਤੇ ਇਸਨੂੰ ਪਲੇਅਰ ਨੂੰ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਦੇ ਹਨ। ਅਸੀਂ ਹੋਮ ਪੇਜ 'ਤੇ ਸੂਚੀ ਨੂੰ HTML ਦੇ ਰੂਪ ਵਿੱਚ ਵੀ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਦੇ ਹਾਂ ਤਾਂ ਜੋ ਖਿਡਾਰੀ ਸਿਰਫ਼ ਸਰਵਰ 'ਤੇ ਕਲਿੱਕ ਕਰ ਸਕਣ ਅਤੇ ਸਿੱਧੇ ਗੇਮ 'ਤੇ ਲਿਜਾਇਆ ਜਾ ਸਕੇ।
• ਸਿਗਨਲਿੰਗ ਸਾਡੇ ਸਾਕਟਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਨਾਲ ਨੇੜਿਓਂ ਜੁੜੀ ਹੋਈ ਹੈ, ਅਗਲੇ ਭਾਗ ਵਿੱਚ ਵਰਣਨ ਕੀਤਾ ਗਿਆ ਹੈ।

ਗੇਮ ਦੇ ਅੰਦਰ ਅਤੇ ਹੋਮ ਪੇਜ 'ਤੇ ਸਰਵਰਾਂ ਦੀ ਸੂਚੀ

ਸਾਕਟਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨਾ

ਅਸੀਂ ਇੱਕ API ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹਾਂ ਜੋ Posix UDP ਸਾਕਟਾਂ ਦੇ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਨੇੜੇ ਹੋਵੇ ਤਾਂ ਜੋ ਲੋੜੀਂਦੀਆਂ ਤਬਦੀਲੀਆਂ ਦੀ ਗਿਣਤੀ ਨੂੰ ਘੱਟ ਕੀਤਾ ਜਾ ਸਕੇ।

ਅਸੀਂ ਨੈੱਟਵਰਕ ਉੱਤੇ ਸਭ ਤੋਂ ਸਰਲ ਡੇਟਾ ਐਕਸਚੇਂਜ ਲਈ ਲੋੜੀਂਦੇ ਘੱਟੋ-ਘੱਟ ਲੋੜਾਂ ਨੂੰ ਵੀ ਲਾਗੂ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ।

ਉਦਾਹਰਨ ਲਈ, ਸਾਨੂੰ ਅਸਲ ਰੂਟਿੰਗ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ: ਸਾਰੇ ਸਾਥੀ ਇੱਕ ਖਾਸ ਫਾਇਰਬੇਸ ਡੇਟਾਬੇਸ ਉਦਾਹਰਨ ਨਾਲ ਜੁੜੇ ਇੱਕੋ "ਵਰਚੁਅਲ LAN" 'ਤੇ ਹਨ।

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

ਇੱਥੇ ਘੱਟੋ-ਘੱਟ API ਹੈ ਜੋ ਸਾਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਲੋੜ ਹੈ:

// Create and destroy a socket
int socket();
int close(int fd);
// Bind a socket to a port, and publish it on Firebase
int bind(int fd, AddrInfo* addr);
// Send a packet. This lazily create a WebRTC connection to the 
// peer when necessary
int sendto(int fd, uint8_t* buf, int len, const AddrInfo* addr);
// Receive the packets destined to this socket
int recvfrom(int fd, uint8_t* buf, int len, AddrInfo* addr);
// Be notified when new packets arrived
int recvCallback(Callback cb);
// Obtain a local ip address for this peer key
uint32_t resolve(client::String* key);
// Get the peer key for this ip
String* reverseResolve(uint32_t addr);
// Get the local peer key
String* local_key();
// Initialize the library with the given Firebase database and 
// WebRTc connection options
void init(client::FirebaseConfig* fb, client::RTCConfiguration* ice);

API ਸਧਾਰਨ ਅਤੇ Posix Sockets API ਦੇ ਸਮਾਨ ਹੈ, ਪਰ ਇਸ ਵਿੱਚ ਕੁਝ ਮਹੱਤਵਪੂਰਨ ਅੰਤਰ ਹਨ: ਕਾਲਬੈਕ ਨੂੰ ਲੌਗ ਕਰਨਾ, ਸਥਾਨਕ IP ਨਿਰਧਾਰਤ ਕਰਨਾ, ਅਤੇ ਆਲਸੀ ਕੁਨੈਕਸ਼ਨ.

ਕਾਲਬੈਕਾਂ ਨੂੰ ਰਜਿਸਟਰ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ

ਭਾਵੇਂ ਮੂਲ ਪ੍ਰੋਗਰਾਮ ਗੈਰ-ਬਲਾਕਿੰਗ I/O ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਕੋਡ ਨੂੰ ਵੈੱਬ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਚਲਾਉਣ ਲਈ ਰੀਫੈਕਟਰ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

ਇਸਦਾ ਕਾਰਨ ਇਹ ਹੈ ਕਿ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਇਵੈਂਟ ਲੂਪ ਪ੍ਰੋਗਰਾਮ ਤੋਂ ਲੁਕਿਆ ਹੋਇਆ ਹੈ (ਭਾਵੇਂ ਇਹ JavaScript ਜਾਂ WebAssembly ਹੋਵੇ)।

ਮੂਲ ਵਾਤਾਵਰਣ ਵਿੱਚ ਅਸੀਂ ਇਸ ਤਰ੍ਹਾਂ ਕੋਡ ਲਿਖ ਸਕਦੇ ਹਾਂ

while(running) {
  select(...); // wait for I/O events
  while(true) {
    int r = readfrom(...); // try to read
    if (r < 0 && errno == EWOULDBLOCK) // no more data available
      break;
    ...
  }
  ...
}

ਜੇਕਰ ਇਵੈਂਟ ਲੂਪ ਸਾਡੇ ਲਈ ਲੁਕਿਆ ਹੋਇਆ ਹੈ, ਤਾਂ ਸਾਨੂੰ ਇਸਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਵਿੱਚ ਬਦਲਣ ਦੀ ਲੋੜ ਹੈ:

auto cb = []() { // this will be called when new data is available
  while(true) {
    int r = readfrom(...); // try to read
    if (r < 0 && errno == EWOULDBLOCK) // no more data available
      break;
    ...
  }
  ...
};
recvCallback(cb); // register the callback

ਸਥਾਨਕ IP ਅਸਾਈਨਮੈਂਟ

ਸਾਡੇ "ਨੈੱਟਵਰਕ" ਵਿੱਚ ਨੋਡ ਆਈਡੀ IP ਐਡਰੈੱਸ ਨਹੀਂ ਹਨ, ਪਰ ਫਾਇਰਬੇਸ ਕੁੰਜੀਆਂ ਹਨ (ਉਹ ਸਤਰ ਹਨ ਜੋ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ: -LmEC50PYZLCiCP-vqde ).

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

ਇਹ ਬਿਲਕੁਲ ਉਹੀ ਹੈ ਜਿਸ ਲਈ ਫੰਕਸ਼ਨਾਂ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। resolve и reverseResolve: ਐਪਲੀਕੇਸ਼ਨ ਕਿਸੇ ਤਰ੍ਹਾਂ ਕੁੰਜੀ ਦਾ ਸਤਰ ਮੁੱਲ (ਉਪਭੋਗਤਾ ਇਨਪੁਟ ਜਾਂ ਮਾਸਟਰ ਸਰਵਰ ਦੁਆਰਾ) ਪ੍ਰਾਪਤ ਕਰਦੀ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਅੰਦਰੂਨੀ ਵਰਤੋਂ ਲਈ ਇੱਕ IP ਐਡਰੈੱਸ ਵਿੱਚ ਬਦਲ ਸਕਦੀ ਹੈ। ਬਾਕੀ API ਨੂੰ ਵੀ ਸਰਲਤਾ ਲਈ ਇੱਕ ਸਤਰ ਦੀ ਬਜਾਏ ਇਹ ਮੁੱਲ ਪ੍ਰਾਪਤ ਹੁੰਦਾ ਹੈ।

ਇਹ DNS ਲੁੱਕਅੱਪ ਵਰਗਾ ਹੈ, ਪਰ ਕਲਾਇੰਟ 'ਤੇ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਯਾਨੀ, IP ਐਡਰੈੱਸ ਨੂੰ ਵੱਖ-ਵੱਖ ਗਾਹਕਾਂ ਵਿਚਕਾਰ ਸਾਂਝਾ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਜੇਕਰ ਕਿਸੇ ਕਿਸਮ ਦੇ ਗਲੋਬਲ ਪਛਾਣਕਰਤਾ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਤਿਆਰ ਕਰਨਾ ਹੋਵੇਗਾ।

ਆਲਸੀ ਕੁਨੈਕਸ਼ਨ

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

ਜੇਕਰ ਅਸੀਂ ਐਬਸਟਰੈਕਸ਼ਨ ਦਾ ਸਮਾਨ ਪੱਧਰ ਪ੍ਰਦਾਨ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ, (sendto/recvfrom ਪੂਰਵ ਕੁਨੈਕਸ਼ਨ ਤੋਂ ਬਿਨਾਂ ਮਨਮਾਨੇ ਸਾਥੀਆਂ ਨਾਲ), ਫਿਰ ਉਹਨਾਂ ਨੂੰ API ਦੇ ਅੰਦਰ ਇੱਕ "ਆਲਸੀ" (ਦੇਰੀ ਵਾਲਾ) ਕੁਨੈਕਸ਼ਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

UDP ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ "ਸਰਵਰ" ਅਤੇ "ਕਲਾਇੰਟ" ਵਿਚਕਾਰ ਆਮ ਸੰਚਾਰ ਦੌਰਾਨ ਅਜਿਹਾ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਸਾਡੀ ਲਾਇਬ੍ਰੇਰੀ ਨੂੰ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ:

• ਸਰਵਰ ਕਾਲ bind()ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਨੂੰ ਇਹ ਦੱਸਣ ਲਈ ਕਿ ਇਹ ਨਿਰਧਾਰਤ ਪੋਰਟ 'ਤੇ ਪੈਕੇਟ ਪ੍ਰਾਪਤ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ।

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

• ਸਰਵਰ ਕਾਲ recvfrom(), ਇਸ ਪੋਰਟ 'ਤੇ ਕਿਸੇ ਵੀ ਹੋਸਟ ਤੋਂ ਆਉਣ ਵਾਲੇ ਪੈਕਟਾਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨਾ।

ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਸਾਨੂੰ ਇਸ ਪੋਰਟ ਤੇ ਭੇਜੇ ਗਏ ਪੈਕੇਟਾਂ ਦੀ ਆਉਣ ਵਾਲੀ ਕਤਾਰ ਦੀ ਜਾਂਚ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

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

ਕਾਲ ਗੈਰ-ਬਲਾਕਿੰਗ ਹੈ, ਇਸ ਲਈ ਜੇਕਰ ਕੋਈ ਪੈਕੇਟ ਨਹੀਂ ਹਨ, ਤਾਂ ਅਸੀਂ ਬਸ -1 ਵਾਪਸ ਕਰਦੇ ਹਾਂ ਅਤੇ ਸੈੱਟ ਕਰਦੇ ਹਾਂ errno=EWOULDBLOCK.

• ਕਲਾਇੰਟ ਕੁਝ ਬਾਹਰੀ ਸਾਧਨਾਂ ਅਤੇ ਕਾਲਾਂ ਦੁਆਰਾ ਸਰਵਰ ਦਾ IP ਅਤੇ ਪੋਰਟ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ sendto(). ਇਹ ਇੱਕ ਅੰਦਰੂਨੀ ਕਾਲ ਵੀ ਕਰਦਾ ਹੈ। bind(), ਇਸ ਲਈ ਬਾਅਦ ਵਿੱਚ recvfrom() ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਬਾਂਡ ਨੂੰ ਲਾਗੂ ਕੀਤੇ ਬਿਨਾਂ ਜਵਾਬ ਪ੍ਰਾਪਤ ਕਰੇਗਾ।

ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਕਲਾਇੰਟ ਬਾਹਰੀ ਤੌਰ 'ਤੇ ਸਟ੍ਰਿੰਗ ਕੁੰਜੀ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ ਅਤੇ ਫੰਕਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ resolve() ਇੱਕ IP ਪਤਾ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ.

ਇਸ ਬਿੰਦੂ 'ਤੇ, ਅਸੀਂ ਇੱਕ WebRTC ਹੈਂਡਸ਼ੇਕ ਸ਼ੁਰੂ ਕਰਦੇ ਹਾਂ ਜੇਕਰ ਦੋ ਸਾਥੀ ਅਜੇ ਇੱਕ ਦੂਜੇ ਨਾਲ ਜੁੜੇ ਨਹੀਂ ਹਨ। ਇੱਕੋ ਪੀਅਰ ਦੇ ਵੱਖ-ਵੱਖ ਪੋਰਟਾਂ ਦੇ ਕਨੈਕਸ਼ਨ ਇੱਕੋ WebRTC DataChannel ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ।

ਅਸੀਂ ਅਸਿੱਧੇ ਤੌਰ 'ਤੇ ਵੀ ਪ੍ਰਦਰਸ਼ਨ ਕਰਦੇ ਹਾਂ bind()ਤਾਂ ਜੋ ਸਰਵਰ ਅਗਲੇ ਵਿੱਚ ਮੁੜ ਜੁੜ ਸਕੇ sendto() ਜੇਕਰ ਇਹ ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ ਬੰਦ ਹੋ ਜਾਂਦਾ ਹੈ।

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

ਹੇਠਾਂ ਦਿੱਤਾ ਚਿੱਤਰ ਸਾਕਟ ਸਕੀਮ ਲਈ ਸੰਦੇਸ਼ ਪ੍ਰਵਾਹ ਦੀ ਇੱਕ ਉਦਾਹਰਣ ਅਤੇ ਕਲਾਇੰਟ ਤੋਂ ਸਰਵਰ ਤੱਕ ਪਹਿਲੇ ਸੰਦੇਸ਼ ਦੇ ਪ੍ਰਸਾਰਣ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ:

ਕਲਾਇੰਟ ਅਤੇ ਸਰਵਰ ਵਿਚਕਾਰ ਕਨੈਕਸ਼ਨ ਪੜਾਅ ਦਾ ਪੂਰਾ ਚਿੱਤਰ

ਸਿੱਟਾ

ਜੇ ਤੁਸੀਂ ਇਸ ਨੂੰ ਹੁਣ ਤੱਕ ਪੜ੍ਹਿਆ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਸ਼ਾਇਦ ਸਿਧਾਂਤ ਨੂੰ ਕਾਰਵਾਈ ਵਿੱਚ ਦੇਖਣ ਵਿੱਚ ਦਿਲਚਸਪੀ ਰੱਖਦੇ ਹੋ। 'ਤੇ ਖੇਡ ਖੇਡੀ ਜਾ ਸਕਦੀ ਹੈ teeworlds.leaningtech.com, ਕੋਸ਼ਿਸ਼ ਕਰੋ!

ਸਾਥੀਆਂ ਵਿਚਕਾਰ ਦੋਸਤਾਨਾ ਮੈਚ

ਨੈੱਟਵਰਕ ਲਾਇਬ੍ਰੇਰੀ ਕੋਡ ਮੁਫ਼ਤ ਵਿੱਚ ਉਪਲਬਧ ਹੈ GitHub. 'ਤੇ ਸਾਡੇ ਚੈਨਲ 'ਤੇ ਗੱਲਬਾਤ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਵੋ ਜੀਟਰ!

ਸਰੋਤ: www.habr.com