ಪರಿಚಯ

ನಮ್ಮ ಕಂಪನಿ ಲೀನಿಂಗ್ ಟೆಕ್ನಾಲಜೀಸ್ ಸಾಂಪ್ರದಾಯಿಕ ಡೆಸ್ಕ್‌ಟಾಪ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ವೆಬ್‌ಗೆ ಪೋರ್ಟ್ ಮಾಡಲು ಪರಿಹಾರಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ. ನಮ್ಮ C++ ಕಂಪೈಲರ್ ಹುರಿದುಂಬಿಸಿ WebAssembly ಮತ್ತು JavaScript ಸಂಯೋಜನೆಯನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ, ಇದು ಎರಡನ್ನೂ ಒದಗಿಸುತ್ತದೆ ಸರಳ ಬ್ರೌಸರ್ ಸಂವಹನ, ಮತ್ತು ಹೆಚ್ಚಿನ ಕಾರ್ಯಕ್ಷಮತೆ.

ಅದರ ಅಪ್ಲಿಕೇಶನ್‌ನ ಉದಾಹರಣೆಯಾಗಿ, ನಾವು ಮಲ್ಟಿಪ್ಲೇಯರ್ ಆಟವನ್ನು ವೆಬ್‌ಗೆ ಪೋರ್ಟ್ ಮಾಡಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ ಮತ್ತು ಆಯ್ಕೆಮಾಡಿದ್ದೇವೆ ಟೀವರ್ಲ್ಡ್ಸ್. ಟೀವರ್ಲ್ಡ್ಸ್ ಒಂದು ಮಲ್ಟಿಪ್ಲೇಯರ್ 2D ರೆಟ್ರೊ ಆಟವಾಗಿದ್ದು, ಸಣ್ಣ ಆದರೆ ಸಕ್ರಿಯ ಆಟಗಾರರ ಸಮುದಾಯವನ್ನು ಹೊಂದಿದೆ (ನನ್ನನ್ನೂ ಒಳಗೊಂಡಂತೆ!). ಡೌನ್‌ಲೋಡ್ ಮಾಡಲಾದ ಸಂಪನ್ಮೂಲಗಳು ಮತ್ತು CPU ಮತ್ತು GPU ಅವಶ್ಯಕತೆಗಳೆರಡರಲ್ಲೂ ಇದು ಚಿಕ್ಕದಾಗಿದೆ - ಆದರ್ಶ ಅಭ್ಯರ್ಥಿ.

Teeworlds ಬ್ರೌಸರ್‌ನಲ್ಲಿ ರನ್ ಆಗುತ್ತಿದೆ

ಪ್ರಯೋಗಕ್ಕಾಗಿ ಈ ಯೋಜನೆಯನ್ನು ಬಳಸಲು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ ನೆಟ್‌ವರ್ಕ್ ಕೋಡ್ ಅನ್ನು ವೆಬ್‌ಗೆ ಪೋರ್ಟ್ ಮಾಡಲು ಸಾಮಾನ್ಯ ಪರಿಹಾರಗಳು. ಇದನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಈ ಕೆಳಗಿನ ವಿಧಾನಗಳಲ್ಲಿ ಮಾಡಲಾಗುತ್ತದೆ:

XMLHttpRequest/fetch, ನೆಟ್ವರ್ಕ್ ಭಾಗವು HTTP ವಿನಂತಿಗಳನ್ನು ಮಾತ್ರ ಹೊಂದಿದ್ದರೆ, ಅಥವಾ
ವೆಬ್ ಸಾಕೆಟ್ಗಳು.

ಎರಡೂ ಪರಿಹಾರಗಳು ಸರ್ವರ್ ಬದಿಯಲ್ಲಿ ಸರ್ವರ್ ಘಟಕವನ್ನು ಹೋಸ್ಟ್ ಮಾಡುವ ಅಗತ್ಯವಿರುತ್ತದೆ ಮತ್ತು ಸಾರಿಗೆ ಪ್ರೋಟೋಕಾಲ್ ಆಗಿ ಬಳಸಲು ಅನುಮತಿಸುವುದಿಲ್ಲ UDP. ವೀಡಿಯೊ ಕಾನ್ಫರೆನ್ಸಿಂಗ್ ಸಾಫ್ಟ್‌ವೇರ್ ಮತ್ತು ಆಟಗಳಂತಹ ನೈಜ-ಸಮಯದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಇದು ಮುಖ್ಯವಾಗಿದೆ, ಏಕೆಂದರೆ ಇದು ಪ್ರೋಟೋಕಾಲ್ ಪ್ಯಾಕೆಟ್‌ಗಳ ವಿತರಣೆ ಮತ್ತು ಕ್ರಮವನ್ನು ಖಾತರಿಪಡಿಸುತ್ತದೆ TCP ಕಡಿಮೆ ಸುಪ್ತತೆಗೆ ಅಡ್ಡಿಯಾಗಬಹುದು.

ಮೂರನೇ ಮಾರ್ಗವಿದೆ - ಬ್ರೌಸರ್‌ನಿಂದ ನೆಟ್‌ವರ್ಕ್ ಬಳಸಿ: WebRTC.

