ಕಳೆದ ಎರಡು ವಾರಗಳಿಂದ ನಾನು ನನ್ನ ಆಟಕ್ಕಾಗಿ ಆನ್‌ಲೈನ್ ಎಂಜಿನ್‌ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೇನೆ. ಇದಕ್ಕೂ ಮೊದಲು, ಆಟಗಳಲ್ಲಿ ನೆಟ್ವರ್ಕಿಂಗ್ ಬಗ್ಗೆ ನನಗೆ ಏನೂ ತಿಳಿದಿರಲಿಲ್ಲ, ಆದ್ದರಿಂದ ನಾನು ಬಹಳಷ್ಟು ಲೇಖನಗಳನ್ನು ಓದಿದ್ದೇನೆ ಮತ್ತು ಎಲ್ಲಾ ಪರಿಕಲ್ಪನೆಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಮತ್ತು ನನ್ನ ಸ್ವಂತ ನೆಟ್ವರ್ಕಿಂಗ್ ಎಂಜಿನ್ ಅನ್ನು ಬರೆಯಲು ಸಾಕಷ್ಟು ಪ್ರಯೋಗಗಳನ್ನು ಮಾಡಿದ್ದೇನೆ.
ಈ ಮಾರ್ಗದರ್ಶಿಯಲ್ಲಿ, ನಿಮ್ಮ ಸ್ವಂತ ಆಟದ ಎಂಜಿನ್ ಅನ್ನು ಬರೆಯುವ ಮೊದಲು ನೀವು ಕಲಿಯಬೇಕಾದ ವಿವಿಧ ಪರಿಕಲ್ಪನೆಗಳನ್ನು ಮತ್ತು ಅವುಗಳನ್ನು ಕಲಿಯಲು ಉತ್ತಮ ಸಂಪನ್ಮೂಲಗಳು ಮತ್ತು ಲೇಖನಗಳನ್ನು ನಿಮ್ಮೊಂದಿಗೆ ಹಂಚಿಕೊಳ್ಳಲು ನಾನು ಬಯಸುತ್ತೇನೆ.
ಸಾಮಾನ್ಯವಾಗಿ, ನೆಟ್ವರ್ಕ್ ಆರ್ಕಿಟೆಕ್ಚರ್ಗಳಲ್ಲಿ ಎರಡು ಮುಖ್ಯ ವಿಧಗಳಿವೆ: ಪೀರ್-ಟು-ಪೀರ್ ಮತ್ತು ಕ್ಲೈಂಟ್-ಸರ್ವರ್. ಪೀರ್-ಟು-ಪೀರ್ (p2p) ಆರ್ಕಿಟೆಕ್ಚರ್‌ನಲ್ಲಿ, ಯಾವುದೇ ಜೋಡಿ ಸಂಪರ್ಕಿತ ಆಟಗಾರರ ನಡುವೆ ಡೇಟಾವನ್ನು ವರ್ಗಾಯಿಸಲಾಗುತ್ತದೆ, ಆದರೆ ಕ್ಲೈಂಟ್-ಸರ್ವರ್ ಆರ್ಕಿಟೆಕ್ಚರ್‌ನಲ್ಲಿ, ಡೇಟಾವನ್ನು ಆಟಗಾರರು ಮತ್ತು ಸರ್ವರ್ ನಡುವೆ ಮಾತ್ರ ವರ್ಗಾಯಿಸಲಾಗುತ್ತದೆ.
ಪೀರ್-ಟು-ಪೀರ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ಇನ್ನೂ ಕೆಲವು ಆಟಗಳಲ್ಲಿ ಬಳಸಲಾಗಿದ್ದರೂ, ಕ್ಲೈಂಟ್-ಸರ್ವರ್ ಪ್ರಮಾಣಿತವಾಗಿದೆ: ಇದು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಸುಲಭವಾಗಿದೆ, ಸಣ್ಣ ಚಾನಲ್ ಅಗಲ ಅಗತ್ಯವಿರುತ್ತದೆ ಮತ್ತು ಮೋಸದಿಂದ ರಕ್ಷಿಸಲು ಸುಲಭವಾಗುತ್ತದೆ. ಆದ್ದರಿಂದ, ಈ ಟ್ಯುಟೋರಿಯಲ್ ನಲ್ಲಿ ನಾವು ಕ್ಲೈಂಟ್-ಸರ್ವರ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುತ್ತೇವೆ.
ನಿರ್ದಿಷ್ಟವಾಗಿ ಹೇಳುವುದಾದರೆ, ನಾವು ಸರ್ವಾಧಿಕಾರಿ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಹೆಚ್ಚು ಆಸಕ್ತಿ ಹೊಂದಿದ್ದೇವೆ: ಅಂತಹ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ, ಸರ್ವರ್ ಯಾವಾಗಲೂ ಸರಿಯಾಗಿರುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಆಟಗಾರನು ತಾನು ನಿರ್ದೇಶಾಂಕಗಳಲ್ಲಿ (10, 5) ಇದ್ದಾನೆ ಎಂದು ಭಾವಿಸಿದರೆ ಮತ್ತು ಸರ್ವರ್ ಅವನು (5, 3) ನಲ್ಲಿ ಇದ್ದಾನೆ ಎಂದು ಹೇಳಿದರೆ, ಕ್ಲೈಂಟ್ ತನ್ನ ಸ್ಥಾನವನ್ನು ಸರ್ವರ್ ವರದಿ ಮಾಡಿದ ಸ್ಥಾನದೊಂದಿಗೆ ಬದಲಾಯಿಸಬೇಕು ಮತ್ತು ವೈಸ್ ಅಲ್ಲ ಪ್ರತಿಯಾಗಿ. ಅಧಿಕೃತ ಸರ್ವರ್‌ಗಳನ್ನು ಬಳಸುವುದರಿಂದ ವಂಚಕರನ್ನು ಗುರುತಿಸುವುದು ಸುಲಭವಾಗುತ್ತದೆ.
ನೆಟ್ವರ್ಕ್ ಗೇಮಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗಳು ಮೂರು ಮುಖ್ಯ ಅಂಶಗಳನ್ನು ಹೊಂದಿವೆ:
- ಸಾರಿಗೆ ಪ್ರೋಟೋಕಾಲ್: ಕ್ಲೈಂಟ್‌ಗಳು ಮತ್ತು ಸರ್ವರ್ ನಡುವೆ ಡೇಟಾವನ್ನು ಹೇಗೆ ವರ್ಗಾಯಿಸಲಾಗುತ್ತದೆ.
- ಅಪ್ಲಿಕೇಶನ್ ಪ್ರೋಟೋಕಾಲ್: ಕ್ಲೈಂಟ್‌ಗಳಿಂದ ಸರ್ವರ್‌ಗೆ ಮತ್ತು ಸರ್ವರ್‌ನಿಂದ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಮತ್ತು ಯಾವ ಸ್ವರೂಪದಲ್ಲಿ ರವಾನೆಯಾಗುತ್ತದೆ.
- ಅಪ್ಲಿಕೇಶನ್ ತರ್ಕ: ಕ್ಲೈಂಟ್‌ಗಳು ಮತ್ತು ಸರ್ವರ್‌ನ ಸ್ಥಿತಿಯನ್ನು ನವೀಕರಿಸಲು ವರ್ಗಾವಣೆಗೊಂಡ ಡೇಟಾವನ್ನು ಹೇಗೆ ಬಳಸಲಾಗುತ್ತದೆ.
ಪ್ರತಿಯೊಂದು ಭಾಗದ ಪಾತ್ರ ಮತ್ತು ಅವುಗಳಿಗೆ ಸಂಬಂಧಿಸಿದ ಸವಾಲುಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಬಹಳ ಮುಖ್ಯ.
ಸಾರಿಗೆ ಪ್ರೋಟೋಕಾಲ್
ಸರ್ವರ್ ಮತ್ತು ಕ್ಲೈಂಟ್‌ಗಳ ನಡುವೆ ಡೇಟಾವನ್ನು ಸಾಗಿಸಲು ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದು ಮೊದಲ ಹಂತವಾಗಿದೆ. ಇದಕ್ಕಾಗಿ ಎರಡು ಇಂಟರ್ನೆಟ್ ಪ್ರೋಟೋಕಾಲ್‌ಗಳಿವೆ: и . ಆದರೆ ಅವುಗಳಲ್ಲಿ ಒಂದನ್ನು ಆಧರಿಸಿ ನಿಮ್ಮ ಸ್ವಂತ ಸಾರಿಗೆ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ನೀವು ರಚಿಸಬಹುದು ಅಥವಾ ಅವುಗಳನ್ನು ಬಳಸುವ ಲೈಬ್ರರಿಯನ್ನು ಬಳಸಬಹುದು.
TCP ಮತ್ತು UDP ಯ ಹೋಲಿಕೆ
TCP ಮತ್ತು UDP ಎರಡೂ ಆಧರಿಸಿವೆ . IP ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಮೂಲದಿಂದ ಸ್ವೀಕರಿಸುವವರಿಗೆ ರವಾನಿಸಲು ಅನುಮತಿಸುತ್ತದೆ, ಆದರೆ ಕಳುಹಿಸಿದ ಪ್ಯಾಕೆಟ್ ಸ್ವೀಕರಿಸುವವರಿಗೆ ಬೇಗ ಅಥವಾ ನಂತರ ತಲುಪುತ್ತದೆ, ಅದು ಒಮ್ಮೆಯಾದರೂ ಅದನ್ನು ತಲುಪುತ್ತದೆ ಮತ್ತು ಪ್ಯಾಕೆಟ್‌ಗಳ ಅನುಕ್ರಮವು ಸರಿಯಾಗಿ ಬರುತ್ತದೆ ಎಂದು ಖಾತರಿ ನೀಡುವುದಿಲ್ಲ. ಆದೇಶ. ಇದಲ್ಲದೆ, ಒಂದು ಪ್ಯಾಕೆಟ್ ಮೌಲ್ಯದಿಂದ ನೀಡಲಾದ ಸೀಮಿತ ಪ್ರಮಾಣದ ಡೇಟಾವನ್ನು ಮಾತ್ರ ಒಳಗೊಂಡಿರುತ್ತದೆ .
UDP ಕೇವಲ IP ಮೇಲಿನ ತೆಳುವಾದ ಪದರವಾಗಿದೆ. ಆದ್ದರಿಂದ, ಇದು ಅದೇ ಮಿತಿಗಳನ್ನು ಹೊಂದಿದೆ. ಇದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ, TCP ಹಲವು ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಹೊಂದಿದೆ. ಇದು ದೋಷ ಪರಿಶೀಲನೆಯೊಂದಿಗೆ ಎರಡು ನೋಡ್‌ಗಳ ನಡುವೆ ವಿಶ್ವಾಸಾರ್ಹ, ಕ್ರಮಬದ್ಧವಾದ ಸಂಪರ್ಕವನ್ನು ಒದಗಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ, TCP ತುಂಬಾ ಅನುಕೂಲಕರವಾಗಿದೆ ಮತ್ತು ಅನೇಕ ಇತರ ಪ್ರೋಟೋಕಾಲ್‌ಗಳಲ್ಲಿ ಬಳಸಲಾಗುತ್ತದೆ, ಉದಾ. , и . ಆದರೆ ಈ ಎಲ್ಲಾ ವೈಶಿಷ್ಟ್ಯಗಳು ಬೆಲೆಗೆ ಬರುತ್ತವೆ: .
ಈ ಕಾರ್ಯಗಳು ಏಕೆ ಸುಪ್ತತೆಯನ್ನು ಉಂಟುಮಾಡಬಹುದು ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, TCP ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನಾವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು. ಕಳುಹಿಸುವ ನೋಡ್ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಸ್ವೀಕರಿಸುವ ನೋಡ್‌ಗೆ ರವಾನಿಸಿದಾಗ, ಅದು ಸ್ವೀಕೃತಿಯನ್ನು (ACK) ಸ್ವೀಕರಿಸಲು ನಿರೀಕ್ಷಿಸುತ್ತದೆ. ಒಂದು ನಿರ್ದಿಷ್ಟ ಸಮಯದ ನಂತರ ಅದನ್ನು ಸ್ವೀಕರಿಸದಿದ್ದರೆ (ಪ್ಯಾಕೆಟ್ ಅಥವಾ ಸ್ವೀಕೃತಿ ಕಳೆದುಹೋದ ಕಾರಣ ಅಥವಾ ಬೇರೆ ಕಾರಣಕ್ಕಾಗಿ), ನಂತರ ಅದು ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಮರುಕಳಿಸುತ್ತದೆ. ಇದಲ್ಲದೆ, TCP ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಸರಿಯಾದ ಕ್ರಮದಲ್ಲಿ ಸ್ವೀಕರಿಸಲಾಗಿದೆ ಎಂದು ಖಾತರಿಪಡಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಕಳೆದುಹೋದ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಸ್ವೀಕರಿಸುವವರೆಗೆ, ಸ್ವೀಕರಿಸುವ ಹೋಸ್ಟ್‌ನಿಂದ ಈಗಾಗಲೇ ಸ್ವೀಕರಿಸಲ್ಪಟ್ಟಿದ್ದರೂ ಸಹ, ಎಲ್ಲಾ ಇತರ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗುವುದಿಲ್ಲ.
ಆದರೆ ನೀವು ಬಹುಶಃ ಊಹಿಸುವಂತೆ, ಮಲ್ಟಿಪ್ಲೇಯರ್ ಆಟಗಳಲ್ಲಿ ಲೇಟೆನ್ಸಿ ಬಹಳ ಮುಖ್ಯವಾಗಿದೆ, ವಿಶೇಷವಾಗಿ FPS ನಂತಹ ಆಕ್ಷನ್-ಪ್ಯಾಕ್ಡ್ ಪ್ರಕಾರಗಳಲ್ಲಿ. ಇದಕ್ಕಾಗಿಯೇ ಅನೇಕ ಆಟಗಳು ತಮ್ಮದೇ ಆದ ಪ್ರೋಟೋಕಾಲ್‌ನೊಂದಿಗೆ UDP ಅನ್ನು ಬಳಸುತ್ತವೆ.
ಸ್ಥಳೀಯ UDP ಆಧಾರಿತ ಪ್ರೋಟೋಕಾಲ್ ವಿವಿಧ ಕಾರಣಗಳಿಗಾಗಿ TCP ಗಿಂತ ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿರುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಇದು ಕೆಲವು ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ವಿಶ್ವಾಸಾರ್ಹವೆಂದು ಮತ್ತು ಇತರವು ವಿಶ್ವಾಸಾರ್ಹವಲ್ಲ ಎಂದು ಗುರುತಿಸಬಹುದು. ಆದ್ದರಿಂದ, ವಿಶ್ವಾಸಾರ್ಹವಲ್ಲದ ಪ್ಯಾಕೆಟ್ ಸ್ವೀಕರಿಸುವವರಿಗೆ ತಲುಪುತ್ತದೆಯೇ ಎಂದು ಅದು ಹೆದರುವುದಿಲ್ಲ. ಅಥವಾ ಇದು ಬಹು ಡೇಟಾ ಸ್ಟ್ರೀಮ್‌ಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬಹುದು ಇದರಿಂದ ಒಂದು ಸ್ಟ್ರೀಮ್‌ನಲ್ಲಿ ಕಳೆದುಹೋದ ಪ್ಯಾಕೆಟ್ ಉಳಿದ ಸ್ಟ್ರೀಮ್‌ಗಳನ್ನು ನಿಧಾನಗೊಳಿಸುವುದಿಲ್ಲ. ಉದಾಹರಣೆಗೆ, ಪ್ಲೇಯರ್ ಇನ್‌ಪುಟ್‌ಗಾಗಿ ಥ್ರೆಡ್ ಮತ್ತು ಚಾಟ್ ಸಂದೇಶಗಳಿಗಾಗಿ ಇನ್ನೊಂದು ಥ್ರೆಡ್ ಇರಬಹುದು. ತುರ್ತು ಅಲ್ಲದ ಚಾಟ್ ಸಂದೇಶವು ಕಳೆದುಹೋದರೆ, ಅದು ತುರ್ತು ಇನ್ಪುಟ್ ಅನ್ನು ನಿಧಾನಗೊಳಿಸುವುದಿಲ್ಲ. ಅಥವಾ ಒಡೆತನದ ಪ್ರೋಟೋಕಾಲ್ ವೀಡಿಯೋ ಗೇಮ್ ಪರಿಸರದಲ್ಲಿ ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿರಲು TCP ಗಿಂತ ವಿಭಿನ್ನವಾಗಿ ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು.
ಆದ್ದರಿಂದ, TCP ತುಂಬಾ ಹೀರಿಕೊಂಡರೆ, ನಾವು UDP ಅನ್ನು ಆಧರಿಸಿ ನಮ್ಮ ಸ್ವಂತ ಸಾರಿಗೆ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ರಚಿಸುತ್ತೇವೆಯೇ?
ಇದು ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗಿದೆ. ಗೇಮಿಂಗ್ ನೆಟ್ವರ್ಕ್ ಸಿಸ್ಟಮ್‌ಗಳಿಗೆ TCP ಬಹುತೇಕ ಉಪೋತ್ಕೃಷ್ಟವಾಗಿದ್ದರೂ ಸಹ, ಇದು ನಿಮ್ಮ ನಿರ್ದಿಷ್ಟ ಆಟಕ್ಕೆ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ನಿಮ್ಮ ಅಮೂಲ್ಯ ಸಮಯವನ್ನು ಉಳಿಸುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಟರ್ನ್-ಆಧಾರಿತ ಆಟ ಅಥವಾ LAN ನೆಟ್‌ವರ್ಕ್‌ಗಳಲ್ಲಿ ಮಾತ್ರ ಆಡಬಹುದಾದ ಆಟಕ್ಕೆ ಲೇಟೆನ್ಸಿ ಸಮಸ್ಯೆಯಾಗದಿರಬಹುದು, ಅಲ್ಲಿ ಲೇಟೆನ್ಸಿ ಮತ್ತು ಪ್ಯಾಕೆಟ್ ನಷ್ಟವು ಇಂಟರ್ನೆಟ್‌ಗಿಂತ ಕಡಿಮೆ ಇರುತ್ತದೆ.
ವರ್ಲ್ಡ್ ಆಫ್ ವಾರ್ಕ್ರಾಫ್ಟ್, Minecraft ಮತ್ತು Terraria ಸೇರಿದಂತೆ ಅನೇಕ ಯಶಸ್ವಿ ಆಟಗಳು TCP ಅನ್ನು ಬಳಸುತ್ತವೆ. ಆದಾಗ್ಯೂ, ಹೆಚ್ಚಿನ FPS ಗಳು ತಮ್ಮದೇ ಆದ UDP-ಆಧಾರಿತ ಪ್ರೋಟೋಕಾಲ್‌ಗಳನ್ನು ಬಳಸುತ್ತವೆ, ಆದ್ದರಿಂದ ನಾವು ಅವುಗಳ ಬಗ್ಗೆ ಕೆಳಗೆ ಹೆಚ್ಚು ಮಾತನಾಡುತ್ತೇವೆ.
ನೀವು TCP ಬಳಸಲು ನಿರ್ಧರಿಸಿದರೆ, ಅದನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ , ಏಕೆಂದರೆ ಇದು ಕಳುಹಿಸುವ ಮೊದಲು ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಬಫರ್ ಮಾಡುತ್ತದೆ, ಅಂದರೆ ಇದು ಸುಪ್ತತೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ.
ಮಲ್ಟಿಪ್ಲೇಯರ್ ಆಟಗಳ ಸಂದರ್ಭದಲ್ಲಿ UDP ಮತ್ತು TCP ನಡುವಿನ ವ್ಯತ್ಯಾಸಗಳ ಬಗ್ಗೆ ಇನ್ನಷ್ಟು ತಿಳಿದುಕೊಳ್ಳಲು, ನೀವು ಗ್ಲೆನ್ ಫೀಡ್ಲರ್ ಅವರ ಲೇಖನವನ್ನು ಓದಬಹುದು .
ಸ್ವಂತ ಪ್ರೋಟೋಕಾಲ್
ಆದ್ದರಿಂದ ನೀವು ನಿಮ್ಮ ಸ್ವಂತ ಸಾರಿಗೆ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ರಚಿಸಲು ಬಯಸುತ್ತೀರಿ, ಆದರೆ ಎಲ್ಲಿ ಪ್ರಾರಂಭಿಸಬೇಕು ಎಂದು ತಿಳಿದಿಲ್ಲವೇ? ನೀವು ಅದೃಷ್ಟವಂತರು ಏಕೆಂದರೆ ಗ್ಲೆನ್ ಫೀಡ್ಲರ್ ಈ ಬಗ್ಗೆ ಎರಡು ಅದ್ಭುತ ಲೇಖನಗಳನ್ನು ಬರೆದಿದ್ದಾರೆ. ನೀವು ಅವರಲ್ಲಿ ಸಾಕಷ್ಟು ಸ್ಮಾರ್ಟ್ ಆಲೋಚನೆಗಳನ್ನು ಕಾಣಬಹುದು.
ಮೊದಲ ಲೇಖನ 2008, ಎರಡನೆಯದಕ್ಕಿಂತ ಸುಲಭ, 2016. ನೀವು ಹಳೆಯದರೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಲು ನಾನು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ.
ಗ್ಲೆನ್ ಫೀಡ್ಲರ್ ಯುಡಿಪಿ ಆಧಾರಿತ ಕಸ್ಟಮ್ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಬಳಸುವ ದೊಡ್ಡ ಪ್ರತಿಪಾದಕರಾಗಿದ್ದಾರೆ ಎಂಬುದನ್ನು ಗಮನಿಸಿ. ಮತ್ತು ಅವರ ಲೇಖನಗಳನ್ನು ಓದಿದ ನಂತರ, ವೀಡಿಯೊ ಆಟಗಳಲ್ಲಿ TCP ಗಂಭೀರ ನ್ಯೂನತೆಗಳನ್ನು ಹೊಂದಿದೆ ಎಂದು ನೀವು ಬಹುಶಃ ಅವರ ಅಭಿಪ್ರಾಯವನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳುತ್ತೀರಿ ಮತ್ತು ನಿಮ್ಮ ಸ್ವಂತ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ನೀವು ಬಯಸುತ್ತೀರಿ.
ಆದರೆ ನೀವು ನೆಟ್‌ವರ್ಕಿಂಗ್‌ಗೆ ಹೊಸಬರಾಗಿದ್ದರೆ, ನೀವೇ ಸಹಾಯ ಮಾಡಿ ಮತ್ತು TCP ಅಥವಾ ಲೈಬ್ರರಿಯನ್ನು ಬಳಸಿ. ನಿಮ್ಮ ಸ್ವಂತ ಸಾರಿಗೆ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಲು, ನೀವು ಮುಂಚಿತವಾಗಿ ಬಹಳಷ್ಟು ಕಲಿಯಬೇಕು.
ನೆಟ್ವರ್ಕ್ ಲೈಬ್ರರಿಗಳು
ನಿಮಗೆ TCP ಗಿಂತ ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾದ ಏನಾದರೂ ಅಗತ್ಯವಿದ್ದರೆ, ಆದರೆ ನಿಮ್ಮ ಸ್ವಂತ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಮತ್ತು ಹೆಚ್ಚಿನ ವಿವರಗಳಿಗೆ ಹೋಗುವ ಜಗಳದ ಮೂಲಕ ಹೋಗಲು ಬಯಸದಿದ್ದರೆ, ನೀವು ನೆಟ್ವರ್ಕಿಂಗ್ ಲೈಬ್ರರಿಯನ್ನು ಬಳಸಬಹುದು. ಅವುಗಳಲ್ಲಿ ಬಹಳಷ್ಟು ಇವೆ:
- ಗ್ಲೆನ್ ಫೀಡ್ಲರ್
- , ಇದು ಇನ್ನು ಮುಂದೆ ಬೆಂಬಲಿಸುವುದಿಲ್ಲ, ಆದರೆ ಅದರ ಫೋರ್ಕ್ ಇದು ಇನ್ನೂ ಸಕ್ರಿಯವಾಗಿರುವಂತೆ ತೋರುತ್ತಿದೆ.
- ಮಲ್ಟಿಪ್ಲೇಯರ್ FPS ಗಾಗಿ ರಚಿಸಲಾದ ಗ್ರಂಥಾಲಯವಾಗಿದೆ
- ಕವಾಟ
ನಾನು ಅವೆಲ್ಲವನ್ನೂ ಪ್ರಯತ್ನಿಸಿಲ್ಲ, ಆದರೆ ನಾನು ENet ಅನ್ನು ಆದ್ಯತೆ ನೀಡುತ್ತೇನೆ ಏಕೆಂದರೆ ಇದು ಬಳಸಲು ಸುಲಭ ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿದೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಇದು ಸ್ಪಷ್ಟ ದಾಖಲಾತಿ ಮತ್ತು ಆರಂಭಿಕರಿಗಾಗಿ ಟ್ಯುಟೋರಿಯಲ್ ಅನ್ನು ಹೊಂದಿದೆ.
ಸಾರಿಗೆ ಪ್ರೋಟೋಕಾಲ್: ತೀರ್ಮಾನ
ಸಂಕ್ಷಿಪ್ತವಾಗಿ ಹೇಳುವುದಾದರೆ: ಎರಡು ಮುಖ್ಯ ಸಾರಿಗೆ ಪ್ರೋಟೋಕಾಲ್‌ಗಳಿವೆ: TCP ಮತ್ತು UDP. TCP ಅನೇಕ ಉಪಯುಕ್ತ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಹೊಂದಿದೆ: ವಿಶ್ವಾಸಾರ್ಹತೆ, ಪ್ಯಾಕೆಟ್ ಆರ್ಡರ್ ಸಂರಕ್ಷಣೆ, ದೋಷ ಪತ್ತೆ. UDP ಇದೆಲ್ಲವನ್ನೂ ಹೊಂದಿಲ್ಲ, ಆದರೆ TCP ಅದರ ಸ್ವಭಾವದಿಂದ ಸುಪ್ತತೆಯನ್ನು ಹೆಚ್ಚಿಸಿದೆ, ಇದು ಕೆಲವು ಆಟಗಳಿಗೆ ಸ್ವೀಕಾರಾರ್ಹವಲ್ಲ. ಅಂದರೆ, ಕಡಿಮೆ ಸುಪ್ತತೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು, ನೀವು UDP ಆಧಾರದ ಮೇಲೆ ನಿಮ್ಮ ಸ್ವಂತ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ರಚಿಸಬಹುದು ಅಥವಾ UDP ಯಲ್ಲಿ ಸಾರಿಗೆ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಅಳವಡಿಸುವ ಮತ್ತು ಮಲ್ಟಿಪ್ಲೇಯರ್ ವೀಡಿಯೊ ಗೇಮ್‌ಗಳಿಗೆ ಅಳವಡಿಸಲಾಗಿರುವ ಲೈಬ್ರರಿಯನ್ನು ಬಳಸಬಹುದು.
TCP, UDP ಮತ್ತು ಲೈಬ್ರರಿಯ ನಡುವಿನ ಆಯ್ಕೆಯು ಹಲವಾರು ಅಂಶಗಳನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ. ಮೊದಲಿಗೆ, ಆಟದ ಅಗತ್ಯಗಳಿಂದ: ಇದು ಕಡಿಮೆ ಸುಪ್ತತೆ ಅಗತ್ಯವಿದೆಯೇ? ಎರಡನೆಯದಾಗಿ, ಅಪ್ಲಿಕೇಶನ್ ಪ್ರೋಟೋಕಾಲ್ ಅವಶ್ಯಕತೆಗಳಿಂದ: ಇದಕ್ಕೆ ವಿಶ್ವಾಸಾರ್ಹ ಪ್ರೋಟೋಕಾಲ್ ಅಗತ್ಯವಿದೆಯೇ? ಮುಂದಿನ ಭಾಗದಲ್ಲಿ ನಾವು ನೋಡುವಂತೆ, ವಿಶ್ವಾಸಾರ್ಹವಲ್ಲದ ಪ್ರೋಟೋಕಾಲ್ ಸಾಕಷ್ಟು ಸೂಕ್ತವಾದ ಅಪ್ಲಿಕೇಶನ್ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ರಚಿಸಲು ಸಾಧ್ಯವಿದೆ. ಅಂತಿಮವಾಗಿ, ನೀವು ನೆಟ್ವರ್ಕ್ ಎಂಜಿನ್ ಡೆವಲಪರ್ನ ಅನುಭವವನ್ನು ಸಹ ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಬೇಕಾಗುತ್ತದೆ.
ನನಗೆ ಎರಡು ಸಲಹೆಗಳಿವೆ:
- ಸಾರಿಗೆ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಉಳಿದ ಅಪ್ಲಿಕೇಶನ್‌ನಿಂದ ಸಾಧ್ಯವಾದಷ್ಟು ಅಮೂರ್ತಗೊಳಿಸಿ ಇದರಿಂದ ಎಲ್ಲಾ ಕೋಡ್ ಅನ್ನು ಪುನಃ ಬರೆಯದೆಯೇ ಅದನ್ನು ಸುಲಭವಾಗಿ ಬದಲಾಯಿಸಬಹುದು.
- ಅತಿಯಾಗಿ ಆಪ್ಟಿಮೈಸ್ ಮಾಡಬೇಡಿ. ನೀವು ನೆಟ್ವರ್ಕಿಂಗ್ ಪರಿಣತರಲ್ಲದಿದ್ದರೆ ಮತ್ತು ನಿಮಗೆ ಕಸ್ಟಮ್ UDP-ಆಧಾರಿತ ಸಾರಿಗೆ ಪ್ರೋಟೋಕಾಲ್ ಅಗತ್ಯವಿದೆಯೇ ಎಂದು ಖಚಿತವಾಗಿರದಿದ್ದರೆ, ನೀವು TCP ಅಥವಾ ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ಒದಗಿಸುವ ಲೈಬ್ರರಿಯೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಬಹುದು ಮತ್ತು ನಂತರ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಪರೀಕ್ಷಿಸಿ ಮತ್ತು ಅಳೆಯಬಹುದು. ಸಮಸ್ಯೆಗಳು ಉದ್ಭವಿಸಿದರೆ ಮತ್ತು ಕಾರಣವೆಂದರೆ ಸಾರಿಗೆ ಪ್ರೋಟೋಕಾಲ್ ಎಂದು ನಿಮಗೆ ವಿಶ್ವಾಸವಿದ್ದರೆ, ನಿಮ್ಮ ಸ್ವಂತ ಸಾರಿಗೆ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ರಚಿಸುವ ಸಮಯ ಇರಬಹುದು.
ಈ ಭಾಗದ ಕೊನೆಯಲ್ಲಿ, ನೀವು ಓದಲು ನಾನು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ ಬ್ರಿಯಾನ್ ಹುಕ್ ಅವರಿಂದ, ಇಲ್ಲಿ ಚರ್ಚಿಸಲಾದ ಹಲವು ವಿಷಯಗಳನ್ನು ಒಳಗೊಂಡಿದೆ.
ಅಪ್ಲಿಕೇಶನ್ ಪ್ರೋಟೋಕಾಲ್
ಈಗ ನಾವು ಕ್ಲೈಂಟ್‌ಗಳು ಮತ್ತು ಸರ್ವರ್ ನಡುವೆ ಡೇಟಾವನ್ನು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳಬಹುದು, ಯಾವ ಡೇಟಾವನ್ನು ವರ್ಗಾಯಿಸಬೇಕು ಮತ್ತು ಯಾವ ಸ್ವರೂಪದಲ್ಲಿ ನಾವು ನಿರ್ಧರಿಸಬೇಕು.
ಕ್ಲೈಂಟ್‌ಗಳು ಸರ್ವರ್‌ಗೆ ಇನ್ಪುಟ್ ಅಥವಾ ಕ್ರಿಯೆಗಳನ್ನು ಕಳುಹಿಸುವುದು ಕ್ಲಾಸಿಕ್ ಸ್ಕೀಮ್, ಮತ್ತು ಸರ್ವರ್ ಪ್ರಸ್ತುತ ಆಟದ ಸ್ಥಿತಿಯನ್ನು ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಕಳುಹಿಸುತ್ತದೆ.
ಸರ್ವರ್ ಪೂರ್ಣ ಸ್ಥಿತಿಯನ್ನು ಕಳುಹಿಸುವುದಿಲ್ಲ, ಆದರೆ ಆಟಗಾರನ ಬಳಿ ಇರುವ ಘಟಕಗಳೊಂದಿಗೆ ಫಿಲ್ಟರ್ ಮಾಡಲಾದ ಸ್ಥಿತಿಯನ್ನು ಕಳುಹಿಸುತ್ತದೆ. ಅವನು ಇದನ್ನು ಮೂರು ಕಾರಣಗಳಿಗಾಗಿ ಮಾಡುತ್ತಾನೆ. ಮೊದಲನೆಯದಾಗಿ, ಹೆಚ್ಚಿನ ಆವರ್ತನದಲ್ಲಿ ಹರಡಲು ಸಂಪೂರ್ಣ ಸ್ಥಿತಿಯು ತುಂಬಾ ದೊಡ್ಡದಾಗಿರಬಹುದು. ಎರಡನೆಯದಾಗಿ, ಕ್ಲೈಂಟ್‌ಗಳು ಮುಖ್ಯವಾಗಿ ದೃಶ್ಯ ಮತ್ತು ಆಡಿಯೊ ಡೇಟಾದಲ್ಲಿ ಆಸಕ್ತರಾಗಿರುತ್ತಾರೆ, ಏಕೆಂದರೆ ಹೆಚ್ಚಿನ ಆಟದ ತರ್ಕವನ್ನು ಆಟದ ಸರ್ವರ್‌ನಲ್ಲಿ ಅನುಕರಿಸಲಾಗುತ್ತದೆ. ಮೂರನೆಯದಾಗಿ, ಕೆಲವು ಆಟಗಳಲ್ಲಿ ಆಟಗಾರನು ನಿರ್ದಿಷ್ಟ ಡೇಟಾವನ್ನು ತಿಳಿದುಕೊಳ್ಳಬೇಕಾಗಿಲ್ಲ, ಉದಾಹರಣೆಗೆ, ನಕ್ಷೆಯ ಇನ್ನೊಂದು ಬದಿಯಲ್ಲಿ ಶತ್ರುಗಳ ಸ್ಥಾನ, ಇಲ್ಲದಿದ್ದರೆ ಅವನು ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಕಸಿದುಕೊಳ್ಳಬಹುದು ಮತ್ತು ಅವನನ್ನು ಕೊಲ್ಲಲು ಎಲ್ಲಿಗೆ ಹೋಗಬೇಕೆಂದು ನಿಖರವಾಗಿ ತಿಳಿಯಬಹುದು.
ಧಾರಾವಾಹಿ
ನಾವು ಕಳುಹಿಸಲು ಬಯಸುವ ಡೇಟಾವನ್ನು (ಇನ್ಪುಟ್ ಅಥವಾ ಆಟದ ಸ್ಥಿತಿ) ಪ್ರಸರಣಕ್ಕೆ ಸೂಕ್ತವಾದ ಸ್ವರೂಪಕ್ಕೆ ಪರಿವರ್ತಿಸುವುದು ಮೊದಲ ಹಂತವಾಗಿದೆ. ಈ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಕರೆಯಲಾಗುತ್ತದೆ .
JSON ಅಥವಾ XML ನಂತಹ ಮಾನವ-ಓದಬಲ್ಲ ಸ್ವರೂಪವನ್ನು ಬಳಸುವುದು ತಕ್ಷಣವೇ ಮನಸ್ಸಿಗೆ ಬರುವ ಆಲೋಚನೆಯಾಗಿದೆ. ಆದರೆ ಇದು ಸಂಪೂರ್ಣವಾಗಿ ನಿಷ್ಪರಿಣಾಮಕಾರಿಯಾಗಿರುತ್ತದೆ ಮತ್ತು ಹೆಚ್ಚಿನ ಚಾನಲ್ ಅನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತದೆ.
ಬದಲಿಗೆ ಬೈನರಿ ಸ್ವರೂಪವನ್ನು ಬಳಸಲು ಶಿಫಾರಸು ಮಾಡಲಾಗಿದೆ, ಇದು ಹೆಚ್ಚು ಸಾಂದ್ರವಾಗಿರುತ್ತದೆ. ಅಂದರೆ, ಪ್ಯಾಕೆಟ್‌ಗಳು ಕೆಲವು ಬೈಟ್‌ಗಳನ್ನು ಮಾತ್ರ ಒಳಗೊಂಡಿರುತ್ತವೆ. ಇಲ್ಲಿ ಪರಿಗಣಿಸಬೇಕಾದ ಸಮಸ್ಯೆ ಇದೆ , ಇದು ವಿವಿಧ ಕಂಪ್ಯೂಟರ್‌ಗಳಲ್ಲಿ ಭಿನ್ನವಾಗಿರಬಹುದು.
ಡೇಟಾವನ್ನು ಧಾರಾವಾಹಿ ಮಾಡಲು, ನೀವು ಲೈಬ್ರರಿಯನ್ನು ಬಳಸಬಹುದು, ಉದಾಹರಣೆಗೆ:
- ಗೂಗಲ್
- ಮರಳುಗಾಳಿ ಕಂಪನಿ
- ಶೇನ್ ಗ್ರಾಂಟ್ ಮತ್ತು ರಾಂಡೋಲ್ಫ್ ವೂರ್ಹೀಸ್
ಲೈಬ್ರರಿಯು ಪೋರ್ಟಬಲ್ ಆರ್ಕೈವ್‌ಗಳನ್ನು ರಚಿಸುತ್ತದೆ ಮತ್ತು ಅಂತ್ಯದ ಬಗ್ಗೆ ಕಾಳಜಿ ವಹಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.
ಪರ್ಯಾಯ ಪರಿಹಾರವೆಂದರೆ ಅದನ್ನು ನೀವೇ ಕಾರ್ಯಗತಗೊಳಿಸುವುದು; ಇದು ವಿಶೇಷವಾಗಿ ಕಷ್ಟಕರವಲ್ಲ, ವಿಶೇಷವಾಗಿ ನಿಮ್ಮ ಕೋಡ್‌ಗೆ ಡೇಟಾ-ಕೇಂದ್ರಿತ ವಿಧಾನವನ್ನು ನೀವು ಬಳಸಿದರೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಲೈಬ್ರರಿಯನ್ನು ಬಳಸುವಾಗ ಯಾವಾಗಲೂ ಸಾಧ್ಯವಾಗದ ಆಪ್ಟಿಮೈಸೇಶನ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ.
ಗ್ಲೆನ್ ಫೀಡ್ಲರ್ ಧಾರಾವಾಹಿಯ ಬಗ್ಗೆ ಎರಡು ಲೇಖನಗಳನ್ನು ಬರೆದಿದ್ದಾರೆ: и .
ಸಂಕೋಚನ
ಕ್ಲೈಂಟ್‌ಗಳು ಮತ್ತು ಸರ್ವರ್ ನಡುವೆ ವರ್ಗಾಯಿಸಲಾದ ಡೇಟಾದ ಪ್ರಮಾಣವು ಚಾನಲ್‌ನ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್‌ನಿಂದ ಸೀಮಿತವಾಗಿದೆ. ಡೇಟಾ ಕಂಪ್ರೆಷನ್ ಪ್ರತಿ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ನಲ್ಲಿ ಹೆಚ್ಚಿನ ಡೇಟಾವನ್ನು ವರ್ಗಾಯಿಸಲು, ನವೀಕರಣ ಆವರ್ತನವನ್ನು ಹೆಚ್ಚಿಸಲು ಅಥವಾ ಚಾನಲ್ ಅವಶ್ಯಕತೆಗಳನ್ನು ಕಡಿಮೆ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.
ಬಿಟ್ ಪ್ಯಾಕೇಜಿಂಗ್
ಮೊದಲ ತಂತ್ರವೆಂದರೆ ಬಿಟ್ ಪ್ಯಾಕಿಂಗ್. ಅಪೇಕ್ಷಿತ ಮೌಲ್ಯವನ್ನು ವಿವರಿಸಲು ಅಗತ್ಯವಿರುವ ಬಿಟ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ನಿಖರವಾಗಿ ಬಳಸುವುದನ್ನು ಇದು ಒಳಗೊಂಡಿದೆ. ಉದಾಹರಣೆಗೆ, ನೀವು 16 ವಿಭಿನ್ನ ಮೌಲ್ಯಗಳನ್ನು ಹೊಂದಿರುವ enum ಹೊಂದಿದ್ದರೆ, ನಂತರ ಸಂಪೂರ್ಣ ಬೈಟ್ (8 ಬಿಟ್‌ಗಳು) ಬದಲಿಗೆ, ನೀವು ಕೇವಲ 4 ಬಿಟ್‌ಗಳನ್ನು ಬಳಸಬಹುದು.
ಲೇಖನದ ಎರಡನೇ ಭಾಗದಲ್ಲಿ ಇದನ್ನು ಹೇಗೆ ಕಾರ್ಯಗತಗೊಳಿಸಬೇಕು ಎಂಬುದನ್ನು ಗ್ಲೆನ್ ಫೀಡ್ಲರ್ ವಿವರಿಸಿದ್ದಾರೆ .
ಬಿಟ್ ಪ್ಯಾಕಿಂಗ್ ವಿಶೇಷವಾಗಿ ಮಾದರಿಯೊಂದಿಗೆ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಇದು ಮುಂದಿನ ವಿಭಾಗದ ವಿಷಯವಾಗಿರುತ್ತದೆ.
ಮಾದರಿ
ಮೌಲ್ಯವನ್ನು ಎನ್ಕೋಡ್ ಮಾಡಲು ಸಂಭವನೀಯ ಮೌಲ್ಯಗಳ ಉಪವಿಭಾಗವನ್ನು ಮಾತ್ರ ಬಳಸುವ ನಷ್ಟದ ಸಂಕುಚಿತ ತಂತ್ರವಾಗಿದೆ. ಫ್ಲೋಟಿಂಗ್ ಪಾಯಿಂಟ್ ಸಂಖ್ಯೆಗಳನ್ನು ಪೂರ್ಣಗೊಳಿಸುವ ಮೂಲಕ ವಿವೇಚನೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಸುಲಭವಾದ ಮಾರ್ಗವಾಗಿದೆ.
ಗ್ಲೆನ್ ಫೀಡ್ಲರ್ (ಮತ್ತೆ!) ತನ್ನ ಲೇಖನದಲ್ಲಿ ಮಾದರಿಯನ್ನು ಹೇಗೆ ಅಭ್ಯಾಸ ಮಾಡಬೇಕೆಂದು ತೋರಿಸುತ್ತಾನೆ .
ಸಂಕೋಚನ ಕ್ರಮಾವಳಿಗಳು
ಮುಂದಿನ ತಂತ್ರವು ನಷ್ಟವಿಲ್ಲದ ಸಂಕೋಚನ ಕ್ರಮಾವಳಿಗಳಾಗಿರುತ್ತದೆ.
ಇಲ್ಲಿ, ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ನೀವು ತಿಳಿದುಕೊಳ್ಳಬೇಕಾದ ಮೂರು ಅತ್ಯಂತ ಆಸಕ್ತಿದಾಯಕ ಅಲ್ಗಾರಿದಮ್‌ಗಳು:
- ಪೂರ್ವ-ಕಂಪ್ಯೂಟೆಡ್ ಕೋಡ್‌ನೊಂದಿಗೆ, ಇದು ಅತ್ಯಂತ ವೇಗವಾಗಿರುತ್ತದೆ ಮತ್ತು ಉತ್ತಮ ಫಲಿತಾಂಶಗಳನ್ನು ನೀಡುತ್ತದೆ. Quake3 ನೆಟ್ವರ್ಕಿಂಗ್ ಎಂಜಿನ್‌ನಲ್ಲಿ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಸಂಕುಚಿತಗೊಳಿಸಲು ಇದನ್ನು ಬಳಸಲಾಯಿತು.
- ಸಾಮಾನ್ಯ ಉದ್ದೇಶದ ಸಂಕುಚಿತ ಅಲ್ಗಾರಿದಮ್ ಆಗಿದ್ದು ಅದು ಡೇಟಾದ ಪ್ರಮಾಣವನ್ನು ಎಂದಿಗೂ ಹೆಚ್ಚಿಸುವುದಿಲ್ಲ. ನೀವು ಹೇಗೆ ನೋಡಬಹುದು , ಇದನ್ನು ವಿವಿಧ ಅನ್ವಯಗಳಲ್ಲಿ ಬಳಸಲಾಗಿದೆ. ರಾಜ್ಯಗಳನ್ನು ನವೀಕರಿಸಲು ಇದು ಅನಗತ್ಯವಾಗಿರಬಹುದು. ಆದರೆ ನೀವು ಸರ್ವರ್‌ನಿಂದ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಸ್ವತ್ತುಗಳು, ದೀರ್ಘ ಪಠ್ಯಗಳು ಅಥವಾ ಭೂಪ್ರದೇಶವನ್ನು ಕಳುಹಿಸಬೇಕಾದರೆ ಅದು ಉಪಯುಕ್ತವಾಗಿರುತ್ತದೆ.
- - ಇದು ಬಹುಶಃ ಸರಳವಾದ ಸಂಕೋಚನ ಅಲ್ಗಾರಿದಮ್ ಆಗಿದೆ, ಆದರೆ ಇದು ಕೆಲವು ಪ್ರಕಾರದ ಡೇಟಾಗೆ ತುಂಬಾ ಪರಿಣಾಮಕಾರಿಯಾಗಿದೆ ಮತ್ತು zlib ಮೊದಲು ಪೂರ್ವ-ಸಂಸ್ಕರಣೆಯ ಹಂತವಾಗಿ ಬಳಸಬಹುದು. ಟೈಲ್ಸ್ ಅಥವಾ ವೋಕ್ಸೆಲ್‌ಗಳಿಂದ ಕೂಡಿದ ಭೂಪ್ರದೇಶವನ್ನು ಸಂಕುಚಿತಗೊಳಿಸಲು ಇದು ವಿಶೇಷವಾಗಿ ಸೂಕ್ತವಾಗಿದೆ, ಇದರಲ್ಲಿ ಅನೇಕ ಪಕ್ಕದ ಅಂಶಗಳು ಪುನರಾವರ್ತನೆಯಾಗುತ್ತವೆ.
ಡೆಲ್ಟಾ ಕಂಪ್ರೆಷನ್
ಕೊನೆಯ ಕಂಪ್ರೆಷನ್ ತಂತ್ರವೆಂದರೆ ಡೆಲ್ಟಾ ಕಂಪ್ರೆಷನ್. ಪ್ರಸ್ತುತ ಆಟದ ಸ್ಥಿತಿ ಮತ್ತು ಕ್ಲೈಂಟ್ ಸ್ವೀಕರಿಸಿದ ಕೊನೆಯ ಸ್ಥಿತಿಯ ನಡುವಿನ ವ್ಯತ್ಯಾಸಗಳು ಮಾತ್ರ ಹರಡುತ್ತವೆ ಎಂಬ ಅಂಶವನ್ನು ಇದು ಒಳಗೊಂಡಿದೆ.
ಇದನ್ನು ಮೊದಲು Quake3 ನೆಟ್ವರ್ಕ್ ಎಂಜಿನ್‌ನಲ್ಲಿ ಬಳಸಲಾಯಿತು. ಅದನ್ನು ಹೇಗೆ ಬಳಸುವುದು ಎಂಬುದನ್ನು ವಿವರಿಸುವ ಎರಡು ಲೇಖನಗಳು ಇಲ್ಲಿವೆ:
- ಬ್ರಿಯಾನ್ ಹುಕ್
- ಫ್ಯಾಬಿಯನ್ ಸಾಂಗ್ಲರ್ಸ್ [ ಹಬ್ರೆ ಲೇಖನಗಳು, ವಿಭಾಗವನ್ನು ನೋಡಿ “ನೆಟ್ವರ್ಕ್ ಮಾದರಿ”]
ಗ್ಲೆನ್ ಫೀಡ್ಲರ್ ತನ್ನ ಲೇಖನದ ಎರಡನೇ ಭಾಗದಲ್ಲಿ ಇದನ್ನು ಬಳಸಿದ್ದಾನೆ .
ಗೂ ry ಲಿಪೀಕರಣ
ಹೆಚ್ಚುವರಿಯಾಗಿ, ಕ್ಲೈಂಟ್‌ಗಳು ಮತ್ತು ಸರ್ವರ್ ನಡುವಿನ ಮಾಹಿತಿಯ ವರ್ಗಾವಣೆಯನ್ನು ನೀವು ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಬೇಕಾಗಬಹುದು. ಇದಕ್ಕೆ ಹಲವಾರು ಕಾರಣಗಳಿವೆ:
- ಗೌಪ್ಯತೆ/ಗೌಪ್ಯತೆ: ಸಂದೇಶಗಳನ್ನು ಸ್ವೀಕರಿಸುವವರು ಮಾತ್ರ ಓದಬಹುದು ಮತ್ತು ನೆಟ್ವರ್ಕ್ ಅನ್ನು ಸ್ನಿಫ್ ಮಾಡುವ ಯಾವುದೇ ವ್ಯಕ್ತಿಗೆ ಅವುಗಳನ್ನು ಓದಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ.
- ದೃಢೀಕರಣ: ಆಟಗಾರನ ಪಾತ್ರವನ್ನು ನಿರ್ವಹಿಸಲು ಬಯಸುವ ವ್ಯಕ್ತಿಯು ತನ್ನ ಕೀಲಿಯನ್ನು ತಿಳಿದಿರಬೇಕು.
- ಮೋಸ ತಡೆಗಟ್ಟುವಿಕೆ: ದುರುದ್ದೇಶಪೂರಿತ ಆಟಗಾರರು ತಮ್ಮದೇ ಆದ ಚೀಟ್ ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ರಚಿಸುವುದು ಹೆಚ್ಚು ಕಷ್ಟಕರವಾಗಿರುತ್ತದೆ, ಅವರು ಎನ್ಕ್ರಿಪ್ಶನ್ ಸ್ಕೀಮ್ ಅನ್ನು ಪುನರುತ್ಪಾದಿಸಬೇಕು ಮತ್ತು ಕೀಲಿಯನ್ನು ಕಂಡುಹಿಡಿಯಬೇಕು (ಇದು ಪ್ರತಿ ಸಂಪರ್ಕದೊಂದಿಗೆ ಬದಲಾಗುತ್ತದೆ).
ಇದಕ್ಕಾಗಿ ಲೈಬ್ರರಿಯನ್ನು ಬಳಸಲು ನಾನು ಬಲವಾಗಿ ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ. ಬಳಸಲು ನಾನು ಸಲಹೆ ನೀಡುತ್ತೇನೆ , ಏಕೆಂದರೆ ಇದು ವಿಶೇಷವಾಗಿ ಸರಳವಾಗಿದೆ ಮತ್ತು ಅತ್ಯುತ್ತಮ ಟ್ಯುಟೋರಿಯಲ್‌ಗಳನ್ನು ಹೊಂದಿದೆ. ಟ್ಯುಟೋರಿಯಲ್ ವಿಶೇಷವಾಗಿ ಆಸಕ್ತಿದಾಯಕವಾಗಿದೆ , ಇದು ಪ್ರತಿ ಹೊಸ ಸಂಪರ್ಕದೊಂದಿಗೆ ಹೊಸ ಕೀಗಳನ್ನು ರಚಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.
ಅಪ್ಲಿಕೇಶನ್ ಪ್ರೋಟೋಕಾಲ್: ತೀರ್ಮಾನ
ಇದು ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಮುಕ್ತಾಯಗೊಳಿಸುತ್ತದೆ. ಸಂಕೋಚನವು ಸಂಪೂರ್ಣವಾಗಿ ಐಚ್ಛಿಕವಾಗಿದೆ ಮತ್ತು ಅದನ್ನು ಬಳಸುವ ನಿರ್ಧಾರವು ಆಟ ಮತ್ತು ಅಗತ್ಯವಿರುವ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್‌ನ ಮೇಲೆ ಮಾತ್ರ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ ಎಂದು ನಾನು ನಂಬುತ್ತೇನೆ. ಎನ್ಕ್ರಿಪ್ಶನ್, ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ಕಡ್ಡಾಯವಾಗಿದೆ, ಆದರೆ ಮೊದಲ ಮೂಲಮಾದರಿಯಲ್ಲಿ ನೀವು ಅದನ್ನು ಮಾಡದೆಯೇ ಮಾಡಬಹುದು.
ಅಪ್ಲಿಕೇಶನ್ ತರ್ಕ
ನಾವು ಈಗ ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ ಸ್ಥಿತಿಯನ್ನು ನವೀಕರಿಸಲು ಸಮರ್ಥರಾಗಿದ್ದೇವೆ, ಆದರೆ ಲೇಟೆನ್ಸಿ ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸಬಹುದು. ಆಟಗಾರನು, ಇನ್ಪುಟ್ ಅನ್ನು ಪೂರ್ಣಗೊಳಿಸಿದ ನಂತರ, ಅದು ಪ್ರಪಂಚದ ಮೇಲೆ ಯಾವ ಪರಿಣಾಮವನ್ನು ಬೀರಿದೆ ಎಂಬುದನ್ನು ನೋಡಲು ಸರ್ವರ್‌ನಿಂದ ನವೀಕರಿಸಲು ಆಟದ ಸ್ಥಿತಿಗಾಗಿ ಕಾಯಬೇಕಾಗುತ್ತದೆ.
ಇದಲ್ಲದೆ, ಎರಡು ರಾಜ್ಯ ನವೀಕರಣಗಳ ನಡುವೆ, ಪ್ರಪಂಚವು ಸಂಪೂರ್ಣವಾಗಿ ಸ್ಥಿರವಾಗಿದೆ. ರಾಜ್ಯದ ನವೀಕರಣ ದರವು ಕಡಿಮೆಯಾಗಿದ್ದರೆ, ಚಲನೆಗಳು ತುಂಬಾ ಜರ್ಕಿ ಆಗಿರುತ್ತವೆ.
ಈ ಸಮಸ್ಯೆಯ ಪರಿಣಾಮವನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಹಲವಾರು ತಂತ್ರಗಳಿವೆ, ಮತ್ತು ನಾನು ಅವುಗಳನ್ನು ಮುಂದಿನ ವಿಭಾಗದಲ್ಲಿ ಕವರ್ ಮಾಡುತ್ತೇವೆ.
ಲೇಟೆನ್ಸಿ ಸ್ಮೂಥಿಂಗ್ ಟೆಕ್ನಿಕ್ಸ್
ಈ ವಿಭಾಗದಲ್ಲಿ ವಿವರಿಸಿದ ಎಲ್ಲಾ ತಂತ್ರಗಳನ್ನು ಸರಣಿಯಲ್ಲಿ ವಿವರವಾಗಿ ಚರ್ಚಿಸಲಾಗಿದೆ ಗೇಬ್ರಿಯಲ್ ಗ್ಯಾಂಬೆಟ್ಟಾ. ಈ ಅತ್ಯುತ್ತಮ ಲೇಖನಗಳ ಸರಣಿಯನ್ನು ಓದಲು ನಾನು ಹೆಚ್ಚು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ. ಇದು ಸಂವಾದಾತ್ಮಕ ಡೆಮೊವನ್ನು ಸಹ ಒಳಗೊಂಡಿದೆ, ಈ ತಂತ್ರಗಳು ಆಚರಣೆಯಲ್ಲಿ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ನೋಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.
ಸರ್ವರ್‌ನಿಂದ ಪ್ರತಿಕ್ರಿಯೆಗಾಗಿ ಕಾಯದೆ ಇನ್ಪುಟ್ ಫಲಿತಾಂಶವನ್ನು ನೇರವಾಗಿ ಅನ್ವಯಿಸುವುದು ಮೊದಲ ತಂತ್ರವಾಗಿದೆ. ಇದನ್ನು ಕರೆಯಲಾಗುತ್ತದೆ ಕ್ಲೈಂಟ್-ಸೈಡ್ ಮುನ್ಸೂಚನೆ. ಆದಾಗ್ಯೂ, ಕ್ಲೈಂಟ್ ಸರ್ವರ್‌ನಿಂದ ನವೀಕರಣವನ್ನು ಸ್ವೀಕರಿಸಿದಾಗ, ಅದರ ಭವಿಷ್ಯವು ಸರಿಯಾಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಬೇಕು. ಇದು ಹಾಗಲ್ಲದಿದ್ದರೆ, ಅವನು ಸರ್ವರ್‌ನಿಂದ ಸ್ವೀಕರಿಸಿದ ಪ್ರಕಾರ ತನ್ನ ಸ್ಥಿತಿಯನ್ನು ಬದಲಾಯಿಸಬೇಕಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಸರ್ವರ್ ಸರ್ವಾಧಿಕಾರಿ. ಈ ತಂತ್ರವನ್ನು ಮೊದಲು ಕ್ವೇಕ್ನಲ್ಲಿ ಬಳಸಲಾಯಿತು. ಲೇಖನದಲ್ಲಿ ನೀವು ಅದರ ಬಗ್ಗೆ ಇನ್ನಷ್ಟು ಓದಬಹುದು ಫ್ಯಾಬಿಯನ್ ಸಾಂಗ್ಲರ್ಸ್ [ ಹಬ್ರೆ ಮೇಲೆ].
ಎರಡು ರಾಜ್ಯದ ನವೀಕರಣಗಳ ನಡುವೆ ಇತರ ಘಟಕಗಳ ಚಲನೆಯನ್ನು ಸುಗಮಗೊಳಿಸಲು ಎರಡನೇ ಸೆಟ್ ತಂತ್ರಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ. ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ಎರಡು ಮಾರ್ಗಗಳಿವೆ: ಇಂಟರ್ಪೋಲೇಷನ್ ಮತ್ತು ಎಕ್ಸ್ಟ್ರಾಪೋಲೇಷನ್. ಇಂಟರ್ಪೋಲೇಷನ್ ಸಂದರ್ಭದಲ್ಲಿ, ಕೊನೆಯ ಎರಡು ರಾಜ್ಯಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಲಾಗುತ್ತದೆ ಮತ್ತು ಒಂದರಿಂದ ಇನ್ನೊಂದಕ್ಕೆ ಪರಿವರ್ತನೆ ತೋರಿಸಲಾಗುತ್ತದೆ. ಇದರ ಅನನುಕೂಲವೆಂದರೆ ಇದು ಸ್ವಲ್ಪ ಪ್ರಮಾಣದ ವಿಳಂಬವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ ಏಕೆಂದರೆ ಕ್ಲೈಂಟ್ ಯಾವಾಗಲೂ ಹಿಂದೆ ಏನಾಯಿತು ಎಂಬುದನ್ನು ನೋಡುತ್ತಾನೆ. ಎಕ್ಸ್ಟ್ರಾಪೋಲೇಷನ್ ಎನ್ನುವುದು ಕ್ಲೈಂಟ್ ಸ್ವೀಕರಿಸಿದ ಕೊನೆಯ ಸ್ಥಿತಿಯನ್ನು ಆಧರಿಸಿ ಈಗ ಘಟಕಗಳು ಎಲ್ಲಿರಬೇಕು ಎಂಬುದನ್ನು ಊಹಿಸುವುದಾಗಿದೆ. ಇದರ ಅನನುಕೂಲವೆಂದರೆ ಘಟಕವು ಚಲನೆಯ ದಿಕ್ಕನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬದಲಾಯಿಸಿದರೆ, ಮುನ್ಸೂಚನೆ ಮತ್ತು ನಿಜವಾದ ಸ್ಥಾನದ ನಡುವೆ ದೊಡ್ಡ ದೋಷವಿರುತ್ತದೆ.
FPS ನಲ್ಲಿ ಮಾತ್ರ ಉಪಯುಕ್ತವಾದ ಇತ್ತೀಚಿನ, ಅತ್ಯಾಧುನಿಕ ತಂತ್ರವಾಗಿದೆ ವಿಳಂಬ ಪರಿಹಾರ. ವಿಳಂಬ ಪರಿಹಾರವನ್ನು ಬಳಸುವಾಗ, ಸರ್ವರ್ ಗುರಿಯತ್ತ ಗುಂಡು ಹಾರಿಸಿದಾಗ ಕ್ಲೈಂಟ್‌ನ ವಿಳಂಬವನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಆಟಗಾರನು ತನ್ನ ಪರದೆಯ ಮೇಲೆ ಹೆಡ್‌ಶಾಟ್ ಅನ್ನು ಪ್ರದರ್ಶಿಸಿದರೆ, ಆದರೆ ವಾಸ್ತವದಲ್ಲಿ ಅವರ ಗುರಿಯು ವಿಳಂಬದಿಂದಾಗಿ ಬೇರೆ ಸ್ಥಳದಲ್ಲಿದ್ದರೆ, ವಿಳಂಬದ ಕಾರಣದಿಂದ ಕೊಲ್ಲುವ ಹಕ್ಕನ್ನು ಆಟಗಾರನಿಗೆ ನಿರಾಕರಿಸುವುದು ಅನ್ಯಾಯವಾಗುತ್ತದೆ. ಆದ್ದರಿಂದ, ಆಟಗಾರನು ತನ್ನ ಪರದೆಯ ಮೇಲೆ ನೋಡಿದ್ದನ್ನು ಅನುಕರಿಸಲು ಮತ್ತು ಅವರ ಶಾಟ್ ಮತ್ತು ಗುರಿಯ ನಡುವಿನ ಘರ್ಷಣೆಯನ್ನು ಪರೀಕ್ಷಿಸಲು ಆಟಗಾರನು ಗುಂಡು ಹಾರಿಸಿದ ಕ್ಷಣಕ್ಕೆ ಸರ್ವರ್ ಸಮಯವನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ.
ಗ್ಲೆನ್ ಫೀಡ್ಲರ್ (ಯಾವಾಗಲೂ!) 2004 ರಲ್ಲಿ ಒಂದು ಲೇಖನವನ್ನು ಬರೆದರು , ಇದರಲ್ಲಿ ಅವರು ಸರ್ವರ್ ಮತ್ತು ಕ್ಲೈಂಟ್ ನಡುವೆ ಭೌತಶಾಸ್ತ್ರದ ಸಿಮ್ಯುಲೇಶನ್‌ಗಳನ್ನು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಲು ಅಡಿಪಾಯವನ್ನು ಹಾಕಿದರು. 2014 ರಲ್ಲಿ ಅವರು ಹೊಸ ಲೇಖನಗಳ ಸರಣಿಯನ್ನು ಬರೆದರು , ಇದು ಭೌತಶಾಸ್ತ್ರದ ಸಿಮ್ಯುಲೇಶನ್‌ಗಳನ್ನು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಲು ಇತರ ತಂತ್ರಗಳನ್ನು ವಿವರಿಸಿದೆ.
ವಾಲ್ವ್ ವಿಕಿಯಲ್ಲಿ ಎರಡು ಲೇಖನಗಳಿವೆ, и ವಿಳಂಬಕ್ಕೆ ಪರಿಹಾರವನ್ನು ಪರಿಗಣಿಸುತ್ತದೆ.
ಮೋಸವನ್ನು ತಡೆಗಟ್ಟುವುದು
ಮೋಸವನ್ನು ತಡೆಗಟ್ಟಲು ಎರಡು ಮುಖ್ಯ ತಂತ್ರಗಳಿವೆ.
ಮೊದಲನೆಯದು: ದುರುದ್ದೇಶಪೂರಿತ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಕಳುಹಿಸಲು ಮೋಸಗಾರರಿಗೆ ಹೆಚ್ಚು ಕಷ್ಟವಾಗುತ್ತದೆ. ಮೇಲೆ ಹೇಳಿದಂತೆ, ಇದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಉತ್ತಮ ಮಾರ್ಗವೆಂದರೆ ಎನ್ಕ್ರಿಪ್ಶನ್.
ಎರಡನೆಯದು: ನಿರಂಕುಶ ಸರ್ವರ್ ಆಜ್ಞೆಗಳು/ಇನ್ಪುಟ್/ಕ್ರಿಯೆಗಳನ್ನು ಮಾತ್ರ ಸ್ವೀಕರಿಸಬೇಕು. ಕ್ಲೈಂಟ್‌ಗೆ ಇನ್ಪುಟ್ ಕಳುಹಿಸುವುದನ್ನು ಹೊರತುಪಡಿಸಿ ಸರ್ವರ್‌ನಲ್ಲಿ ಸ್ಥಿತಿಯನ್ನು ಬದಲಾಯಿಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. ನಂತರ, ಪ್ರತಿ ಬಾರಿ ಸರ್ವರ್ ಇನ್ಪುಟ್ ಅನ್ನು ಸ್ವೀಕರಿಸಿದಾಗ, ಅದನ್ನು ಬಳಸುವ ಮೊದಲು ಅದು ಮಾನ್ಯವಾಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಬೇಕು.
ಅಪ್ಲಿಕೇಶನ್ ತರ್ಕ: ತೀರ್ಮಾನ
ಹೆಚ್ಚಿನ ಲೇಟೆನ್ಸಿಗಳು ಮತ್ತು ಕಡಿಮೆ ರಿಫ್ರೆಶ್ ದರಗಳನ್ನು ಅನುಕರಿಸುವ ವಿಧಾನವನ್ನು ನೀವು ಕಾರ್ಯಗತಗೊಳಿಸಲು ನಾನು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ ಇದರಿಂದ ಕ್ಲೈಂಟ್ ಮತ್ತು ಸರ್ವರ್ ಒಂದೇ ಕಂಪ್ಯೂಟರ್‌ನಲ್ಲಿ ರನ್ ಆಗುತ್ತಿರುವಾಗಲೂ ನಿಮ್ಮ ಆಟದ ನಡವಳಿಕೆಯನ್ನು ಕಳಪೆ ಸ್ಥಿತಿಯಲ್ಲಿ ಪರೀಕ್ಷಿಸಬಹುದು. ಇದು ವಿಳಂಬ ಸುಗಮಗೊಳಿಸುವ ತಂತ್ರಗಳ ಅನುಷ್ಠಾನವನ್ನು ಹೆಚ್ಚು ಸರಳಗೊಳಿಸುತ್ತದೆ.
ಇತರ ಸಹಾಯಕ ಸಂಪನ್ಮೂಲಗಳು
ನೆಟ್ವರ್ಕ್ ಮಾದರಿಗಳಲ್ಲಿ ನೀವು ಇತರ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಅನ್ವೇಷಿಸಲು ಬಯಸಿದರೆ, ನೀವು ಅವುಗಳನ್ನು ಇಲ್ಲಿ ಕಾಣಬಹುದು:
- - ಅವರ ಸಂಪೂರ್ಣ ಬ್ಲಾಗ್ ಓದಲು ಯೋಗ್ಯವಾಗಿದೆ, ಅಲ್ಲಿ ಸಾಕಷ್ಟು ಉತ್ತಮ ಲೇಖನಗಳಿವೆ. ನೆಟ್ವರ್ಕ್ ತಂತ್ರಜ್ಞಾನಗಳ ಎಲ್ಲಾ ಲೇಖನಗಳನ್ನು ಸಂಗ್ರಹಿಸಲಾಗಿದೆ.
- M. ಫಾತಿಹ್ MAR ಮೂಲಕ ಆನ್‌ಲೈನ್ ವೀಡಿಯೊ ಗೇಮ್ ಎಂಜಿನ್‌ಗಳಲ್ಲಿನ ಲೇಖನಗಳು ಮತ್ತು ವೀಡಿಯೊಗಳ ಸಮಗ್ರ ಪಟ್ಟಿಯಾಗಿದೆ.
- В ಅನೇಕ ಉಪಯುಕ್ತ ಲಿಂಕ್‌ಗಳೂ ಇವೆ.
ಮೂಲ: www.habr.com