RTCDataChannel ಇದು ವಿಶ್ವಾಸಾರ್ಹ ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹವಲ್ಲದ ಪ್ರಸರಣ ಎರಡನ್ನೂ ಬೆಂಬಲಿಸುತ್ತದೆ (ನಂತರದ ಸಂದರ್ಭದಲ್ಲಿ ಇದು ಸಾಧ್ಯವಾದಾಗಲೆಲ್ಲಾ UDP ಅನ್ನು ಸಾರಿಗೆ ಪ್ರೋಟೋಕಾಲ್ ಆಗಿ ಬಳಸಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ), ಮತ್ತು ರಿಮೋಟ್ ಸರ್ವರ್‌ನೊಂದಿಗೆ ಮತ್ತು ಬ್ರೌಸರ್‌ಗಳ ನಡುವೆ ಬಳಸಬಹುದು. ಇದರರ್ಥ ನಾವು ಸರ್ವರ್ ಘಟಕವನ್ನು ಒಳಗೊಂಡಂತೆ ಸಂಪೂರ್ಣ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಬ್ರೌಸರ್‌ಗೆ ಪೋರ್ಟ್ ಮಾಡಬಹುದು!

ಆದಾಗ್ಯೂ, ಇದು ಹೆಚ್ಚುವರಿ ತೊಂದರೆಯೊಂದಿಗೆ ಬರುತ್ತದೆ: ಇಬ್ಬರು WebRTC ಪೀರ್‌ಗಳು ಸಂವಹನ ಮಾಡುವ ಮೊದಲು, ಅವರು ಸಂಪರ್ಕಿಸಲು ತುಲನಾತ್ಮಕವಾಗಿ ಸಂಕೀರ್ಣವಾದ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಅನ್ನು ನಿರ್ವಹಿಸಬೇಕಾಗುತ್ತದೆ, ಇದಕ್ಕೆ ಹಲವಾರು ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಘಟಕಗಳು (ಸಿಗ್ನಲಿಂಗ್ ಸರ್ವರ್ ಮತ್ತು ಒಂದು ಅಥವಾ ಹೆಚ್ಚಿನ ಸರ್ವರ್‌ಗಳು) ಅಗತ್ಯವಿರುತ್ತದೆ. ಸ್ಟನ್/ಟರ್ನ್ ಮಾಡಿ).

ತಾತ್ತ್ವಿಕವಾಗಿ, WebRTC ಅನ್ನು ಆಂತರಿಕವಾಗಿ ಬಳಸುವ ನೆಟ್‌ವರ್ಕ್ API ಅನ್ನು ರಚಿಸಲು ನಾವು ಬಯಸುತ್ತೇವೆ, ಆದರೆ ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸುವ ಅಗತ್ಯವಿಲ್ಲದ UDP ಸಾಕೆಟ್‌ಗಳ ಇಂಟರ್ಫೇಸ್‌ಗೆ ಸಾಧ್ಯವಾದಷ್ಟು ಹತ್ತಿರದಲ್ಲಿದೆ.

ಅಪ್ಲಿಕೇಶನ್ ಕೋಡ್‌ಗೆ ಸಂಕೀರ್ಣವಾದ ವಿವರಗಳನ್ನು ಬಹಿರಂಗಪಡಿಸದೆಯೇ WebRTC ಯ ಲಾಭವನ್ನು ಪಡೆಯಲು ಇದು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ (ನಮ್ಮ ಯೋಜನೆಯಲ್ಲಿ ನಾವು ಸಾಧ್ಯವಾದಷ್ಟು ಕಡಿಮೆ ಬದಲಾಯಿಸಲು ಬಯಸಿದ್ದೇವೆ).

ಕನಿಷ್ಠ WebRTC

WebRTC ಎಂಬುದು ಬ್ರೌಸರ್‌ಗಳಲ್ಲಿ ಲಭ್ಯವಿರುವ API ಗಳ ಒಂದು ಸೆಟ್ ಆಗಿದ್ದು ಅದು ಆಡಿಯೋ, ವಿಡಿಯೋ ಮತ್ತು ಅನಿಯಂತ್ರಿತ ಡೇಟಾದ ಪೀರ್-ಟು-ಪೀರ್ ಪ್ರಸರಣವನ್ನು ಒದಗಿಸುತ್ತದೆ.

ICE ಎಂಬ ಯಾಂತ್ರಿಕತೆಯ ಮೂಲಕ STUN ಮತ್ತು/ಅಥವಾ TURN ಸರ್ವರ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಗೆಳೆಯರ ನಡುವೆ ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸಲಾಗಿದೆ (ಒಂದು ಅಥವಾ ಎರಡೂ ಬದಿಗಳಲ್ಲಿ NAT ಇದ್ದರೂ ಸಹ). SDP ಪ್ರೋಟೋಕಾಲ್‌ನ ಕೊಡುಗೆ ಮತ್ತು ಉತ್ತರದ ಮೂಲಕ ಗೆಳೆಯರು ICE ಮಾಹಿತಿ ಮತ್ತು ಚಾನಲ್ ನಿಯತಾಂಕಗಳನ್ನು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳುತ್ತಾರೆ.

ಅದ್ಭುತ! ಒಂದೇ ಬಾರಿಗೆ ಎಷ್ಟು ಸಂಕ್ಷೇಪಣಗಳು? ಈ ಪದಗಳ ಅರ್ಥವನ್ನು ಸಂಕ್ಷಿಪ್ತವಾಗಿ ವಿವರಿಸೋಣ:

NAT ಗಾಗಿ ಸೆಷನ್ ಟ್ರಾವರ್ಸಲ್ ಉಪಯುಕ್ತತೆಗಳು (ಸ್ಟನ್) — NAT ಅನ್ನು ಬೈಪಾಸ್ ಮಾಡಲು ಮತ್ತು ಹೋಸ್ಟ್‌ನೊಂದಿಗೆ ನೇರವಾಗಿ ಡೇಟಾವನ್ನು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳಲು ಜೋಡಿಯನ್ನು (IP, ಪೋರ್ಟ್) ಪಡೆಯುವ ಪ್ರೋಟೋಕಾಲ್. ಅವನು ತನ್ನ ಕೆಲಸವನ್ನು ಪೂರ್ಣಗೊಳಿಸಲು ನಿರ್ವಹಿಸಿದರೆ, ನಂತರ ಗೆಳೆಯರು ಸ್ವತಂತ್ರವಾಗಿ ಪರಸ್ಪರ ಡೇಟಾವನ್ನು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳಬಹುದು.
NAT ಸುತ್ತ ರಿಲೇಗಳನ್ನು ಬಳಸುವ ಪ್ರಯಾಣ (ಟರ್ನ್ ಮಾಡಿ) NAT ಟ್ರಾವರ್ಸಲ್‌ಗೆ ಸಹ ಬಳಸಲಾಗುತ್ತದೆ, ಆದರೆ ಇದು ಎರಡೂ ಗೆಳೆಯರಿಗೆ ಗೋಚರಿಸುವ ಪ್ರಾಕ್ಸಿ ಮೂಲಕ ಡೇಟಾವನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡುವ ಮೂಲಕ ಇದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ. ಇದು ಸುಪ್ತತೆಯನ್ನು ಸೇರಿಸುತ್ತದೆ ಮತ್ತು STUN ಗಿಂತ ಕಾರ್ಯಗತಗೊಳಿಸಲು ಹೆಚ್ಚು ದುಬಾರಿಯಾಗಿದೆ (ಏಕೆಂದರೆ ಇದು ಸಂಪೂರ್ಣ ಸಂವಹನ ಅವಧಿಯಾದ್ಯಂತ ಅನ್ವಯಿಸುತ್ತದೆ), ಆದರೆ ಕೆಲವೊಮ್ಮೆ ಇದು ಏಕೈಕ ಆಯ್ಕೆಯಾಗಿದೆ.
ಇಂಟರಾಕ್ಟಿವ್ ಕನೆಕ್ಟಿವಿಟಿ ಸ್ಥಾಪನೆ (ICE) ಗೆಳೆಯರನ್ನು ನೇರವಾಗಿ ಸಂಪರ್ಕಿಸುವುದರಿಂದ ಪಡೆದ ಮಾಹಿತಿಯ ಆಧಾರದ ಮೇಲೆ ಇಬ್ಬರು ಗೆಳೆಯರನ್ನು ಸಂಪರ್ಕಿಸುವ ಅತ್ಯುತ್ತಮ ವಿಧಾನವನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ಬಳಸಲಾಗುತ್ತದೆ, ಹಾಗೆಯೇ ಯಾವುದೇ ಸಂಖ್ಯೆಯ STUN ಮತ್ತು ಟರ್ನ್ ಸರ್ವರ್‌ಗಳಿಂದ ಪಡೆದ ಮಾಹಿತಿ.
ಅಧಿವೇಶನ ವಿವರಣೆ ಪ್ರೋಟೋಕಾಲ್ (ಎಸ್‌ಡಿಪಿ) ಸಂಪರ್ಕ ಚಾನಲ್ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳನ್ನು ವಿವರಿಸಲು ಒಂದು ಸ್ವರೂಪವಾಗಿದೆ, ಉದಾಹರಣೆಗೆ, ICE ಅಭ್ಯರ್ಥಿಗಳು, ಮಲ್ಟಿಮೀಡಿಯಾ ಕೊಡೆಕ್‌ಗಳು (ಆಡಿಯೋ/ವೀಡಿಯೊ ಚಾನಲ್‌ನ ಸಂದರ್ಭದಲ್ಲಿ), ಇತ್ಯಾದಿ... ಗೆಳೆಯರಲ್ಲಿ ಒಬ್ಬರು SDP ಆಫರ್ ಅನ್ನು ಕಳುಹಿಸುತ್ತಾರೆ ಮತ್ತು ಎರಡನೆಯವರು SDP ಉತ್ತರದೊಂದಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತಾರೆ . ಇದರ ನಂತರ, ಚಾನಲ್ ಅನ್ನು ರಚಿಸಲಾಗಿದೆ.

ಅಂತಹ ಸಂಪರ್ಕವನ್ನು ರಚಿಸಲು, ಗೆಳೆಯರು STUN ಮತ್ತು ಟರ್ನ್ ಸರ್ವರ್‌ಗಳಿಂದ ಸ್ವೀಕರಿಸುವ ಮಾಹಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸಬೇಕು ಮತ್ತು ಅದನ್ನು ಪರಸ್ಪರ ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳಬೇಕು.

ಸಮಸ್ಯೆಯೆಂದರೆ ಅವರು ನೇರವಾಗಿ ಸಂವಹನ ಮಾಡುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಇನ್ನೂ ಹೊಂದಿಲ್ಲ, ಆದ್ದರಿಂದ ಈ ಡೇಟಾವನ್ನು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳಲು ಬ್ಯಾಂಡ್‌ನ ಹೊರಗಿನ ಕಾರ್ಯವಿಧಾನವು ಅಸ್ತಿತ್ವದಲ್ಲಿರಬೇಕು: ಸಿಗ್ನಲಿಂಗ್ ಸರ್ವರ್.

ಸಿಗ್ನಲಿಂಗ್ ಸರ್ವರ್ ತುಂಬಾ ಸರಳವಾಗಿದೆ ಏಕೆಂದರೆ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಹಂತದಲ್ಲಿ ಗೆಳೆಯರ ನಡುವೆ ಡೇಟಾವನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡುವುದು ಅದರ ಏಕೈಕ ಕೆಲಸವಾಗಿದೆ (ಕೆಳಗಿನ ರೇಖಾಚಿತ್ರದಲ್ಲಿ ತೋರಿಸಿರುವಂತೆ).

ಸರಳೀಕೃತ WebRTC ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಅನುಕ್ರಮ ರೇಖಾಚಿತ್ರ

ಟೀವರ್ಲ್ಡ್ಸ್ ನೆಟ್‌ವರ್ಕ್ ಮಾದರಿ ಅವಲೋಕನ

ಟೀವರ್ಲ್ಡ್ಸ್ ನೆಟ್ವರ್ಕ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ತುಂಬಾ ಸರಳವಾಗಿದೆ:

ಕ್ಲೈಂಟ್ ಮತ್ತು ಸರ್ವರ್ ಘಟಕಗಳು ಎರಡು ವಿಭಿನ್ನ ಕಾರ್ಯಕ್ರಮಗಳಾಗಿವೆ.
ಗ್ರಾಹಕರು ಹಲವಾರು ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಒಂದನ್ನು ಸಂಪರ್ಕಿಸುವ ಮೂಲಕ ಆಟವನ್ನು ಪ್ರವೇಶಿಸುತ್ತಾರೆ, ಪ್ರತಿಯೊಂದೂ ಒಂದು ಸಮಯದಲ್ಲಿ ಕೇವಲ ಒಂದು ಆಟವನ್ನು ಹೋಸ್ಟ್ ಮಾಡುತ್ತದೆ.
ಆಟದಲ್ಲಿನ ಎಲ್ಲಾ ಡೇಟಾ ವರ್ಗಾವಣೆಯನ್ನು ಸರ್ವರ್ ಮೂಲಕ ನಡೆಸಲಾಗುತ್ತದೆ.
ಆಟದ ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ ಪ್ರದರ್ಶಿಸಲಾದ ಎಲ್ಲಾ ಸಾರ್ವಜನಿಕ ಸರ್ವರ್‌ಗಳ ಪಟ್ಟಿಯನ್ನು ಸಂಗ್ರಹಿಸಲು ವಿಶೇಷ ಮಾಸ್ಟರ್ ಸರ್ವರ್ ಅನ್ನು ಬಳಸಲಾಗುತ್ತದೆ.

ಡೇಟಾ ವಿನಿಮಯಕ್ಕಾಗಿ WebRTC ಬಳಕೆಗೆ ಧನ್ಯವಾದಗಳು, ನಾವು ಕ್ಲೈಂಟ್ ಇರುವ ಬ್ರೌಸರ್‌ಗೆ ಆಟದ ಸರ್ವರ್ ಘಟಕವನ್ನು ವರ್ಗಾಯಿಸಬಹುದು. ಇದು ನಮಗೆ ಉತ್ತಮ ಅವಕಾಶವನ್ನು ನೀಡುತ್ತದೆ ...

ಸರ್ವರ್‌ಗಳನ್ನು ತೊಡೆದುಹಾಕಿ

ಸರ್ವರ್ ಲಾಜಿಕ್‌ನ ಕೊರತೆಯು ಉತ್ತಮ ಪ್ರಯೋಜನವನ್ನು ಹೊಂದಿದೆ: ನಾವು ಸಂಪೂರ್ಣ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಗಿಥಬ್ ಪುಟಗಳಲ್ಲಿ ಅಥವಾ ಕ್ಲೌಡ್‌ಫ್ಲೇರ್‌ನ ಹಿಂದೆ ನಮ್ಮ ಸ್ವಂತ ಹಾರ್ಡ್‌ವೇರ್‌ನಲ್ಲಿ ಸ್ಥಿರ ವಿಷಯವಾಗಿ ನಿಯೋಜಿಸಬಹುದು, ಹೀಗಾಗಿ ವೇಗದ ಡೌನ್‌ಲೋಡ್‌ಗಳು ಮತ್ತು ಹೆಚ್ಚಿನ ಸಮಯವನ್ನು ಉಚಿತವಾಗಿ ಖಾತ್ರಿಪಡಿಸಿಕೊಳ್ಳಬಹುದು. ವಾಸ್ತವವಾಗಿ, ನಾವು ಅವರ ಬಗ್ಗೆ ಮರೆತುಬಿಡಬಹುದು, ಮತ್ತು ನಾವು ಅದೃಷ್ಟವಂತರಾಗಿದ್ದರೆ ಮತ್ತು ಆಟವು ಜನಪ್ರಿಯವಾಗಿದ್ದರೆ, ಮೂಲಸೌಕರ್ಯವನ್ನು ಆಧುನೀಕರಿಸಬೇಕಾಗಿಲ್ಲ.

ಆದಾಗ್ಯೂ, ಸಿಸ್ಟಮ್ ಕೆಲಸ ಮಾಡಲು, ನಾವು ಇನ್ನೂ ಬಾಹ್ಯ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ಬಳಸಬೇಕಾಗುತ್ತದೆ:

ಒಂದು ಅಥವಾ ಹೆಚ್ಚಿನ STUN ಸರ್ವರ್‌ಗಳು: ನಾವು ಆಯ್ಕೆ ಮಾಡಲು ಹಲವಾರು ಉಚಿತ ಆಯ್ಕೆಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ.
ಕನಿಷ್ಠ ಒಂದು ಟರ್ನ್ ಸರ್ವರ್: ಇಲ್ಲಿ ಯಾವುದೇ ಉಚಿತ ಆಯ್ಕೆಗಳಿಲ್ಲ, ಆದ್ದರಿಂದ ನಾವು ನಮ್ಮದೇ ಆದದನ್ನು ಹೊಂದಿಸಬಹುದು ಅಥವಾ ಸೇವೆಗಾಗಿ ಪಾವತಿಸಬಹುದು. ಅದೃಷ್ಟವಶಾತ್, ಹೆಚ್ಚಿನ ಸಮಯ ಸಂಪರ್ಕವನ್ನು STUN ಸರ್ವರ್‌ಗಳ ಮೂಲಕ ಸ್ಥಾಪಿಸಬಹುದು (ಮತ್ತು ನಿಜವಾದ p2p ಅನ್ನು ಒದಗಿಸಿ), ಆದರೆ TURN ಫಾಲ್‌ಬ್ಯಾಕ್ ಆಯ್ಕೆಯಾಗಿ ಅಗತ್ಯವಿದೆ.
ಸಿಗ್ನಲಿಂಗ್ ಸರ್ವರ್: ಇತರ ಎರಡು ಅಂಶಗಳಿಗಿಂತ ಭಿನ್ನವಾಗಿ, ಸಿಗ್ನಲಿಂಗ್ ಅನ್ನು ಪ್ರಮಾಣೀಕರಿಸಲಾಗಿಲ್ಲ. ಸಿಗ್ನಲಿಂಗ್ ಸರ್ವರ್ ನಿಜವಾಗಿ ಜವಾಬ್ದಾರರಾಗಿರುವುದು ಅಪ್ಲಿಕೇಶನ್‌ನ ಮೇಲೆ ಸ್ವಲ್ಪಮಟ್ಟಿಗೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ. ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸುವ ಮೊದಲು, ಸಣ್ಣ ಪ್ರಮಾಣದ ಡೇಟಾವನ್ನು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳುವುದು ಅವಶ್ಯಕ.
ಟೀವರ್ಲ್ಡ್ಸ್ ಮಾಸ್ಟರ್ ಸರ್ವರ್: ಇದನ್ನು ಇತರ ಸರ್ವರ್‌ಗಳು ತಮ್ಮ ಅಸ್ತಿತ್ವವನ್ನು ಜಾಹೀರಾತು ಮಾಡಲು ಮತ್ತು ಕ್ಲೈಂಟ್‌ಗಳು ಸಾರ್ವಜನಿಕ ಸರ್ವರ್‌ಗಳನ್ನು ಹುಡುಕಲು ಬಳಸುತ್ತಾರೆ. ಇದು ಅಗತ್ಯವಿಲ್ಲದಿದ್ದರೂ (ಕ್ಲೈಂಟ್‌ಗಳು ಯಾವಾಗಲೂ ಹಸ್ತಚಾಲಿತವಾಗಿ ತಿಳಿದಿರುವ ಸರ್ವರ್‌ಗೆ ಸಂಪರ್ಕಿಸಬಹುದು), ಆಟಗಾರರು ಯಾದೃಚ್ಛಿಕ ಜನರೊಂದಿಗೆ ಆಟಗಳಲ್ಲಿ ಭಾಗವಹಿಸಲು ಇದು ಒಳ್ಳೆಯದು.

ನಾವು Google ನ ಉಚಿತ STUN ಸರ್ವರ್‌ಗಳನ್ನು ಬಳಸಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ ಮತ್ತು ಒಂದು ಟರ್ನ್ ಸರ್ವರ್ ಅನ್ನು ನಾವೇ ನಿಯೋಜಿಸಿದ್ದೇವೆ.

ಕೊನೆಯ ಎರಡು ಅಂಕಗಳಿಗಾಗಿ ನಾವು ಬಳಸಿದ್ದೇವೆ ಫೈರ್ಬೇಸ್:

Teeworlds ಮಾಸ್ಟರ್ ಸರ್ವರ್ ಅನ್ನು ಅತ್ಯಂತ ಸರಳವಾಗಿ ಅಳವಡಿಸಲಾಗಿದೆ: ಪ್ರತಿ ಸಕ್ರಿಯ ಸರ್ವರ್‌ನ ಮಾಹಿತಿಯನ್ನು (ಹೆಸರು, IP, ನಕ್ಷೆ, ಮೋಡ್, ...) ಹೊಂದಿರುವ ವಸ್ತುಗಳ ಪಟ್ಟಿಯಾಗಿ. ಸರ್ವರ್‌ಗಳು ತಮ್ಮದೇ ಆದ ವಸ್ತುವನ್ನು ಪ್ರಕಟಿಸುತ್ತವೆ ಮತ್ತು ನವೀಕರಿಸುತ್ತವೆ, ಮತ್ತು ಗ್ರಾಹಕರು ಸಂಪೂರ್ಣ ಪಟ್ಟಿಯನ್ನು ತೆಗೆದುಕೊಂಡು ಅದನ್ನು ಪ್ಲೇಯರ್‌ಗೆ ಪ್ರದರ್ಶಿಸುತ್ತಾರೆ. ನಾವು ಹೋಮ್ ಪೇಜ್‌ನಲ್ಲಿ HTML ನಂತೆ ಪಟ್ಟಿಯನ್ನು ಪ್ರದರ್ಶಿಸುತ್ತೇವೆ ಆದ್ದರಿಂದ ಆಟಗಾರರು ಸರ್ವರ್‌ನಲ್ಲಿ ಕ್ಲಿಕ್ ಮಾಡಬಹುದು ಮತ್ತು ನೇರವಾಗಿ ಆಟಕ್ಕೆ ತೆಗೆದುಕೊಳ್ಳಬಹುದು.
ಸಿಗ್ನಲಿಂಗ್ ನಮ್ಮ ಸಾಕೆಟ್‌ಗಳ ಅನುಷ್ಠಾನಕ್ಕೆ ನಿಕಟವಾಗಿ ಸಂಬಂಧಿಸಿದೆ, ಮುಂದಿನ ವಿಭಾಗದಲ್ಲಿ ವಿವರಿಸಲಾಗಿದೆ.

ಆಟದ ಒಳಗೆ ಮತ್ತು ಮುಖಪುಟದಲ್ಲಿ ಸರ್ವರ್‌ಗಳ ಪಟ್ಟಿ

ಸಾಕೆಟ್ಗಳ ಅನುಷ್ಠಾನ

ಅಗತ್ಯವಿರುವ ಬದಲಾವಣೆಗಳ ಸಂಖ್ಯೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಲು ನಾವು Posix UDP ಸಾಕೆಟ್‌ಗಳಿಗೆ ಸಾಧ್ಯವಾದಷ್ಟು ಹತ್ತಿರವಿರುವ API ಅನ್ನು ರಚಿಸಲು ಬಯಸುತ್ತೇವೆ.

ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಸರಳವಾದ ಡೇಟಾ ವಿನಿಮಯಕ್ಕೆ ಅಗತ್ಯವಾದ ಕನಿಷ್ಠವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ನಾವು ಬಯಸುತ್ತೇವೆ.

ಉದಾಹರಣೆಗೆ, ನಮಗೆ ನಿಜವಾದ ರೂಟಿಂಗ್ ಅಗತ್ಯವಿಲ್ಲ: ಎಲ್ಲಾ ಗೆಳೆಯರು ನಿರ್ದಿಷ್ಟ ಫೈರ್‌ಬೇಸ್ ಡೇಟಾಬೇಸ್ ನಿದರ್ಶನದೊಂದಿಗೆ ಸಂಯೋಜಿತವಾಗಿರುವ ಒಂದೇ "ವರ್ಚುವಲ್ 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 ಸಾಕೆಟ್ಸ್ API ಗೆ ಹೋಲುತ್ತದೆ, ಆದರೆ ಕೆಲವು ಪ್ರಮುಖ ವ್ಯತ್ಯಾಸಗಳನ್ನು ಹೊಂದಿದೆ: ಕಾಲ್‌ಬ್ಯಾಕ್‌ಗಳನ್ನು ಲಾಗ್ ಮಾಡುವುದು, ಸ್ಥಳೀಯ ಐಪಿಗಳನ್ನು ನಿಯೋಜಿಸುವುದು ಮತ್ತು ಸೋಮಾರಿಯಾದ ಸಂಪರ್ಕಗಳು.

ಕಾಲ್‌ಬ್ಯಾಕ್‌ಗಳನ್ನು ನೋಂದಾಯಿಸಲಾಗುತ್ತಿದೆ

ಮೂಲ ಪ್ರೋಗ್ರಾಂ ನಿರ್ಬಂಧಿಸದ I/O ಅನ್ನು ಬಳಸಿದರೂ, ವೆಬ್ ಬ್ರೌಸರ್‌ನಲ್ಲಿ ರನ್ ಮಾಡಲು ಕೋಡ್ ಅನ್ನು ಮರುಫಲಕ ಮಾಡಬೇಕು.

ಇದಕ್ಕೆ ಕಾರಣವೆಂದರೆ ಬ್ರೌಸರ್‌ನಲ್ಲಿನ ಈವೆಂಟ್ ಲೂಪ್ ಅನ್ನು ಪ್ರೋಗ್ರಾಂನಿಂದ ಮರೆಮಾಡಲಾಗಿದೆ (ಅದು ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಅಥವಾ ವೆಬ್ಅಸೆಂಬ್ಲಿ ಆಗಿರಬಹುದು).

ಸ್ಥಳೀಯ ಪರಿಸರದಲ್ಲಿ ನಾವು ಈ ರೀತಿಯ ಕೋಡ್ ಅನ್ನು ಬರೆಯಬಹುದು

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 ನಿಯೋಜನೆ

ನಮ್ಮ "ನೆಟ್‌ವರ್ಕ್" ನಲ್ಲಿರುವ ನೋಡ್ ಐಡಿಗಳು ಐಪಿ ವಿಳಾಸಗಳಲ್ಲ, ಆದರೆ ಫೈರ್‌ಬೇಸ್ ಕೀಗಳು (ಅವು ಈ ರೀತಿ ಕಾಣುವ ಸ್ಟ್ರಿಂಗ್‌ಗಳಾಗಿವೆ: -LmEC50PYZLCiCP-vqde ).

ಇದು ಅನುಕೂಲಕರವಾಗಿದೆ ಏಕೆಂದರೆ IP ಗಳನ್ನು ನಿಯೋಜಿಸಲು ಮತ್ತು ಅವುಗಳ ಅನನ್ಯತೆಯನ್ನು ಪರಿಶೀಲಿಸಲು ನಮಗೆ ಯಾಂತ್ರಿಕ ವ್ಯವಸ್ಥೆ ಅಗತ್ಯವಿಲ್ಲ (ಹಾಗೆಯೇ ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕ ಕಡಿತಗೊಂಡ ನಂತರ ಅವುಗಳನ್ನು ವಿಲೇವಾರಿ ಮಾಡುವುದು), ಆದರೆ ಸಂಖ್ಯಾತ್ಮಕ ಮೌಲ್ಯದಿಂದ ಗೆಳೆಯರನ್ನು ಗುರುತಿಸುವುದು ಅಗತ್ಯವಾಗಿರುತ್ತದೆ.

ಈ ಕಾರ್ಯಗಳನ್ನು ನಿಖರವಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ. resolve и reverseResolve: ಅಪ್ಲಿಕೇಶನ್ ಹೇಗಾದರೂ ಕೀಲಿಯ ಸ್ಟ್ರಿಂಗ್ ಮೌಲ್ಯವನ್ನು ಪಡೆಯುತ್ತದೆ (ಬಳಕೆದಾರರ ಇನ್ಪುಟ್ ಮೂಲಕ ಅಥವಾ ಮಾಸ್ಟರ್ ಸರ್ವರ್ ಮೂಲಕ), ಮತ್ತು ಆಂತರಿಕ ಬಳಕೆಗಾಗಿ ಅದನ್ನು IP ವಿಳಾಸಕ್ಕೆ ಪರಿವರ್ತಿಸಬಹುದು. ಉಳಿದ API ಕೂಡ ಸರಳತೆಗಾಗಿ ಸ್ಟ್ರಿಂಗ್ ಬದಲಿಗೆ ಈ ಮೌಲ್ಯವನ್ನು ಪಡೆಯುತ್ತದೆ.

ಇದು DNS ಲುಕಪ್ ಅನ್ನು ಹೋಲುತ್ತದೆ, ಆದರೆ ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ ಸ್ಥಳೀಯವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.

ಅಂದರೆ, ವಿವಿಧ ಕ್ಲೈಂಟ್‌ಗಳ ನಡುವೆ IP ವಿಳಾಸಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳಲಾಗುವುದಿಲ್ಲ ಮತ್ತು ಕೆಲವು ರೀತಿಯ ಜಾಗತಿಕ ಗುರುತಿಸುವಿಕೆ ಅಗತ್ಯವಿದ್ದರೆ, ಅದನ್ನು ಬೇರೆ ರೀತಿಯಲ್ಲಿ ರಚಿಸಬೇಕಾಗುತ್ತದೆ.

ಸೋಮಾರಿಯಾದ ಸಂಪರ್ಕ

UDP ಗೆ ಸಂಪರ್ಕದ ಅಗತ್ಯವಿಲ್ಲ, ಆದರೆ ನಾವು ನೋಡಿದಂತೆ, WebRTC ಗೆ ಇಬ್ಬರು ಗೆಳೆಯರ ನಡುವೆ ಡೇಟಾ ವರ್ಗಾವಣೆಯನ್ನು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು ಸುದೀರ್ಘ ಸಂಪರ್ಕ ಪ್ರಕ್ರಿಯೆಯ ಅಗತ್ಯವಿದೆ.

ನಾವು ಅದೇ ಮಟ್ಟದ ಅಮೂರ್ತತೆಯನ್ನು ಒದಗಿಸಲು ಬಯಸಿದರೆ, (sendto/recvfrom ಪೂರ್ವ ಸಂಪರ್ಕವಿಲ್ಲದೆ ಅನಿಯಂತ್ರಿತ ಗೆಳೆಯರೊಂದಿಗೆ), ನಂತರ ಅವರು API ಒಳಗೆ "ಸೋಮಾರಿ" (ವಿಳಂಬಿತ) ಸಂಪರ್ಕವನ್ನು ನಿರ್ವಹಿಸಬೇಕು.

UDP ಬಳಸುವಾಗ "ಸರ್ವರ್" ಮತ್ತು "ಕ್ಲೈಂಟ್" ನಡುವಿನ ಸಾಮಾನ್ಯ ಸಂವಹನದ ಸಮಯದಲ್ಲಿ ಇದು ಸಂಭವಿಸುತ್ತದೆ ಮತ್ತು ನಮ್ಮ ಲೈಬ್ರರಿ ಏನು ಮಾಡಬೇಕು:

ಸರ್ವರ್ ಕರೆಗಳು bind()ನಿಗದಿತ ಪೋರ್ಟ್‌ನಲ್ಲಿ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸಲು ಬಯಸುತ್ತದೆ ಎಂದು ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗೆ ಹೇಳಲು.

ಬದಲಿಗೆ, ನಾವು ಸರ್ವರ್ ಕೀ ಅಡಿಯಲ್ಲಿ Firebase ಗೆ ತೆರೆದ ಪೋರ್ಟ್ ಅನ್ನು ಪ್ರಕಟಿಸುತ್ತೇವೆ ಮತ್ತು ಅದರ ಸಬ್‌ಟ್ರೀಯಲ್ಲಿ ಈವೆಂಟ್‌ಗಳನ್ನು ಆಲಿಸುತ್ತೇವೆ.

ಸರ್ವರ್ ಕರೆಗಳು recvfrom(), ಈ ಪೋರ್ಟ್‌ನಲ್ಲಿ ಯಾವುದೇ ಹೋಸ್ಟ್‌ನಿಂದ ಬರುವ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸಲಾಗುತ್ತಿದೆ.

ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಈ ಪೋರ್ಟ್‌ಗೆ ಕಳುಹಿಸಲಾದ ಪ್ಯಾಕೆಟ್‌ಗಳ ಒಳಬರುವ ಕ್ಯೂ ಅನ್ನು ನಾವು ಪರಿಶೀಲಿಸಬೇಕಾಗಿದೆ.

ಪ್ರತಿಯೊಂದು ಪೋರ್ಟ್ ತನ್ನದೇ ಆದ ಸರದಿಯನ್ನು ಹೊಂದಿದೆ ಮತ್ತು ನಾವು ವೆಬ್‌ಆರ್‌ಟಿಸಿ ಡೇಟಾಗ್ರಾಮ್‌ಗಳ ಪ್ರಾರಂಭಕ್ಕೆ ಮೂಲ ಮತ್ತು ಗಮ್ಯಸ್ಥಾನದ ಪೋರ್ಟ್‌ಗಳನ್ನು ಸೇರಿಸುತ್ತೇವೆ ಇದರಿಂದ ಹೊಸ ಪ್ಯಾಕೆಟ್ ಬಂದಾಗ ಯಾವ ಸರತಿಯನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡಬೇಕೆಂದು ನಮಗೆ ತಿಳಿಯುತ್ತದೆ.

ಕರೆ ತಡೆಯುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಯಾವುದೇ ಪ್ಯಾಕೆಟ್‌ಗಳಿಲ್ಲದಿದ್ದರೆ, ನಾವು ಸರಳವಾಗಿ -1 ಅನ್ನು ಹಿಂತಿರುಗಿಸಿ ಹೊಂದಿಸುತ್ತೇವೆ errno=EWOULDBLOCK.

ಕ್ಲೈಂಟ್ ಕೆಲವು ಬಾಹ್ಯ ವಿಧಾನಗಳು ಮತ್ತು ಕರೆಗಳ ಮೂಲಕ ಸರ್ವರ್ನ IP ಮತ್ತು ಪೋರ್ಟ್ ಅನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ sendto(). ಇದು ಆಂತರಿಕ ಕರೆಯನ್ನೂ ಮಾಡುತ್ತದೆ. bind(), ಆದ್ದರಿಂದ ನಂತರದ recvfrom() ಬೈಂಡ್ ಅನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸದೆ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ.

ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಕ್ಲೈಂಟ್ ಬಾಹ್ಯವಾಗಿ ಸ್ಟ್ರಿಂಗ್ ಕೀಲಿಯನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಮತ್ತು ಕಾರ್ಯವನ್ನು ಬಳಸುತ್ತದೆ resolve() IP ವಿಳಾಸವನ್ನು ಪಡೆಯಲು.

ಈ ಹಂತದಲ್ಲಿ, ಇಬ್ಬರು ಗೆಳೆಯರು ಇನ್ನೂ ಪರಸ್ಪರ ಸಂಪರ್ಕ ಹೊಂದಿಲ್ಲದಿದ್ದರೆ ನಾವು WebRTC ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ. ಒಂದೇ ಪೀರ್‌ನ ವಿಭಿನ್ನ ಪೋರ್ಟ್‌ಗಳಿಗೆ ಸಂಪರ್ಕಗಳು ಒಂದೇ ವೆಬ್‌ಆರ್‌ಟಿಸಿ ಡೇಟಾ ಚಾನೆಲ್ ಅನ್ನು ಬಳಸುತ್ತವೆ.

ನಾವು ಪರೋಕ್ಷವಾಗಿ ಸಹ ನಿರ್ವಹಿಸುತ್ತೇವೆ bind()ಇದರಿಂದ ಸರ್ವರ್ ಮುಂದಿನದರಲ್ಲಿ ಮರುಸಂಪರ್ಕಿಸಬಹುದು sendto() ಕೆಲವು ಕಾರಣಗಳಿಂದ ಅದು ಮುಚ್ಚಲ್ಪಟ್ಟರೆ.

ಫೈರ್‌ಬೇಸ್‌ನಲ್ಲಿ ಸರ್ವರ್ ಪೋರ್ಟ್ ಮಾಹಿತಿಯ ಅಡಿಯಲ್ಲಿ ಕ್ಲೈಂಟ್ ತನ್ನ SDP ಕೊಡುಗೆಯನ್ನು ಬರೆದಾಗ ಕ್ಲೈಂಟ್‌ನ ಸಂಪರ್ಕದ ಕುರಿತು ಸರ್ವರ್‌ಗೆ ಸೂಚಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಸರ್ವರ್ ಅದರ ಪ್ರತಿಕ್ರಿಯೆಯೊಂದಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ.

ಕೆಳಗಿನ ರೇಖಾಚಿತ್ರವು ಸಾಕೆಟ್ ಸ್ಕೀಮ್‌ಗಾಗಿ ಸಂದೇಶ ಹರಿವಿನ ಉದಾಹರಣೆಯನ್ನು ತೋರಿಸುತ್ತದೆ ಮತ್ತು ಕ್ಲೈಂಟ್‌ನಿಂದ ಸರ್ವರ್‌ಗೆ ಕಳುಹಿಸಲಾದ ಮೊದಲ ಸಂದೇಶ:

ಕ್ಲೈಂಟ್ ಮತ್ತು ಸರ್ವರ್ ನಡುವಿನ ಸಂಪರ್ಕ ಹಂತದ ಸಂಪೂರ್ಣ ರೇಖಾಚಿತ್ರ

ತೀರ್ಮಾನಕ್ಕೆ

ನೀವು ಇಲ್ಲಿಯವರೆಗೆ ಓದಿದ್ದರೆ, ಸಿದ್ಧಾಂತವನ್ನು ಕ್ರಿಯೆಯಲ್ಲಿ ನೋಡಲು ನೀವು ಬಹುಶಃ ಆಸಕ್ತಿ ಹೊಂದಿರುತ್ತೀರಿ. ಆಟವನ್ನು ಆಡಬಹುದು teeworlds.leaningtech.com, ಪ್ರಯತ್ನ ಪಡು, ಪ್ರಯತ್ನಿಸು!

ಸಹೋದ್ಯೋಗಿಗಳ ನಡುವೆ ಸೌಹಾರ್ದ ಹೊಂದಾಣಿಕೆ

ನೆಟ್‌ವರ್ಕ್ ಲೈಬ್ರರಿ ಕೋಡ್ ಇಲ್ಲಿ ಉಚಿತವಾಗಿ ಲಭ್ಯವಿದೆ github. ನಲ್ಲಿ ನಮ್ಮ ಚಾನಲ್‌ನಲ್ಲಿ ಸಂವಾದಕ್ಕೆ ಸೇರಿ ಗಿಟ್ಟೆ!

ಮೂಲ: www.habr.com

Cheerp, WebRTC ಮತ್ತು Firebase ಜೊತೆಗೆ C++ ನಿಂದ ವೆಬ್‌ಗೆ ಮಲ್ಟಿಪ್ಲೇಯರ್ ಆಟವನ್ನು ಪೋರ್ಟ್ ಮಾಡಲಾಗುತ್ತಿದೆ