TCP ಮತ್ತು UDP ಪ್ರೋಟೋಕಾಲ್‌ಗಳು. ಇತರ ನಿಘಂಟುಗಳಲ್ಲಿ "UDP" ಏನೆಂದು ನೋಡಿ udp ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಪ್ರೋಟೋಕಾಲ್ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ

UDP (ಬಳಕೆದಾರ ಡೇಟಾಗ್ರಾಮ್ ಪ್ರೋಟೋಕಾಲ್) ವಿಶ್ವಾಸಾರ್ಹವಲ್ಲದ ಡೇಟಾ ವಿತರಣೆಯೊಂದಿಗೆ ಸಂಪರ್ಕವಿಲ್ಲದ ಸಾರಿಗೆ ಪ್ರೋಟೋಕಾಲ್ ಆಗಿದೆ. ಆ. ಇದು ಪ್ಯಾಕೆಟ್ ವಿತರಣೆಯ ದೃಢೀಕರಣವನ್ನು ಒದಗಿಸುವುದಿಲ್ಲ, ಒಳಬರುವ ಪ್ಯಾಕೆಟ್‌ಗಳ ಕ್ರಮವನ್ನು ಸಂರಕ್ಷಿಸುವುದಿಲ್ಲ ಮತ್ತು ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳಬಹುದು ಅಥವಾ ನಕಲು ಮಾಡಬಹುದು. ಪೋರ್ಟ್‌ಗಳ ಪರಿಕಲ್ಪನೆಯ ಪರಿಚಯವನ್ನು ಹೊರತುಪಡಿಸಿ UDP IP ಯಂತೆಯೇ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಕಡಿಮೆ ಓವರ್‌ಹೆಡ್‌ನಿಂದ UDP ಸಾಮಾನ್ಯವಾಗಿ TCP ಗಿಂತ ವೇಗವಾಗಿರುತ್ತದೆ. ವಿಶ್ವಾಸಾರ್ಹ ವಿತರಣೆಯ ಅಗತ್ಯವಿಲ್ಲದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಂದ ಇದನ್ನು ಬಳಸಲಾಗುತ್ತದೆ, ಅಥವಾ ಅವುಗಳನ್ನು ಸ್ವತಃ ಕಾರ್ಯಗತಗೊಳಿಸಿ. ಉದಾಹರಣೆಗೆ, ನೇಮ್ ಸರ್ವರ್‌ಗಳು, TFTP (ಟ್ರಿವಿಯಲ್ ಫೈಲ್ ಟ್ರಾನ್ಸ್‌ಫರ್ ಪ್ರೋಟೋಕಾಲ್) ಸೇವೆ, SNMP (ಸರಳ ನೆಟ್‌ವರ್ಕ್ ಮ್ಯಾನೇಜ್‌ಮೆಂಟ್ ಪ್ರೋಟೋಕಾಲ್), ದೃಢೀಕರಣ ವ್ಯವಸ್ಥೆಗಳು. ಕ್ಷೇತ್ರದಲ್ಲಿ UDP ಪ್ರೋಟೋಕಾಲ್ ಗುರುತಿಸುವಿಕೆ ಶಿಷ್ಟಾಚಾರ IP ಹೆಡರ್ - ಸಂಖ್ಯೆ 17.

UDP ಅನ್ನು ತನ್ನ ಸಾರಿಗೆ ಲೇಯರ್ ಸೇವೆಯಾಗಿ ಬಳಸುವ ಯಾವುದೇ ಅಪ್ಲಿಕೇಶನ್ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಕಳುಹಿಸಿದ ಅದೇ ಕ್ರಮದಲ್ಲಿ ವಿತರಿಸಲಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಸ್ವೀಕೃತಿ ಕಾರ್ಯವಿಧಾನಗಳು ಮತ್ತು ಅನುಕ್ರಮ ಸಂಖ್ಯೆಯ ವ್ಯವಸ್ಥೆಯನ್ನು ಒದಗಿಸಬೇಕು.

			ತಲುಪಬೇಕಾದ ಬಂದರು

ಅಕ್ಕಿ. UDP ಪ್ಯಾಕೆಟ್ ಹೆಡರ್ ಫಾರ್ಮ್ಯಾಟ್

udp ಪ್ಯಾಕೆಟ್ ಕ್ಷೇತ್ರಗಳ ಉದ್ದೇಶ:

ಕಳುಹಿಸುವವರ ಪೋರ್ಟ್ ಸಂಖ್ಯೆ -ಮೂಲ ಬಂದರು(16 ಬಿಟ್‌ಗಳು) - ಪ್ಯಾಕೆಟ್ ಕಳುಹಿಸಲಾದ ಪೋರ್ಟ್ ಸಂಖ್ಯೆಯನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ, ಇದು ಪ್ರಸ್ತುತವಾದಾಗ (ಉದಾಹರಣೆಗೆ, ಕಳುಹಿಸುವವರು ಪ್ರತಿಕ್ರಿಯೆಗಾಗಿ ಕಾಯುತ್ತಿದ್ದಾರೆ). ಈ ಕ್ಷೇತ್ರವನ್ನು ಬಳಸದಿದ್ದರೆ, ಅದು ಸೊನ್ನೆಗಳಿಂದ ತುಂಬಿರುತ್ತದೆ.

ಗಮ್ಯಸ್ಥಾನ ಪೋರ್ಟ್ ಸಂಖ್ಯೆ -ತಲುಪುವ ದಾರಿ ಬಂದರು(16 ಬಿಟ್‌ಗಳು) - ಪ್ಯಾಕೆಟ್ ಅನ್ನು ತಲುಪಿಸುವ ಪೋರ್ಟ್ ಸಂಖ್ಯೆಯನ್ನು ಒಳಗೊಂಡಿದೆ.

ಉದ್ದ -ಉದ್ದ(16 ಬಿಟ್‌ಗಳು) - ಹೆಡರ್ ಮತ್ತು ಡೇಟಾ ಸೇರಿದಂತೆ ಬೈಟ್‌ಗಳಲ್ಲಿ ಈ ಡೇಟಾಗ್ರಾಮ್‌ನ ಉದ್ದವನ್ನು ಒಳಗೊಂಡಿದೆ.

ಚೆಕ್ಸಮ್ ಕ್ಷೇತ್ರ -ಚೆಕ್ಸಮ್(16 ಬಿಟ್‌ಗಳು) - 16-ಬಿಟ್ ಪದಗಳ 16-ಬಿಟ್ ಮೊತ್ತದ ಬಿಟ್‌ವೈಸ್ ಪೂರಕವನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತದೆ. ಮೊತ್ತವನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುವಲ್ಲಿ ಒಳಗೊಂಡಿರುವ ಮೊತ್ತವು: 16-ಬಿಟ್ ಗಡಿ ಜೋಡಣೆ ಕ್ಷೇತ್ರಗಳೊಂದಿಗೆ ಪ್ಯಾಕೆಟ್ ಡೇಟಾ (ಶೂನ್ಯ), UDP ಪ್ಯಾಕೆಟ್ ಹೆಡರ್, ಹುಸಿ-ಹೆಡರ್ (IP ಪ್ರೋಟೋಕಾಲ್ನಿಂದ ಮಾಹಿತಿ).

tcp ಪ್ರೋಟೋಕಾಲ್

TCP (ಟ್ರಾನ್ಸ್ಮಿಷನ್ ಕಂಟ್ರೋಲ್ ಪ್ರೋಟೋಕಾಲ್) ವಿಶ್ವಾಸಾರ್ಹ ಡೇಟಾ ವಿತರಣೆಯೊಂದಿಗೆ ಸಂಪರ್ಕ-ಆಧಾರಿತ ಸಾರಿಗೆ ಪ್ರೋಟೋಕಾಲ್ ಆಗಿದೆ. ಆದ್ದರಿಂದ, ಇದು ರವಾನೆಯಾದ ಡೇಟಾದ ಸಮಗ್ರತೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ ಕಠಿಣ ದೋಷ ಪತ್ತೆ ಕ್ರಮಾವಳಿಗಳನ್ನು ಹೊಂದಿದೆ.

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

TCP ಬೈಟ್ ಸರಣಿ ಪ್ರೋಟೋಕಾಲ್ ಆಗಿದೆ. ಪ್ಯಾಕೆಟ್ ಸೀರಿಯಲ್ ಪ್ರೋಟೋಕಾಲ್‌ಗಳಿಗಿಂತ ಭಿನ್ನವಾಗಿ, ಇದು ಪ್ರತಿ ಪ್ಯಾಕೆಟ್‌ಗೆ ಪ್ರತ್ಯೇಕವಾಗಿ ಬದಲಾಗಿ ಪ್ಯಾಕೆಟ್‌ನ ಪ್ರತಿ ಬೈಟ್‌ಗೆ ಸರಣಿ ಸಂಖ್ಯೆಯನ್ನು ನಿಯೋಜಿಸುತ್ತದೆ.

										ತಲುಪಬೇಕಾದ ಬಂದರು
	ಸ್ವೀಕೃತಿ ಸಂಖ್ಯೆ

ಅಕ್ಕಿ. TCP ಪ್ಯಾಕೆಟ್ ಹೆಡರ್ ಫಾರ್ಮ್ಯಾಟ್

ಒಳ್ಳೆಯ ದಿನ, ಪ್ರಿಯ ಓದುಗರು.
ಜನಪ್ರಿಯ ಬೇಡಿಕೆಯಿಂದ, ಇಂದು ನಾನು ನಿಮಗಾಗಿ ಲೇಖನವನ್ನು ಪ್ರಕಟಿಸುತ್ತಿದ್ದೇನೆ ಅದು ಕಂಪ್ಯೂಟರ್ ನೆಟ್‌ವರ್ಕ್ ನಿಯಮಗಳ ಮೂಲಭೂತ ಅಂಶಗಳನ್ನು ನಿಮಗೆ ಪರಿಚಯಿಸುತ್ತದೆ, ಅವುಗಳೆಂದರೆ:

• ನೆಟ್‌ವರ್ಕ್ ಪ್ರೋಟೋಕಾಲ್‌ಗಳು - ಈ ಭಯಾನಕ ಹೆಸರುಗಳು ಯಾವುವು ಮತ್ತು ಅವುಗಳನ್ನು ಯಾವುದಕ್ಕಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ?
• UDP, TCP, ICMP - ಏನು, ಏಕೆ ಮತ್ತು ಏನು ವ್ಯತ್ಯಾಸ
• ಪ್ರತಿಯೊಬ್ಬರೂ ಐಪಿ ವಿಳಾಸವನ್ನು ಹೊಂದಿದ್ದಾರೆ, ಆದರೆ ಇದು ಏಕೆ ಎಂದು ಎಲ್ಲರಿಗೂ ತಿಳಿದಿಲ್ಲ :-)
• ವಿಳಾಸ ಮಾಸ್ಕ್ (ಸಬ್‌ನೆಟ್)
• ಗೇಟ್ವೇ
• ರೂಟಿಂಗ್ ಕೋಷ್ಟಕಗಳ ಬಗ್ಗೆ ಕೆಲವು ಪದಗಳು
• ಬಂದರುಗಳು - ಅವು ನಿಜವಾಗಿಯೂ ಯಾವುವು?
• ಮ್ಯಾಕ್ ವಿಳಾಸ

ಹಾಗೆ.

ಲೇಖನವು ಯುವಕರು ಮತ್ತು ವಯಸ್ಸಾದ ಎಲ್ಲರಿಗೂ ಉಪಯುಕ್ತವಾಗಿದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ, ಏಕೆಂದರೆ ಇದು ವಿಚಿತ್ರವಾದ, ಗ್ರಹಿಸಲಾಗದ ಕ್ರಿಯೆಗಳು ಅಥವಾ ಪದಗಳ ಗುಂಪನ್ನು ಹೊಂದಿಲ್ಲ, ಆದರೆ ಪ್ರವೇಶಿಸಬಹುದಾದ ಭಾಷೆಯಲ್ಲಿ ಪ್ರಸ್ತುತಪಡಿಸಲಾದ ಮಾಹಿತಿಯ ಒಂದು ಬ್ಲಾಕ್, ಇದು ಕನಿಷ್ಠ ನೀಡುತ್ತದೆ ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಅದು ಏಕೆ ಬೇಕು ಎಂಬುದನ್ನು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತೀರಿ. ಹೋಗು.

ನೆಟ್‌ವರ್ಕ್ ಪ್ರೋಟೋಕಾಲ್‌ಗಳು TCP/IP, NWLink IPX/SPX, NetBEUI

ನೆಟ್‌ವರ್ಕ್ ಪ್ರೋಟೋಕಾಲ್ ಎಂದರೇನು ಮತ್ತು ಅದನ್ನು ಯಾವುದಕ್ಕಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ ಎಂಬುದರೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸೋಣ.
ನೆಟ್ವರ್ಕ್ ಪ್ರೋಟೋಕಾಲ್ಕಂಪ್ಯೂಟರ್‌ಗಳ ನಡುವಿನ ಸಂವಹನಕ್ಕಾಗಿ ಸಾಫ್ಟ್‌ವೇರ್ ಅಳವಡಿಸಲಾದ ನಿಯಮಗಳ ಒಂದು ಸೆಟ್ ಆಗಿದೆ. ಕಂಪ್ಯೂಟರ್‌ಗಳು ಪರಸ್ಪರ ಮಾತನಾಡುವ ಮತ್ತು ಮಾಹಿತಿಯನ್ನು ರವಾನಿಸುವ ಒಂದು ರೀತಿಯ ಭಾಷೆ. ಹಿಂದೆ, ಕಂಪ್ಯೂಟರ್‌ಗಳು ಮಾತನಾಡಲು, ಬಹುಭಾಷಾ ಮತ್ತು ವಿಂಡೋಸ್‌ನ ಹಳೆಯ ಆವೃತ್ತಿಗಳು ಸಂಪೂರ್ಣ ಪ್ರೋಟೋಕಾಲ್‌ಗಳನ್ನು ಬಳಸುತ್ತಿದ್ದವು - TCP/IP, NWLink IPX/SPX, NetBEUI. ಈಗ ನಾವು ಸಾಮಾನ್ಯ ಒಪ್ಪಂದಕ್ಕೆ ಬಂದಿದ್ದೇವೆ ಮತ್ತು ಮಾನದಂಡವು TCP/IP ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಬಳಸುತ್ತದೆ ಮತ್ತು ಆದ್ದರಿಂದ ಇದನ್ನು ಮತ್ತಷ್ಟು ಚರ್ಚಿಸಲಾಗುವುದು.

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

ನೆಟ್‌ವರ್ಕ್ ಪ್ರೋಟೋಕಾಲ್‌ಗಳು UDP, TCP, ICMP

TCP/IP ಪ್ರೋಟೋಕಾಲ್‌ನಲ್ಲಿ, ಡೇಟಾ ಪ್ರಸರಣಕ್ಕಾಗಿ ಬಳಸುವ ಪ್ರೋಟೋಕಾಲ್‌ಗಳು TCP ಮತ್ತು UDP. TCP ಮತ್ತು UDP ಪೋರ್ಟ್‌ಗಳೆರಡೂ ಇವೆ ಎಂದು ಅನೇಕ ಜನರು ಬಹುಶಃ ಕೇಳಿರಬಹುದು, ಆದರೆ ವ್ಯತ್ಯಾಸವೇನು ಮತ್ತು ಅದು ಏನು ಎಂದು ಎಲ್ಲರಿಗೂ ತಿಳಿದಿಲ್ಲ. ಆದ್ದರಿಂದ..

TCP ಪ್ರೋಟೋಕಾಲ್ (ಟ್ರಾನ್ಸ್ಮಿಷನ್ ಕಂಟ್ರೋಲ್ ಪ್ರೋಟೋಕಾಲ್) ಮೂಲಕ ಡೇಟಾ ಪ್ರಸರಣಕ್ಕೆ ಮಾಹಿತಿಯ ಸ್ವೀಕೃತಿಯ ದೃಢೀಕರಣದ ಅಗತ್ಯವಿದೆ. "ಸರಿ, ಅವರು ಹೇಳುತ್ತಾರೆ, ನೀವು ಅದನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೀರಾ - ಅರ್ಥವಾಯಿತು!" ಸ್ಥಾಪಿತ ಸಮಯದ ಚೌಕಟ್ಟಿನೊಳಗೆ ರವಾನಿಸುವ ಪಕ್ಷವು ಅಗತ್ಯ ದೃಢೀಕರಣವನ್ನು ಸ್ವೀಕರಿಸದಿದ್ದರೆ, ಡೇಟಾವನ್ನು ಮತ್ತೆ ರವಾನಿಸಲಾಗುತ್ತದೆ. ಆದ್ದರಿಂದ, TCP ಅನ್ನು ಸಂಪರ್ಕ ಆಧಾರಿತ ಪ್ರೋಟೋಕಾಲ್ ಎಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ, ಆದರೆ UDP (ಬಳಕೆದಾರ ಡೇಟಾಗ್ರಾಮ್ ಪ್ರೋಟೋಕಾಲ್) ಅಲ್ಲ. ಸ್ವಾಗತ ದೃಢೀಕರಣ ಅಗತ್ಯವಿಲ್ಲದ ಸಂದರ್ಭಗಳಲ್ಲಿ UDP ಅನ್ನು ಬಳಸಲಾಗುತ್ತದೆ (ಉದಾಹರಣೆಗೆ, DNS ಪ್ರಶ್ನೆಗಳು ಅಥವಾ IP ಟೆಲಿಫೋನಿ (ಇದರಲ್ಲಿ ಸ್ಕೈಪ್ ಪ್ರಮುಖ ಪ್ರತಿನಿಧಿಯಾಗಿದೆ)). ಅಂದರೆ, ವ್ಯತ್ಯಾಸವು ಸ್ವಾಗತದ ದೃಢೀಕರಣದ ಉಪಸ್ಥಿತಿಯಲ್ಲಿದೆ. ಇದು "ಅಷ್ಟೆ!" ಎಂದು ತೋರುತ್ತದೆ, ಆದರೆ ಆಚರಣೆಯಲ್ಲಿ ಇದು ಪ್ರಮುಖ ಪಾತ್ರ ವಹಿಸುತ್ತದೆ.

ICMP ಪ್ರೋಟೋಕಾಲ್ (ಇಂಟರ್ನೆಟ್ ಕಂಟ್ರೋಲ್ ಮೆಸೇಜ್ ಪ್ರೋಟೋಕಾಲ್) ಸಹ ಇದೆ, ಇದನ್ನು ನೆಟ್ವರ್ಕ್ ಪ್ಯಾರಾಮೀಟರ್ಗಳ ಬಗ್ಗೆ ಡೇಟಾವನ್ನು ರವಾನಿಸಲು ಬಳಸಲಾಗುತ್ತದೆ. ಇದು ಯುಟಿಲಿಟಿ ಪ್ಯಾಕೇಜ್ ಪ್ರಕಾರಗಳನ್ನು ಒಳಗೊಂಡಿದೆ ಪಿಂಗ್, ತಲುಪಲಾಗದ ದೂರ, TTLಇತ್ಯಾದಿ

IP ವಿಳಾಸ ಎಂದರೇನು

ಪ್ರತಿಯೊಬ್ಬರೂ ಒಂದನ್ನು ಹೊಂದಿದ್ದಾರೆ, ಆದರೆ ಇದು ಯಾವ ರೀತಿಯ ವಿಳಾಸವಾಗಿದೆ ಮತ್ತು ಅದು ಇಲ್ಲದೆ ಬದುಕಲು ಏಕೆ ಅಸಾಧ್ಯವೆಂದು ಎಲ್ಲರಿಗೂ ತಿಳಿದಿಲ್ಲ. ನಾನು ನಿಮಗೆ ಹೇಳುತ್ತಿದ್ದೇನೆ.

IP ವಿಳಾಸವು ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಕಂಪ್ಯೂಟರ್ ಅನ್ನು ಗುರುತಿಸಲು ಬಳಸುವ 32-ಬಿಟ್ ಸಂಖ್ಯೆಯಾಗಿದೆ. ಈ ಸಂಖ್ಯೆಯ ಪ್ರತಿ ಆಕ್ಟೆಟ್‌ನ ದಶಮಾಂಶ ಮೌಲ್ಯಗಳಲ್ಲಿ ವಿಳಾಸವನ್ನು ಬರೆಯುವುದು ವಾಡಿಕೆಯಾಗಿದೆ, ಫಲಿತಾಂಶದ ಮೌಲ್ಯಗಳನ್ನು ಚುಕ್ಕೆಗಳೊಂದಿಗೆ ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, 192.168.101.36

IP ವಿಳಾಸಗಳು ಅನನ್ಯವಾಗಿವೆ, ಅಂದರೆ ಪ್ರತಿ ಕಂಪ್ಯೂಟರ್ ತನ್ನದೇ ಆದ ಸಂಖ್ಯೆಗಳ ಸಂಯೋಜನೆಯನ್ನು ಹೊಂದಿದೆ ಮತ್ತು ಒಂದೇ ವಿಳಾಸದೊಂದಿಗೆ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಎರಡು ಕಂಪ್ಯೂಟರ್‌ಗಳು ಇರುವಂತಿಲ್ಲ. IP ವಿಳಾಸಗಳನ್ನು ಕೇಂದ್ರವಾಗಿ ವಿತರಿಸಲಾಗುತ್ತದೆ, ಇಂಟರ್ನೆಟ್ ಪೂರೈಕೆದಾರರು ತಮ್ಮ ಅಗತ್ಯಗಳಿಗೆ ಅನುಗುಣವಾಗಿ ರಾಷ್ಟ್ರೀಯ ಕೇಂದ್ರಗಳಿಗೆ ಅರ್ಜಿಗಳನ್ನು ಮಾಡುತ್ತಾರೆ. ಪೂರೈಕೆದಾರರು ಸ್ವೀಕರಿಸಿದ ವಿಳಾಸ ಶ್ರೇಣಿಗಳನ್ನು ಗ್ರಾಹಕರ ನಡುವೆ ಮತ್ತಷ್ಟು ವಿತರಿಸಲಾಗುತ್ತದೆ. ಗ್ರಾಹಕರು, ಪ್ರತಿಯಾಗಿ, ಸ್ವತಃ ಪೂರೈಕೆದಾರರಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಬಹುದು ಮತ್ತು ಸ್ವೀಕರಿಸಿದ IP ವಿಳಾಸಗಳನ್ನು ಉಪಕ್ಲೈಂಟ್‌ಗಳ ನಡುವೆ ವಿತರಿಸಬಹುದು, ಇತ್ಯಾದಿ. IP ವಿಳಾಸಗಳನ್ನು ವಿತರಿಸುವ ಈ ವಿಧಾನದೊಂದಿಗೆ, ಕಂಪ್ಯೂಟರ್ ಸಿಸ್ಟಮ್ ವಿಶಿಷ್ಟವಾದ IP ವಿಳಾಸವನ್ನು ಹೊಂದಿರುವ ಕಂಪ್ಯೂಟರ್ನ "ಸ್ಥಳ" ವನ್ನು ನಿಖರವಾಗಿ ತಿಳಿದಿದೆ; - ಅವಳು "ಮಾಲೀಕ" ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಡೇಟಾವನ್ನು ಕಳುಹಿಸಲು ಸಾಕು, ಮತ್ತು ಪೂರೈಕೆದಾರರು ಗಮ್ಯಸ್ಥಾನವನ್ನು ವಿಶ್ಲೇಷಿಸುತ್ತಾರೆ ಮತ್ತು ವಿಳಾಸಗಳ ಈ ಭಾಗವನ್ನು ಯಾರಿಗೆ ನೀಡಲಾಗಿದೆ ಎಂದು ತಿಳಿದುಕೊಂಡು ಮುಂದಿನ ಮಾಲೀಕರಿಗೆ ಮಾಹಿತಿಯನ್ನು ಕಳುಹಿಸುತ್ತಾರೆ. ಗಮ್ಯಸ್ಥಾನದ ಕಂಪ್ಯೂಟರ್‌ಗೆ ಡೇಟಾ ಬರುವವರೆಗೆ IP ವಿಳಾಸ ಉಪವಿಭಾಗ.

ಸ್ಥಳೀಯ ನೆಟ್ವರ್ಕ್ಗಳ ನಿರ್ಮಾಣಕ್ಕಾಗಿ, ವಿಶೇಷ ವಿಳಾಸ ಶ್ರೇಣಿಗಳನ್ನು ಹಂಚಲಾಗುತ್ತದೆ. ಇವು ವಿಳಾಸಗಳು 10.x.x.x, 192.168.x.x, 10.x.x.x, 172.16.x.x ನಿಂದ 172.31.x.x, 169.254.x.x, ಇಲ್ಲಿ x ಎಂದರೆ 0 ರಿಂದ 254 ರವರೆಗಿನ ಯಾವುದೇ ಸಂಖ್ಯೆ. ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ವಿಳಾಸಗಳಿಂದ ರವಾನೆಯಾಗುವ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ರೂಟ್ ಮಾಡಲಾಗುವುದಿಲ್ಲ, ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ಅವುಗಳನ್ನು ಸರಳವಾಗಿ ಇಂಟರ್ನೆಟ್‌ನಲ್ಲಿ ಕಳುಹಿಸಲಾಗುವುದಿಲ್ಲ ಮತ್ತು ಆದ್ದರಿಂದ ವಿವಿಧ ಸ್ಥಳೀಯ ನೆಟ್‌ವರ್ಕ್‌ಗಳಲ್ಲಿನ ಕಂಪ್ಯೂಟರ್‌ಗಳು ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಶ್ರೇಣಿಗಳಿಂದ ಹೊಂದಿಕೆಯಾಗುವ ವಿಳಾಸಗಳನ್ನು ಹೊಂದಿರಬಹುದು. ಅಂದರೆ, ಕಂಪನಿ LLC "ಹಾರ್ನ್ಸ್ ಮತ್ತು ಹೂವ್ಸ್" ಮತ್ತು LLC "Vasya ಮತ್ತು ಕಂಪನಿ" 192.168.0.244 ವಿಳಾಸಗಳೊಂದಿಗೆ ಎರಡು ಕಂಪ್ಯೂಟರ್ಗಳನ್ನು ಹೊಂದಬಹುದು, ಆದರೆ ಇಂಟರ್ನೆಟ್ ಪೂರೈಕೆದಾರರಿಂದ ಸ್ವೀಕರಿಸಿದ 85.144.213.122 ವಿಳಾಸಗಳೊಂದಿಗೆ ಹೇಳಲಾಗುವುದಿಲ್ಲ, ಏಕೆಂದರೆ . ಇಂಟರ್ನೆಟ್‌ನಲ್ಲಿ ಒಂದೇ ರೀತಿಯ ಎರಡು ಐಪಿ ವಿಳಾಸಗಳು ಇರುವಂತಿಲ್ಲ. ಅಂತಹ ಕಂಪ್ಯೂಟರ್‌ಗಳಿಂದ ಇಂಟರ್ನೆಟ್‌ಗೆ ಮತ್ತು ಹಿಂದಕ್ಕೆ ಮಾಹಿತಿಯನ್ನು ಕಳುಹಿಸಲು, ಇಂಟರ್ನೆಟ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ ಸ್ಥಳೀಯ ವಿಳಾಸಗಳನ್ನು ನೈಜವಾದವುಗಳೊಂದಿಗೆ ಬದಲಾಯಿಸುವ ವಿಶೇಷ ಕಾರ್ಯಕ್ರಮಗಳು ಮತ್ತು ಸಾಧನಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ. ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ಡೇಟಾವನ್ನು ನೈಜ IP ವಿಳಾಸದಿಂದ ನೆಟ್ವರ್ಕ್ಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಸ್ಥಳೀಯ ಒಂದರಿಂದ ಅಲ್ಲ. ಈ ಪ್ರಕ್ರಿಯೆಯು ಬಳಕೆದಾರರಿಂದ ಗಮನಿಸದೆ ಸಂಭವಿಸುತ್ತದೆ ಮತ್ತು ಇದನ್ನು ವಿಳಾಸ ಅನುವಾದ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ಒಂದೇ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ, ಹಾರ್ನ್ಸ್ ಮತ್ತು ಹೂವ್ಸ್ ಎಲ್‌ಎಲ್‌ಸಿ ಎಂಬ ಕಂಪನಿ, ಒಂದು ಸ್ಥಳೀಯ ಐಪಿ ವಿಳಾಸದೊಂದಿಗೆ ಎರಡು ಕಂಪ್ಯೂಟರ್‌ಗಳು ಇರುವಂತಿಲ್ಲ ಎಂದು ನಾನು ನಮೂದಿಸಲು ಬಯಸುತ್ತೇನೆ, ಅಂದರೆ, ಮೇಲಿನ ಉದಾಹರಣೆಯಲ್ಲಿ 192.168.0.244 ವಿಳಾಸದೊಂದಿಗೆ ಒಂದು ಕಂಪ್ಯೂಟರ್ ಎಂದು ಅರ್ಥೈಸಲಾಗಿದೆ. ಒಂದು ಕಂಪನಿಯಲ್ಲಿ, ಎರಡನೆಯದು ಅದೇ ವಿಳಾಸದೊಂದಿಗೆ ಇನ್ನೊಂದರಲ್ಲಿ. ಅದೇ ಕಂಪನಿಯಲ್ಲಿ, 192.168.0.244 ವಿಳಾಸದೊಂದಿಗೆ ಎರಡು ಕಂಪ್ಯೂಟರ್ಗಳು ಸರಳವಾಗಿ ಸಿಗುವುದಿಲ್ಲ.

ಬಾಹ್ಯ IP ಮತ್ತು ಆಂತರಿಕ IP, ಶಾಶ್ವತ (ಸ್ಥಿರ IP) ಮತ್ತು ವೇರಿಯಬಲ್ (ಡೈನಾಮಿಕ್) IP ನಂತಹ ಪದಗಳನ್ನು ನೀವು ಬಹುಶಃ ಕೇಳಿರಬಹುದು. ಅವರ ಬಗ್ಗೆ ಸಂಕ್ಷಿಪ್ತವಾಗಿ:

• ಬಾಹ್ಯ IP ನಿಮ್ಮ ಪೂರೈಕೆದಾರರು ನಿಮಗೆ ನೀಡುವ ಅದೇ IP ಆಗಿದೆ, ಅಂದರೆ. ಇಂಟರ್ನೆಟ್‌ನಲ್ಲಿ ನಿಮ್ಮ ಅನನ್ಯ ವಿಳಾಸ, ಉದಾಹರಣೆಗೆ, 85.144.24.122
• ಆಂತರಿಕ ಐಪಿ ಸ್ಥಳೀಯ ಐಪಿ, ಅಂದರೆ. ಸ್ಥಳೀಯ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ನಿಮ್ಮ IP, ಉದಾಹರಣೆಗೆ, 192.168.1.3
• ಸ್ಥಿರ IP ಒಂದು IP ಆಗಿದ್ದು ಅದು ಪ್ರತಿ ಸಂಪರ್ಕದೊಂದಿಗೆ ಬದಲಾಗುವುದಿಲ್ಲ, ಅಂದರೆ. ದೃಢವಾಗಿ ಮತ್ತು ಶಾಶ್ವತವಾಗಿ ನಿಮಗೆ ನಿಯೋಜಿಸಲಾಗಿದೆ
• ಡೈನಾಮಿಕ್ ಐಪಿ ಎಂಬುದು ತೇಲುವ ಐಪಿ ವಿಳಾಸವಾಗಿದ್ದು ಅದು ಪ್ರತಿ ಸಂಪರ್ಕದೊಂದಿಗೆ ಬದಲಾಗುತ್ತದೆ

ನಿಮ್ಮ ಐಪಿ ಪ್ರಕಾರ (ಸ್ಥಿರ ಅಥವಾ ಡೈನಾಮಿಕ್) ನಿಮ್ಮ ಪೂರೈಕೆದಾರರ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ.

ವಿಳಾಸ ಮಾಸ್ಕ್ ಎಂದರೇನು (ಸಬ್‌ನೆಟ್)

ಸಬ್‌ನೆಟ್‌ನ ಪರಿಕಲ್ಪನೆಯನ್ನು ಪರಿಚಯಿಸಲಾಯಿತು ಇದರಿಂದ ಒಂದು ಸಂಸ್ಥೆಯ IP ವಿಳಾಸಗಳ ಭಾಗವನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ಸಾಧ್ಯವಾಯಿತು, ಇನ್ನೊಂದು ಭಾಗ, ಇತ್ಯಾದಿ. ಸಬ್‌ನೆಟ್ ಎನ್ನುವುದು ಒಂದೇ ಸ್ಥಳೀಯ ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಸೇರಿದ IP ವಿಳಾಸಗಳ ಶ್ರೇಣಿಯಾಗಿದೆ. ಸ್ಥಳೀಯ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುವಾಗ, ಮಾಹಿತಿಯನ್ನು ನೇರವಾಗಿ ಸ್ವೀಕರಿಸುವವರಿಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ. ಸ್ಥಳೀಯ ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಸೇರದ ಐಪಿ ವಿಳಾಸವನ್ನು ಹೊಂದಿರುವ ಕಂಪ್ಯೂಟರ್‌ಗಳಿಗೆ ಡೇಟಾವನ್ನು ಉದ್ದೇಶಿಸಿದ್ದರೆ, ಒಂದು ನೆಟ್‌ವರ್ಕ್‌ನಿಂದ ಇನ್ನೊಂದಕ್ಕೆ ಫಾರ್ವರ್ಡ್ ಮಾಡುವ ಮಾರ್ಗವನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು ವಿಶೇಷ ನಿಯಮಗಳನ್ನು ಅದಕ್ಕೆ ಅನ್ವಯಿಸಲಾಗುತ್ತದೆ.

ಮಾಸ್ಕ್ ಎನ್ನುವುದು ಒಂದು ನಿರ್ದಿಷ್ಟ ಗುಂಪಿನಲ್ಲಿ (ಸಬ್‌ನೆಟ್) ಎಷ್ಟು ಕಂಪ್ಯೂಟರ್‌ಗಳನ್ನು ಸೇರಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ಸಾಫ್ಟ್‌ವೇರ್‌ಗೆ ಹೇಳುವ ನಿಯತಾಂಕವಾಗಿದೆ. ವಿಳಾಸ ಮುಖವಾಡವು IP ವಿಳಾಸದಂತೆಯೇ ಅದೇ ರಚನೆಯನ್ನು ಹೊಂದಿದೆ: ಇದು ನಾಲ್ಕು ಗುಂಪುಗಳ ಸಂಖ್ಯೆಗಳ ಗುಂಪಾಗಿದೆ, ಪ್ರತಿಯೊಂದೂ 0 ರಿಂದ 255 ರ ವ್ಯಾಪ್ತಿಯಲ್ಲಿರಬಹುದು. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಮಾಸ್ಕ್ ಮೌಲ್ಯವು ಕಡಿಮೆ, ಹೆಚ್ಚಿನ ಕಂಪ್ಯೂಟರ್ಗಳು ಈ ಸಬ್ನೆಟ್ಗೆ ಸಂಪರ್ಕಗೊಂಡಿವೆ. ಸಣ್ಣ ಕಂಪನಿ ನೆಟ್‌ವರ್ಕ್‌ಗಳಿಗೆ, ಮಾಸ್ಕ್ ಸಾಮಾನ್ಯವಾಗಿ 255.255.255.x (ಉದಾಹರಣೆಗೆ, 255.255.255.224). ನೆಟ್ವರ್ಕ್ ಮಾಸ್ಕ್ ಅನ್ನು IP ವಿಳಾಸದೊಂದಿಗೆ ಕಂಪ್ಯೂಟರ್ಗೆ ನಿಯೋಜಿಸಲಾಗಿದೆ. ಆದ್ದರಿಂದ, ಉದಾಹರಣೆಗೆ, 255.255.255.0 ರ ಮಾಸ್ಕ್ ಹೊಂದಿರುವ ನೆಟ್‌ವರ್ಕ್ 192.168.0.0 192.168.0.1 ರಿಂದ 192.168.254 192.168.0.0 ವರೆಗಿನ ವಿಳಾಸಗಳೊಂದಿಗೆ ಕಂಪ್ಯೂಟರ್‌ಗಳನ್ನು ಹೊಂದಿರಬಹುದು 168.0 .127. ಅರ್ಥ ಸ್ಪಷ್ಟವಾಗಿದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ನಿಯಮದಂತೆ, IP ವಿಳಾಸಗಳನ್ನು ಉಳಿಸಲು ಪೂರೈಕೆದಾರರು ಕಡಿಮೆ ಸಂಖ್ಯೆಯ ಕಂಪ್ಯೂಟರ್‌ಗಳನ್ನು ಹೊಂದಿರುವ ನೆಟ್‌ವರ್ಕ್‌ಗಳನ್ನು ಬಳಸುತ್ತಾರೆ. ಉದಾಹರಣೆಗೆ, ಕ್ಲೈಂಟ್‌ಗೆ 255.255.255.252 ರ ಮುಖವಾಡದೊಂದಿಗೆ ವಿಳಾಸವನ್ನು ನಿಯೋಜಿಸಬಹುದು. ಈ ಸಬ್‌ನೆಟ್ ಕೇವಲ ಎರಡು ಕಂಪ್ಯೂಟರ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿದೆ.

ಕಂಪ್ಯೂಟರ್ ಐಪಿ ವಿಳಾಸವನ್ನು ಸ್ವೀಕರಿಸಿದ ನಂತರ ಮತ್ತು ಸಬ್‌ನೆಟ್ ಮಾಸ್ಕ್‌ನ ಮೌಲ್ಯವನ್ನು ತಿಳಿದ ನಂತರ, ಪ್ರೋಗ್ರಾಂ ಈ ಸ್ಥಳೀಯ ಸಬ್‌ನೆಟ್‌ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಪ್ರಾರಂಭಿಸಬಹುದು. ಆದಾಗ್ಯೂ, ಜಾಗತಿಕ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಇತರ ಕಂಪ್ಯೂಟರ್ಗಳೊಂದಿಗೆ ಮಾಹಿತಿಯನ್ನು ವಿನಿಮಯ ಮಾಡಲು, ಬಾಹ್ಯ ನೆಟ್ವರ್ಕ್ಗಾಗಿ ಮಾಹಿತಿಯನ್ನು ಎಲ್ಲಿ ಕಳುಹಿಸಬೇಕು ಎಂಬ ನಿಯಮಗಳನ್ನು ನೀವು ತಿಳಿದುಕೊಳ್ಳಬೇಕು. ಈ ಉದ್ದೇಶಕ್ಕಾಗಿ, ಗೇಟ್‌ವೇ ವಿಳಾಸದಂತಹ ವಿಶಿಷ್ಟತೆಯನ್ನು ಬಳಸಲಾಗುತ್ತದೆ.

ಗೇಟ್‌ವೇ ಎಂದರೇನು?

ಗೇಟ್‌ವೇ ಎನ್ನುವುದು ವಿಭಿನ್ನ IP ಸಬ್‌ನೆಟ್‌ಗಳ ನಡುವೆ ಮಾಹಿತಿಯನ್ನು ರವಾನಿಸುವ ಸಾಧನ (ಕಂಪ್ಯೂಟರ್ ಅಥವಾ ರೂಟರ್). ಗಮ್ಯಸ್ಥಾನದ ವಿಳಾಸವು ಸ್ಥಳೀಯ ಸಬ್‌ನೆಟ್‌ನ ಭಾಗವಾಗಿಲ್ಲ ಎಂದು ಪ್ರೋಗ್ರಾಂ (IP ಮತ್ತು ಮುಖವಾಡದಿಂದ) ನಿರ್ಧರಿಸಿದರೆ, ಅದು ಈ ಡೇಟಾವನ್ನು ಗೇಟ್‌ವೇ ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಸಾಧನಕ್ಕೆ ಕಳುಹಿಸುತ್ತದೆ. ಪ್ರೋಟೋಕಾಲ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳಲ್ಲಿ, ಅಂತಹ ಸಾಧನದ IP ವಿಳಾಸವನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಿ.

ಸ್ಥಳೀಯ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಮಾತ್ರ ಕೆಲಸ ಮಾಡಲು, ಗೇಟ್ವೇ ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸದಿರಬಹುದು.

ಇಂಟರ್ನೆಟ್‌ಗೆ ಸಂಪರ್ಕಿಸುವ ವೈಯಕ್ತಿಕ ಬಳಕೆದಾರರಿಗೆ ಅಥವಾ ಒಂದೇ ಸಂಪರ್ಕ ಚಾನಲ್ ಹೊಂದಿರುವ ಸಣ್ಣ ವ್ಯವಹಾರಗಳಿಗೆ, ಸಿಸ್ಟಮ್ ಕೇವಲ ಒಂದು ಗೇಟ್‌ವೇ ವಿಳಾಸವನ್ನು ಹೊಂದಿರಬೇಕು - ಇದು ಇಂಟರ್ನೆಟ್ ಸಂಪರ್ಕವನ್ನು ಹೊಂದಿರುವ ಸಾಧನದ ವಿಳಾಸವಾಗಿದೆ. ಬಹು ಮಾರ್ಗಗಳಿದ್ದರೆ, ಬಹು ಗೇಟ್‌ವೇ ಇರುತ್ತದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಡೇಟಾ ಮಾರ್ಗವನ್ನು ನಿರ್ಧರಿಸಲು ರೂಟಿಂಗ್ ಟೇಬಲ್ ಅನ್ನು ಬಳಸಲಾಗುತ್ತದೆ.

ರೂಟಿಂಗ್ ಕೋಷ್ಟಕಗಳು ಯಾವುವು

ಮತ್ತು ಆದ್ದರಿಂದ ನಾವು ಸರಾಗವಾಗಿ ಅವರನ್ನು ತಲುಪಿದೆವು. ಅಂದಹಾಗೆ.. ಇವು ಯಾವ ರೀತಿಯ ಕೋಷ್ಟಕಗಳು?

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

ನೆಟ್ವರ್ಕ್ ಪೋರ್ಟ್ಗಳು ಯಾವುವು

ಡೇಟಾವನ್ನು ರವಾನಿಸುವಾಗ, ಕಳುಹಿಸುವವರ ಮತ್ತು ಸ್ವೀಕರಿಸುವವರ IP ವಿಳಾಸಗಳ ಜೊತೆಗೆ, ಮಾಹಿತಿ ಪ್ಯಾಕೆಟ್ ಪೋರ್ಟ್ ಸಂಖ್ಯೆಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಉದಾಹರಣೆ: 192.168.1.1:80, - ಈ ಸಂದರ್ಭದಲ್ಲಿ 80 ಪೋರ್ಟ್ ಸಂಖ್ಯೆ. ಪೋರ್ಟ್ ಎನ್ನುವುದು ಡೇಟಾವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬೇಕಾದ ಪ್ರಕ್ರಿಯೆಯನ್ನು (ಪ್ರೋಗ್ರಾಂ) ಗುರುತಿಸಲು ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸುವಾಗ ಮತ್ತು ರವಾನಿಸುವಾಗ ಬಳಸಲಾಗುವ ಸಂಖ್ಯೆ. ಆದ್ದರಿಂದ, ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಪೋರ್ಟ್ 80 ಗೆ ಕಳುಹಿಸಿದರೆ, ಮಾಹಿತಿಯನ್ನು HTTP ಸರ್ವರ್‌ಗೆ ಉದ್ದೇಶಿಸಲಾಗಿದೆ ಎಂದು ಇದು ಸೂಚಿಸುತ್ತದೆ.

1 ರಿಂದ 1023 ರವರೆಗಿನ ಪೋರ್ಟ್ ಸಂಖ್ಯೆಗಳನ್ನು ನಿರ್ದಿಷ್ಟ ಕಾರ್ಯಕ್ರಮಗಳಿಗೆ ನಿಗದಿಪಡಿಸಲಾಗಿದೆ (ಪ್ರಸಿದ್ಧ ಪೋರ್ಟ್‌ಗಳು ಎಂದು ಕರೆಯಲ್ಪಡುವ). 1024 -65 535 ಸಂಖ್ಯೆಯ ಪೋರ್ಟ್‌ಗಳನ್ನು ಸ್ವಾಮ್ಯದ ಕಾರ್ಯಕ್ರಮಗಳಲ್ಲಿ ಬಳಸಬಹುದು. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಉಚಿತ ಪೋರ್ಟ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ಮೂಲಕ ಸಂಭವನೀಯ ಘರ್ಷಣೆಗಳನ್ನು ಕಾರ್ಯಕ್ರಮಗಳ ಮೂಲಕ ಪರಿಹರಿಸಬೇಕು. ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ಪೋರ್ಟ್‌ಗಳನ್ನು ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ವಿತರಿಸಲಾಗುತ್ತದೆ: ಮುಂದಿನ ಬಾರಿ ಪ್ರೋಗ್ರಾಂ ಪ್ರಾರಂಭವಾದಾಗ, ಅದು ವಿಭಿನ್ನ ಪೋರ್ಟ್ ಮೌಲ್ಯವನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ಸಾಧ್ಯತೆಯಿದೆ, ಹೊರತು, ನೀವು ಸೆಟ್ಟಿಂಗ್‌ಗಳ ಮೂಲಕ ಪೋರ್ಟ್ ಅನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಹೊಂದಿಸದಿದ್ದರೆ.

MAC ವಿಳಾಸ ಎಂದರೇನು

ವಾಸ್ತವವಾಗಿ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಕಳುಹಿಸಲಾದ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಕಂಪ್ಯೂಟರ್ಗಳಿಗೆ ಅವರ ಹೆಸರುಗಳಿಂದ ಅಥವಾ IP ವಿಳಾಸದಿಂದ ತಿಳಿಸಲಾಗುವುದಿಲ್ಲ. ಪ್ಯಾಕೆಟ್ ನಿರ್ದಿಷ್ಟ ವಿಳಾಸವನ್ನು ಹೊಂದಿರುವ ಸಾಧನಕ್ಕಾಗಿ ಉದ್ದೇಶಿಸಲಾಗಿದೆ, ಇದನ್ನು MAC ವಿಳಾಸ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ.

MAC ವಿಳಾಸವು ನೆಟ್‌ವರ್ಕ್ ಸಾಧನದ ವಿಶಿಷ್ಟ ವಿಳಾಸವಾಗಿದೆ, ಇದನ್ನು ಸಲಕರಣೆ ತಯಾರಕರಿಂದ ನಿಯೋಜಿಸಲಾಗಿದೆ, ಅಂದರೆ. ಇದು ನಿಮ್ಮ ನೆಟ್‌ವರ್ಕ್ ಕಾರ್ಡ್‌ನ ಒಂದು ರೀತಿಯ ಸ್ಟ್ಯಾಂಪ್ ಮಾಡಿದ ಸಂಖ್ಯೆ. MAC ವಿಳಾಸದ ಮೊದಲಾರ್ಧವು ತಯಾರಕರ ಗುರುತಿಸುವಿಕೆಯಾಗಿದೆ, ಎರಡನೆಯದು ಈ ಸಾಧನದ ಅನನ್ಯ ಸಂಖ್ಯೆಯಾಗಿದೆ.

ನಿಯಮದಂತೆ, ಗುರುತಿಸುವಿಕೆಗಾಗಿ MAC ವಿಳಾಸದ ಅಗತ್ಯವಿದೆ, ಒದಗಿಸುವವರೊಂದಿಗೆ (ಒದಗಿಸುವವರು ಲಾಗಿನ್-ಪಾಸ್ವರ್ಡ್ ಬದಲಿಗೆ MAC ವಿಳಾಸ ಬೈಂಡಿಂಗ್ ಅನ್ನು ಬಳಸಿದರೆ) ಅಥವಾ ರೂಟರ್ ಅನ್ನು ಹೊಂದಿಸುವಾಗ.

ಎಲ್ಲಾ ನೆಟ್‌ವರ್ಕ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಎಲ್ಲಿ ನೋಡಬೇಕು

ನೀವು ಎಲ್ಲಿ ನೋಡಬಹುದು ಮತ್ತು ಇದನ್ನೆಲ್ಲ ಬದಲಾಯಿಸಬಹುದು ಎಂಬುದರ ಕುರಿತು ಕೆಲವು ಪದಗಳನ್ನು ಹೇಳಲು ನಾನು ಬಹುತೇಕ ಮರೆತಿದ್ದೇನೆ.

ಬಳಕೆದಾರರ ಡೇಟಾಗ್ರಾಮ್ ಪ್ರೋಟೋಕಾಲ್ (UDP) TCP/IP ಪ್ರೋಟೋಕಾಲ್ ಸೂಟ್‌ನಿಂದ ಲಭ್ಯವಿರುವ ಸರಳವಾದ ಸಾರಿಗೆ ಲೇಯರ್ ಸಂವಹನ ಪ್ರೋಟೋಕಾಲ್ ಆಗಿದೆ. ಇದು ಕನಿಷ್ಟ ಸಂವಹನ ಕಾರ್ಯವಿಧಾನದ ಕಾರಣದಿಂದಾಗಿರುತ್ತದೆ. UDP ಅನ್ನು ವಿಶ್ವಾಸಾರ್ಹವಲ್ಲದ ಸಾರಿಗೆ ಪ್ರೋಟೋಕಾಲ್ ಎಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ, ಆದರೆ ಇದು IP ಸೇವೆಗಳನ್ನು ಬಳಸುತ್ತದೆ ಅದು ಉತ್ತಮ ಪ್ರಯತ್ನದ ವಿತರಣಾ ಕಾರ್ಯವಿಧಾನವನ್ನು ಒದಗಿಸುತ್ತದೆ.

UDP ಯಲ್ಲಿ, ಸ್ವೀಕರಿಸುವವರು ಸ್ವೀಕರಿಸಿದ ಪ್ಯಾಕೆಟ್‌ನ ಸ್ವೀಕೃತಿಯನ್ನು ರಚಿಸುವುದಿಲ್ಲ ಮತ್ತು ಕಳುಹಿಸುವವರು ಕಳುಹಿಸಿದ ಪ್ಯಾಕೆಟ್‌ನ ಸ್ವೀಕೃತಿಯನ್ನು ನಿರೀಕ್ಷಿಸುವುದಿಲ್ಲ. ಈ ನ್ಯೂನತೆಯು ಈ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ವಿಶ್ವಾಸಾರ್ಹವಲ್ಲ ಮತ್ತು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಸುಲಭಗೊಳಿಸುತ್ತದೆ.

ಯುಡಿಪಿಗೆ ಬೇಡಿಕೆ

ಪ್ರಶ್ನೆ ಉದ್ಭವಿಸಬಹುದು, ಡೇಟಾವನ್ನು ಸಾಗಿಸಲು ನಮಗೆ ವಿಶ್ವಾಸಾರ್ಹವಲ್ಲದ ಪ್ರೋಟೋಕಾಲ್ ಏಕೆ ಬೇಕು? ಸ್ವೀಕೃತಿ ಪ್ಯಾಕೆಟ್‌ಗಳು ನಿಜವಾದ ಡೇಟಾದ ಜೊತೆಗೆ ಗಮನಾರ್ಹ ಪ್ರಮಾಣದ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಅನ್ನು ಹೊಂದಿರುವಲ್ಲಿ ನಾವು UDP ಅನ್ನು ನಿಯೋಜಿಸುತ್ತೇವೆ. ಉದಾಹರಣೆಗೆ, ವೀಡಿಯೊ ಸ್ಟ್ರೀಮಿಂಗ್ ಸಂದರ್ಭದಲ್ಲಿ, ಸಾವಿರಾರು ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಅದರ ಬಳಕೆದಾರರಿಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ. ಎಲ್ಲಾ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಗುರುತಿಸುವುದು ಕಷ್ಟ ಮತ್ತು ದೊಡ್ಡ ಪ್ರಮಾಣದ ವ್ಯರ್ಥ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಅನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಆಧಾರವಾಗಿರುವ IP ಪ್ರೋಟೋಕಾಲ್‌ನ ಅತ್ಯುತ್ತಮ ವಿತರಣಾ ಕಾರ್ಯವಿಧಾನವು ಅದರ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ತಲುಪಿಸಲು ಅತ್ಯುತ್ತಮ ಪ್ರಯತ್ನವನ್ನು ಮಾಡುತ್ತದೆ, ಆದರೆ ವೀಡಿಯೊ ಸ್ಟ್ರೀಮ್‌ನಲ್ಲಿ ಕೆಲವು ಪ್ಯಾಕೆಟ್‌ಗಳು ಕಳೆದುಹೋದರೂ ಸಹ, ಇದು ದುರಂತವಲ್ಲ ಮತ್ತು ಸುಲಭವಾಗಿ ನಿರ್ಲಕ್ಷಿಸಬಹುದು. ವೀಡಿಯೊ ಮತ್ತು ಧ್ವನಿ ಸಂಚಾರದಲ್ಲಿ ಹಲವಾರು ಪ್ಯಾಕೆಟ್‌ಗಳ ನಷ್ಟವು ಕೆಲವೊಮ್ಮೆ ಗಮನಕ್ಕೆ ಬರುವುದಿಲ್ಲ.

ಬಳಕೆದಾರರ ಡೇಟಾಗ್ರಾಮ್ ಪ್ರೋಟೋಕಾಲ್ ವೈಶಿಷ್ಟ್ಯಗಳು

• ಡೇಟಾ ದೃಢೀಕರಣಕ್ಕೆ ಯಾವುದೇ ಪ್ರಾಮುಖ್ಯತೆ ಇಲ್ಲದಿದ್ದಾಗ UDP ಅನ್ನು ಬಳಸಲಾಗುತ್ತದೆ.
• UDP ಒಂದು ದಿಕ್ಕಿನಲ್ಲಿ ಡೇಟಾವನ್ನು ರವಾನಿಸಲು ಉತ್ತಮ ಪ್ರೋಟೋಕಾಲ್ ಆಗಿದೆ.
• UDP ಸರಳವಾಗಿದೆ ಮತ್ತು ವಿನಂತಿ ಆಧಾರಿತ ಸಂದೇಶಗಳಿಗೆ ಸೂಕ್ತವಾಗಿದೆ.
• UDP ಸಂಪರ್ಕ ಆಧಾರಿತವಾಗಿಲ್ಲ.
• UDP ದಟ್ಟಣೆ ನಿಯಂತ್ರಣ ಕಾರ್ಯವಿಧಾನವನ್ನು ಒದಗಿಸುವುದಿಲ್ಲ.
• UDP ಕಸ್ಟಮೈಸ್ ಮಾಡಿದ ಡೇಟಾ ವಿತರಣೆಯನ್ನು ಖಾತರಿಪಡಿಸುವುದಿಲ್ಲ.
• VoIP, ಮೀಡಿಯಾ ಸ್ಟ್ರೀಮಿಂಗ್‌ನಂತಹ ಸ್ಟ್ರೀಮಿಂಗ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ UDP ಸೂಕ್ತವಾದ ಪ್ರೋಟೋಕಾಲ್ ಆಗಿದೆ.

UDP ಹೆಡರ್

UDP ಹೆಡರ್ ಅದರ ಕಾರ್ಯದಂತೆಯೇ ಸರಳವಾಗಿದೆ.

UDP ಹೆಡರ್ ನಾಲ್ಕು ಮುಖ್ಯ ನಿಯತಾಂಕಗಳನ್ನು ಒಳಗೊಂಡಿದೆ:

• ಮೂಲ ಬಂದರು- ಪ್ಯಾಕೆಟ್‌ನ ಮೂಲ ಪೋರ್ಟ್ ಅನ್ನು ಗುರುತಿಸಲು ಈ 16-ಬಿಟ್ ಮಾಹಿತಿಯನ್ನು ಬಳಸಲಾಗುತ್ತದೆ.
• ತಲುಪಬೇಕಾದ ಬಂದರು- ಈ 16-ಬಿಟ್ ಮಾಹಿತಿಯನ್ನು ಗಮ್ಯಸ್ಥಾನ ಯಂತ್ರದಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ ಮಟ್ಟದ ಸೇವೆಯನ್ನು ಗುರುತಿಸಲು ಬಳಸಲಾಗುತ್ತದೆ.
• ಉದ್ದ- ಉದ್ದವು UDP ಪ್ಯಾಕೆಟ್‌ನ ಸಂಪೂರ್ಣ ಉದ್ದವನ್ನು ಸೂಚಿಸುತ್ತದೆ (ಹೆಡರ್ ಸೇರಿದಂತೆ). ಇದು 16-ಬಿಟ್ ಕ್ಷೇತ್ರವಾಗಿದೆ, ಮತ್ತು ಕನಿಷ್ಠ ಮೌಲ್ಯವು 8 ಬೈಟ್‌ಗಳು, ಇದು UDP ಹೆಡರ್‌ನ ಗಾತ್ರವಾಗಿದೆ.
• ಚೆಕ್ಸಮ್. ಕಳುಹಿಸುವ ಮೊದಲು ಕಳುಹಿಸುವವರು ರಚಿಸಿದ ಚೆಕ್‌ಸಮ್ ಮೌಲ್ಯವನ್ನು ಈ ಕ್ಷೇತ್ರವು ಸಂಗ್ರಹಿಸುತ್ತದೆ. IPv4 ಈ ಕ್ಷೇತ್ರವನ್ನು ಐಚ್ಛಿಕವಾಗಿ ಹೊಂದಿದೆ, ಆದ್ದರಿಂದ ಚೆಕ್‌ಸಮ್ ಕ್ಷೇತ್ರವು ಯಾವುದೇ ಮೌಲ್ಯವನ್ನು ಹೊಂದಿರದಿದ್ದಾಗ, ಅದನ್ನು 0 ಗೆ ಹೊಂದಿಸಲಾಗಿದೆ ಮತ್ತು ಅದರ ಎಲ್ಲಾ ಬಿಟ್‌ಗಳನ್ನು ಶೂನ್ಯಕ್ಕೆ ಹೊಂದಿಸಲಾಗಿದೆ.

UDP ಅನ್ನು ಎಲ್ಲಿ ಬಳಸಲಾಗುತ್ತದೆ?

ಡೇಟಾವನ್ನು ವರ್ಗಾಯಿಸಲು UDP ಬಳಸುವ ಕೆಲವು ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಇಲ್ಲಿವೆ:

• ಡೊಮೇನ್ ಹೆಸರು ಸೇವೆಗಳು
• ಸರಳ ನೆಟ್‌ವರ್ಕ್ ಮ್ಯಾನೇಜ್‌ಮೆಂಟ್ ಪ್ರೋಟೋಕಾಲ್
• ಕ್ಷುಲ್ಲಕ ಫೈಲ್ ವರ್ಗಾವಣೆ ಪ್ರೋಟೋಕಾಲ್
• ರೂಟಿಂಗ್ ಮಾಹಿತಿ ಪ್ರೋಟೋಕಾಲ್
• ಕೆರ್ಬರೋಸ್

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

TCP ಬೇಸಿಕ್ಸ್

ಟ್ರಾನ್ಸ್‌ಮಿಷನ್ ಕಂಟ್ರೋಲ್ ಪ್ರೋಟೋಕಾಲ್ (TCP) ನಿರ್ದಿಷ್ಟವಾಗಿ ವಿಶ್ವಾಸಾರ್ಹವಲ್ಲದ ಇಂಟರ್ನೆಟ್ ನೆಟ್‌ವರ್ಕ್ ಮೂಲಕ ವಿಶ್ವಾಸಾರ್ಹ ಅಂತ್ಯದಿಂದ ಕೊನೆಯವರೆಗೆ ಬೈಟ್ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಒದಗಿಸಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. ಅಂತರ್ಸಂಪರ್ಕಿತ ನೆಟ್‌ವರ್ಕ್ ಅದ್ವಿತೀಯ ನೆಟ್‌ವರ್ಕ್‌ನಿಂದ ಭಿನ್ನವಾಗಿರುತ್ತದೆ, ಅದರ ವಿಭಿನ್ನ ವಿಭಾಗಗಳು ವಿಭಿನ್ನ ಟೋಪೋಲಾಜಿಗಳು, ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್‌ಗಳು, ಲೇಟೆನ್ಸಿ ಮೌಲ್ಯಗಳು, ಪ್ಯಾಕೆಟ್ ಗಾತ್ರಗಳು ಮತ್ತು ಇತರ ನಿಯತಾಂಕಗಳನ್ನು ಹೊಂದಿರಬಹುದು. TCP ಯ ಅಭಿವೃದ್ಧಿಯು ಪ್ರೋಟೋಕಾಲ್‌ನ ಸಾಮರ್ಥ್ಯದ ಮೇಲೆ ಇಂಟರ್ನೆಟ್‌ವರ್ಕ್‌ನ ಗುಣಲಕ್ಷಣಗಳಿಗೆ ಹೊಂದಿಕೊಳ್ಳುವ ಮತ್ತು ವಿವಿಧ ಸಮಸ್ಯೆಗಳ ಮುಖಾಂತರ ಚೇತರಿಸಿಕೊಳ್ಳುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಕೇಂದ್ರೀಕರಿಸಿದೆ.

TCP ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು RFC 793 ರಲ್ಲಿ ವಿವರಿಸಲಾಗಿದೆ. ಕಾಲಾನಂತರದಲ್ಲಿ, ವಿವಿಧ ದೋಷಗಳು ಮತ್ತು ತಪ್ಪುಗಳನ್ನು ಕಂಡುಹಿಡಿಯಲಾಗಿದೆ ಮತ್ತು ಕೆಲವು ವಿಷಯಗಳಲ್ಲಿ ಅಗತ್ಯತೆಗಳನ್ನು ಬದಲಾಯಿಸಲಾಗಿದೆ. ಈ ಸ್ಪಷ್ಟೀಕರಣಗಳು ಮತ್ತು ತಿದ್ದುಪಡಿಗಳ ವಿವರವಾದ ವಿವರಣೆಯನ್ನು RFC 1122 ರಲ್ಲಿ ನೀಡಲಾಗಿದೆ. ಪ್ರೋಟೋಕಾಲ್ ವಿಸ್ತರಣೆಗಳನ್ನು RFC 1323 ರಲ್ಲಿ ನೀಡಲಾಗಿದೆ.

TCP ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಬೆಂಬಲಿಸುವ ಪ್ರತಿಯೊಂದು ಯಂತ್ರವು TCP ಸಾರಿಗೆ ಘಟಕವನ್ನು ಹೊಂದಿದೆ, ಇದು ಗ್ರಂಥಾಲಯ ಕಾರ್ಯವಿಧಾನ, ಬಳಕೆದಾರ ಪ್ರಕ್ರಿಯೆ ಅಥವಾ ಸಿಸ್ಟಮ್ ಕರ್ನಲ್‌ನ ಭಾಗವಾಗಿದೆ. ಎರಡೂ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಸಾರಿಗೆ ಘಟಕವು TCP ಹರಿವುಗಳನ್ನು ಮತ್ತು IP ಪದರಕ್ಕೆ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. TCP ಘಟಕವು ಸ್ಥಳೀಯ ಪ್ರಕ್ರಿಯೆಗಳಿಂದ ಬಳಕೆದಾರರ ಡೇಟಾ ಸ್ಟ್ರೀಮ್‌ಗಳನ್ನು ಪಡೆಯುತ್ತದೆ, ಅವುಗಳನ್ನು 64 KB ಗಿಂತ ದೊಡ್ಡದಾದ ತುಂಡುಗಳಾಗಿ ವಿಭಜಿಸುತ್ತದೆ (ಆಚರಣೆಯಲ್ಲಿ, ಈ ಸಂಖ್ಯೆಯು ಸಾಮಾನ್ಯವಾಗಿ 460 ಬೈಟ್‌ಗಳ ಡೇಟಾ, ಇದು ಅವುಗಳನ್ನು IP ಮತ್ತು TCP ಹೆಡರ್‌ಗಳೊಂದಿಗೆ ಒಂದು ಎತರ್ನೆಟ್ ಫ್ರೇಮ್‌ನಲ್ಲಿ ಇರಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ), ಮತ್ತು ಅವುಗಳನ್ನು ಪ್ರತ್ಯೇಕ IP ಡೇಟಾಗ್ರಾಮ್‌ಗಳಾಗಿ ಕಳುಹಿಸುತ್ತದೆ. TCP ಡೇಟಾದೊಂದಿಗೆ IP ಡೇಟಾಗ್ರಾಮ್‌ಗಳು ಯಂತ್ರಕ್ಕೆ ಬಂದಾಗ, ಅವುಗಳನ್ನು TCP ಘಟಕಕ್ಕೆ ವರ್ಗಾಯಿಸಲಾಗುತ್ತದೆ, ಇದು ಮೂಲ ಬೈಟ್ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಪುನರ್ನಿರ್ಮಿಸುತ್ತದೆ. ಸರಳತೆಗಾಗಿ, ನಾವು ಕೆಲವೊಮ್ಮೆ TCP ಸಾರಿಗೆ ಘಟಕ (ಸಾಫ್ಟ್‌ವೇರ್‌ನ ತುಂಡು) ಅಥವಾ TCP ಪ್ರೋಟೋಕಾಲ್ (ನಿಯಮಗಳ ಒಂದು ಸೆಟ್) ಅನ್ನು ಉಲ್ಲೇಖಿಸಲು "TCP" ಅನ್ನು ಬಳಸುತ್ತೇವೆ. ಸನ್ನಿವೇಶದಿಂದ ಅರ್ಥವೇನು ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, "ಬಳಕೆದಾರರು TCP ಡೇಟಾವನ್ನು ರವಾನಿಸುತ್ತಿದ್ದಾರೆ" ಎಂಬ ಅಭಿವ್ಯಕ್ತಿಯಲ್ಲಿ TCP ಸಾರಿಗೆ ಘಟಕವನ್ನು ಸ್ವಾಭಾವಿಕವಾಗಿ ಸೂಚಿಸಲಾಗುತ್ತದೆ.

IP ಲೇಯರ್ ಡೇಟಾಗ್ರಾಮ್‌ಗಳ ಸರಿಯಾದ ವಿತರಣೆಯನ್ನು ಖಾತರಿಪಡಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ TCP ಅವಧಿ ಮೀರಿದ ಸಮಯ ಮೀರುವಿಕೆಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬೇಕು ಮತ್ತು ಅಗತ್ಯವಿದ್ದರೆ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಮರುಪ್ರಸಾರಿಸಬೇಕು. ಕೆಲವೊಮ್ಮೆ ಡೇಟಾಗ್ರಾಮ್‌ಗಳು ತಪ್ಪು ಕ್ರಮದಲ್ಲಿ ಬರುತ್ತವೆ. ಅಂತಹ ಡೇಟಾಗ್ರಾಮ್‌ಗಳಿಂದ ಸಂದೇಶಗಳನ್ನು ಮರುಪಡೆಯಲು TCP ಸಹ ಕಾರಣವಾಗಿದೆ. ಹೀಗಾಗಿ, IP ಒದಗಿಸದಿರುವ ಅನೇಕ ಬಳಕೆದಾರರು ಬಯಸುವ ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ಒದಗಿಸಲು TCP ಅನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ.

TCP ಸೇವಾ ಮಾದರಿ

TCP ಸೇವೆಯು ಕಳುಹಿಸುವವರು ಮತ್ತು ಸ್ವೀಕರಿಸುವವರು ರಚಿಸಿದ ಸಾಕೆಟ್‌ಗಳು (ಸಾಕೆಟ್‌ಗಳು ಅಥವಾ ಅಂತಿಮ ಬಿಂದುಗಳು) ಅನ್ನು ಆಧರಿಸಿದೆ. ಅವುಗಳನ್ನು ಬರ್ಕ್ಲಿ ಸಾಕೆಟ್ಸ್ ವಿಭಾಗದಲ್ಲಿ ಚರ್ಚಿಸಲಾಗಿದೆ. ಪ್ರತಿ ಸಾಕೆಟ್ ಹೋಸ್ಟ್‌ನ IP ವಿಳಾಸವನ್ನು ಒಳಗೊಂಡಿರುವ ಸಂಖ್ಯೆಯನ್ನು (ವಿಳಾಸ) ಹೊಂದಿದೆ ಮತ್ತು ಪೋರ್ಟ್ ಎಂದು ಕರೆಯಲ್ಪಡುವ ಹೋಸ್ಟ್‌ಗೆ ಸ್ಥಳೀಯ 16-ಬಿಟ್ ಸಂಖ್ಯೆಯನ್ನು ಹೊಂದಿರುತ್ತದೆ. TCP ಯಲ್ಲಿನ ಪೋರ್ಟ್ ಅನ್ನು TSAP ವಿಳಾಸ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. TCP ಸೇವೆಯನ್ನು ಪ್ರವೇಶಿಸಲು, ಕಳುಹಿಸುವ ಯಂತ್ರದಲ್ಲಿನ ಸಾಕೆಟ್ ಮತ್ತು ಸ್ವೀಕರಿಸುವವರ ಯಂತ್ರದಲ್ಲಿನ ಸಾಕೆಟ್ ನಡುವೆ ಸಂಪರ್ಕವನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಸ್ಥಾಪಿಸಬೇಕು.

ಒಂದು ಸಾಕೆಟ್ ಅನ್ನು ಏಕಕಾಲದಲ್ಲಿ ಅನೇಕ ಸಂಪರ್ಕಗಳಿಗೆ ಬಳಸಬಹುದು. ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ಎರಡು ಅಥವಾ ಹೆಚ್ಚಿನ ಸಂಪರ್ಕಗಳು ಒಂದೇ ಸಾಕೆಟ್‌ನಲ್ಲಿ ಕೊನೆಗೊಳ್ಳಬಹುದು. ಸಂಪರ್ಕಗಳನ್ನು ಎರಡೂ ತುದಿಗಳಲ್ಲಿ ಸಾಕೆಟ್ ಐಡಿಗಳಿಂದ ಪ್ರತ್ಯೇಕಿಸಲಾಗಿದೆ - (ಸಾಕೆಟ್1, ಸಾಕೆಟ್2). ವರ್ಚುವಲ್ ಚಾನಲ್ ಸಂಖ್ಯೆಗಳು ಅಥವಾ ಇತರ ಗುರುತಿಸುವಿಕೆಗಳನ್ನು ಬಳಸಲಾಗುವುದಿಲ್ಲ.

ಜನಪ್ರಿಯ ಪೋರ್ಟ್‌ಗಳು ಎಂದು ಕರೆಯಲ್ಪಡುವ 1024 ಕ್ಕಿಂತ ಕೆಳಗಿನ ಪೋರ್ಟ್ ಸಂಖ್ಯೆಗಳನ್ನು ಪ್ರಮಾಣಿತ ಸೇವೆಗಳಿಂದ ಕಾಯ್ದಿರಿಸಲಾಗಿದೆ. ಉದಾಹರಣೆಗೆ, FTP ಬಳಸಿಕೊಂಡು ಫೈಲ್ ಅನ್ನು ವರ್ಗಾಯಿಸಲು ಹೋಸ್ಟ್‌ಗೆ ಸಂಪರ್ಕಿಸಲು ಬಯಸುವ ಯಾವುದೇ ಪ್ರಕ್ರಿಯೆಯು ಗಮ್ಯಸ್ಥಾನ ಹೋಸ್ಟ್‌ನ ಪೋರ್ಟ್ 21 ಅನ್ನು ಸಂಪರ್ಕಿಸಬಹುದು ಮತ್ತು ಹೀಗಾಗಿ ಅದರ FTP ಡೀಮನ್ ಅನ್ನು ಸಂಪರ್ಕಿಸಬಹುದು. www.iana.org ವೆಬ್‌ಸೈಟ್‌ನಲ್ಲಿ ಜನಪ್ರಿಯ ಪೋರ್ಟ್‌ಗಳ ಪಟ್ಟಿಯನ್ನು ಒದಗಿಸಲಾಗಿದೆ.

ನಾವು ಸಹಜವಾಗಿ, ಬೂಟ್ ಸಮಯದಲ್ಲಿ ಪೋರ್ಟ್ 21 ಗೆ ಎಫ್‌ಟಿಪಿ ಡೀಮನ್ ಅನ್ನು ಬಂಧಿಸಬಹುದು, ನಂತರ ಟೆಲ್ನೆಟ್ ಡೀಮನ್ ಅನ್ನು ಪೋರ್ಟ್ 23 ಗೆ ಬಂಧಿಸಬಹುದು, ಇತ್ಯಾದಿ. ಆದರೆ, ನಾವು ಹಾಗೆ ಮಾಡಿದರೆ, ನಾವು ಡೀಮನ್‌ಗಳ ಬಗ್ಗೆ ಮಾಹಿತಿಯೊಂದಿಗೆ ಮೆಮೊರಿಯನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತೇವೆ , ವಾಸ್ತವವಾಗಿ , ಅವರು ಹೆಚ್ಚಿನ ಸಮಯ ನಿಷ್ಕ್ರಿಯವಾಗಿರುತ್ತಾರೆ. ಬದಲಾಗಿ, ಯುನಿಕ್ಸ್‌ನಲ್ಲಿ inetd ಎಂದು ಕರೆಯಲ್ಪಡುವ ಏಕ ಡೀಮನ್ ಅನ್ನು ಬಳಸುವುದು ಸಾಮಾನ್ಯವಾಗಿದೆ, ಇದು ಬಹು ಪೋರ್ಟ್‌ಗಳೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುತ್ತದೆ ಮತ್ತು ಮೊದಲ ಒಳಬರುವ ಸಂಪರ್ಕಕ್ಕಾಗಿ ಕಾಯುತ್ತದೆ. ಇದು ಸಂಭವಿಸಿದಾಗ, inetd ಹೊಸ ಪ್ರಕ್ರಿಯೆಯನ್ನು ರಚಿಸುತ್ತದೆ ಮತ್ತು ವಿನಂತಿಯನ್ನು ನಿರ್ವಹಿಸಲು ಸೂಕ್ತವಾದ ಡೀಮನ್ ಅನ್ನು ಆಹ್ವಾನಿಸುತ್ತದೆ. ಹೀಗಾಗಿ, inetd ಮಾತ್ರ ನಿರಂತರವಾಗಿ ಸಕ್ರಿಯವಾಗಿರುತ್ತದೆ, ಇತರರು ಅವರಿಗೆ ಕೆಲಸ ಇದ್ದಾಗ ಮಾತ್ರ ಕರೆಯುತ್ತಾರೆ. Inetd ವಿಶೇಷ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ ಅನ್ನು ಹೊಂದಿದೆ, ಇದರಿಂದ ಅದು ಪೋರ್ಟ್ ಅಸೈನ್‌ಮೆಂಟ್‌ಗಳ ಬಗ್ಗೆ ಕಲಿಯಬಹುದು. ಇದರರ್ಥ ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರು ಸಿಸ್ಟಮ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು ಆದ್ದರಿಂದ ನಿರಂತರ ಡೀಮನ್‌ಗಳು ಅತ್ಯಂತ ಜನನಿಬಿಡ ಪೋರ್ಟ್‌ಗಳೊಂದಿಗೆ ಸಂಬಂಧ ಹೊಂದಿವೆ (ಉದಾಹರಣೆಗೆ, 80), ಮತ್ತು inetd ಉಳಿದವುಗಳೊಂದಿಗೆ ಸಂಬಂಧ ಹೊಂದಿದೆ.

ಕೆಲವು ಕಾಯ್ದಿರಿಸಿದ ಬಂದರುಗಳು
	ಶಿಷ್ಟಾಚಾರ	ಬಳಕೆ
21	FTP	ಫೈಲ್‌ಗಳನ್ನು ವರ್ಗಾಯಿಸಲಾಗುತ್ತಿದೆ
23	ಟೆಲ್ನೆಟ್	ರಿಮೋಟ್ ಲಾಗಿನ್
25	SMTP	ಇಮೇಲ್
69	TFTP	ಸರಳವಾದ ಫೈಲ್ ವರ್ಗಾವಣೆ ಪ್ರೋಟೋಕಾಲ್
79	ಬೆರಳು	ಬಳಕೆದಾರರ ಮಾಹಿತಿಗಾಗಿ ಹುಡುಕಲಾಗುತ್ತಿದೆ
80	HTTP	ವರ್ಲ್ಡ್ ವೈಡ್ ವೆಬ್
110	POP-3	ರಿಮೋಟ್ ಇಮೇಲ್ ಪ್ರವೇಶ
119	NNTP	ಸುದ್ದಿ ಗುಂಪುಗಳು

ಎಲ್ಲಾ TCP ಸಂಪರ್ಕಗಳು ಪೂರ್ಣ ಡ್ಯುಪ್ಲೆಕ್ಸ್ ಮತ್ತು ಪಾಯಿಂಟ್-ಟು-ಪಾಯಿಂಟ್. ಫುಲ್ ಡ್ಯುಪ್ಲೆಕ್ಸ್ ಎಂದರೆ ಟ್ರಾಫಿಕ್ ಒಂದೇ ಸಮಯದಲ್ಲಿ ವಿರುದ್ಧ ದಿಕ್ಕಿನಲ್ಲಿ ಹರಿಯಬಹುದು. ಪಾಯಿಂಟ್-ಟು-ಪಾಯಿಂಟ್ ಸಂಪರ್ಕ ಎಂದರೆ ಅದು ಎರಡು ಅಂತಿಮ ಬಿಂದುಗಳನ್ನು ಹೊಂದಿದೆ. ಪ್ರಸಾರ ಮತ್ತು ಮಲ್ಟಿಕಾಸ್ಟಿಂಗ್ ಅನ್ನು TCP ಬೆಂಬಲಿಸುವುದಿಲ್ಲ.

TCP ಸಂಪರ್ಕವು ಬೈಟ್ ಸ್ಟ್ರೀಮ್ ಆಗಿದೆ, ಸಂದೇಶ ಸ್ಟ್ರೀಮ್ ಅಲ್ಲ. ಸಂದೇಶಗಳ ನಡುವಿನ ಗಡಿಗಳನ್ನು ಸಂರಕ್ಷಿಸಲಾಗಿಲ್ಲ. ಉದಾಹರಣೆಗೆ, ಕಳುಹಿಸುವ ಪ್ರಕ್ರಿಯೆಯು TCP ಸ್ಟ್ರೀಮ್‌ಗೆ ನಾಲ್ಕು 512-ಬೈಟ್ ಚಂಕ್‌ಗಳ ಡೇಟಾವನ್ನು ಬರೆದರೆ, ಆ ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸುವ ಪ್ರಕ್ರಿಯೆಗೆ ನಾಲ್ಕು 512-ಬೈಟ್ ಭಾಗಗಳು, ಎರಡು 1024-ಬೈಟ್ ಭಾಗಗಳು, ಒಂದು 2048-ಬೈಟ್ ಚಂಕ್ ಅಥವಾ ಯಾವುದಾದರೂ ರೂಪದಲ್ಲಿ ತಲುಪಿಸಬಹುದು. ಬೇರೆ. ಡೇಟಾವನ್ನು ಹೇಗೆ ಬರೆಯಲಾಗಿದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಲು ಸ್ವೀಕರಿಸುವವರಿಗೆ ಯಾವುದೇ ಮಾರ್ಗವಿಲ್ಲ.

UNIX ಸಿಸ್ಟಮ್‌ನಲ್ಲಿರುವ ಫೈಲ್‌ಗಳು ಸಹ ಈ ಆಸ್ತಿಯನ್ನು ಹೊಂದಿವೆ. ರೈಲ್ ಅನ್ನು ಓದುವ ಪ್ರೋಗ್ರಾಂ ಈ ಫೈಲ್ ಅನ್ನು ಹೇಗೆ ಬರೆಯಲಾಗಿದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ: ಬ್ಲಾಕ್-ಬೈ-ಬ್ಲಾಕ್, ಬೈಟ್-ಬೈಟ್, ಅಥವಾ ಸಂಪೂರ್ಣವಾಗಿ ಏಕಕಾಲದಲ್ಲಿ. UNIX ಸಿಸ್ಟಮ್ ಫೈಲ್‌ಗಳಂತೆ, TCP ಪ್ರೋಗ್ರಾಂಗಳು ಬೈಟ್‌ಗಳ ಅರ್ಥದ ಬಗ್ಗೆ ಯಾವುದೇ ಕಲ್ಪನೆ ಅಥವಾ ಕಾಳಜಿಯನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ. ಅವರಿಗೆ ಬೈಟ್ ಕೇವಲ ಬೈಟ್ ಆಗಿದೆ.

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

ಕೆಲವು ಹಳೆಯ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಪುಶ್ ಫ್ಲ್ಯಾಗ್ ಅನ್ನು ಸಂದೇಶ ಡಿಲಿಮಿಟರ್ ಆಗಿ ಬಳಸಿದವು. ಈ ಟ್ರಿಕ್ ಕೆಲವೊಮ್ಮೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆಯಾದರೂ, ಎಲ್ಲಾ TCP ಅನುಷ್ಠಾನಗಳು ಪುಶ್ ಫ್ಲ್ಯಾಗ್ ಅನ್ನು ಸ್ವೀಕರಿಸುವ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ರವಾನಿಸುವುದಿಲ್ಲ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಮೊದಲ ಪುಶ್ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಸಾಲಿನಲ್ಲಿ ಕಳುಹಿಸುವ ಮೊದಲು TCP ಘಟಕವು ಅಂತಹ ಹಲವಾರು ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸಿದರೆ (ಅಂದರೆ, ಔಟ್‌ಪುಟ್ ಲೈನ್ ಕಾರ್ಯನಿರತವಾಗಿದೆ), TCP ಘಟಕವು ಈ ಎಲ್ಲಾ ಡೇಟಾವನ್ನು ಒಂದೇ ಡೇಟಾಗ್ರಾಮ್‌ನಂತೆ ಕಳುಹಿಸುವ ಹಕ್ಕನ್ನು ಹೊಂದಿರುತ್ತದೆ, ಅವುಗಳನ್ನು ಪ್ರತ್ಯೇಕ ಭಾಗಗಳಾಗಿ ವಿಭಜಿಸುವುದಿಲ್ಲ.

ಉಲ್ಲೇಖಿಸಬೇಕಾದ TCP ಸೇವೆಯ ಕೊನೆಯ ವೈಶಿಷ್ಟ್ಯವೆಂದರೆ ತುರ್ತು ಡೇಟಾ. ಪ್ರೋಗ್ರಾಮ್‌ನೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುತ್ತಿರುವ ಬಳಕೆದಾರರು ಪ್ರಗತಿಯಲ್ಲಿರುವ ರಿಮೋಟ್ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸ್ಥಗಿತಗೊಳಿಸಲು Delete ಅಥವಾ Ctrl-C ಅನ್ನು ಸಂವಾದಾತ್ಮಕವಾಗಿ ಒತ್ತಿದಾಗ, ಕಳುಹಿಸುವ ಅಪ್ಲಿಕೇಶನ್ ಔಟ್‌ಪುಟ್ ಡೇಟಾ ಸ್ಟ್ರೀಮ್‌ನಲ್ಲಿ ನಿಯಂತ್ರಣ ಮಾಹಿತಿಯನ್ನು ಇರಿಸುತ್ತದೆ ಮತ್ತು ತುರ್ತು ಫ್ಲ್ಯಾಗ್‌ನೊಂದಿಗೆ TCP ಸೇವೆಗೆ ರವಾನಿಸುತ್ತದೆ. ಈ ಫ್ಲ್ಯಾಗ್ TCP ಘಟಕವು ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ ಮತ್ತು ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಸಂಪರ್ಕಕ್ಕಾಗಿ ಅದು ಹೊಂದಿರುವುದನ್ನು ತಕ್ಷಣವೇ ಬಿಡುಗಡೆ ಮಾಡುತ್ತದೆ.

ತುರ್ತು ಡೇಟಾವು ಅದರ ಗಮ್ಯಸ್ಥಾನವನ್ನು ತಲುಪಿದಾಗ, ಸ್ವೀಕರಿಸುವ ಅಪ್ಲಿಕೇಶನ್ ಅಡಚಣೆಯಾಗುತ್ತದೆ (ಅಂದರೆ, UNIX ಪರಿಭಾಷೆಯಲ್ಲಿ "ಸಿಗ್ನಲ್"), ಅದರ ನಂತರ ಅದು ಇನ್‌ಪುಟ್ ಸ್ಟ್ರೀಮ್‌ನಿಂದ ಡೇಟಾವನ್ನು ಓದಬಹುದು ಮತ್ತು ಅವುಗಳಲ್ಲಿ ತುರ್ತು ಡೇಟಾವನ್ನು ಹುಡುಕಬಹುದು. ತುರ್ತು ಡೇಟಾದ ಅಂತ್ಯವನ್ನು ಗುರುತಿಸಲಾಗಿದೆ ಇದರಿಂದ ಅಪ್ಲಿಕೇಶನ್ ಎಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ ಎಂಬುದನ್ನು ಗುರುತಿಸಬಹುದು. ತುರ್ತು ಡೇಟಾದ ಪ್ರಾರಂಭವನ್ನು ಗುರುತಿಸಲಾಗಿಲ್ಲ. ಅಪ್ಲಿಕೇಶನ್ ಅದನ್ನು ತನ್ನದೇ ಆದ ಮೇಲೆ ಲೆಕ್ಕಾಚಾರ ಮಾಡಬೇಕು. ಈ ಸರ್ಕ್ಯೂಟ್ ಕಚ್ಚಾ ಸಿಗ್ನಲಿಂಗ್ ಕಾರ್ಯವಿಧಾನವನ್ನು ಒದಗಿಸುತ್ತದೆ, ಉಳಿದೆಲ್ಲವನ್ನೂ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಬಿಡುತ್ತದೆ.

TCP ಪ್ರೋಟೋಕಾಲ್

ಈ ವಿಭಾಗವು ಸಾಮಾನ್ಯ ಪರಿಭಾಷೆಯಲ್ಲಿ TCP ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಚರ್ಚಿಸುತ್ತದೆ. ಮುಂದಿನ ವಿಭಾಗದಲ್ಲಿ, ನಾವು ಕ್ಷೇತ್ರದಿಂದ ಕ್ಷೇತ್ರದಿಂದ ಪ್ರೋಟೋಕಾಲ್ ಹೆಡರ್ ಅನ್ನು ಚರ್ಚಿಸುತ್ತೇವೆ.

ಸಂಪೂರ್ಣ ಪ್ರೋಟೋಕಾಲ್ ರಚನೆಯನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುವ TCP ಯ ಪ್ರಮುಖ ಗುಣಲಕ್ಷಣವೆಂದರೆ TCP ಸಂಪರ್ಕದಲ್ಲಿ, ಪ್ರತಿ ಬೈಟ್ ತನ್ನದೇ ಆದ 32-ಬಿಟ್ ಅನುಕ್ರಮ ಸಂಖ್ಯೆಯನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಇಂಟರ್ನೆಟ್‌ನ ಆರಂಭಿಕ ವರ್ಷಗಳಲ್ಲಿ, ರೂಟರ್‌ಗಳ ನಡುವಿನ ಮೂಲ ಡೇಟಾ ವರ್ಗಾವಣೆ ವೇಗವು ಗುತ್ತಿಗೆ ಪಡೆದ ಲೈನ್‌ಗಳ ಮೂಲಕ 56 Kbps ಆಗಿತ್ತು. ಅತಿವೇಗದಲ್ಲಿ ನಿರಂತರವಾಗಿ ಡೇಟಾವನ್ನು ಪಂಪ್ ಮಾಡುವ ಹೋಸ್ಟ್‌ಗೆ, ಅನುಕ್ರಮ ಸಂಖ್ಯೆಗಳು ಪೂರ್ಣ ವೃತ್ತಕ್ಕೆ ಬರಲು ಒಂದು ವಾರಕ್ಕಿಂತ ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಪ್ರಸ್ತುತ ವೇಗದಲ್ಲಿ, ಅನುಕ್ರಮ ಸಂಖ್ಯೆಗಳು ಬಹಳ ಬೇಗನೆ ಖಾಲಿಯಾಗಬಹುದು, ನಂತರ ಇದರ ಕುರಿತು ಇನ್ನಷ್ಟು. ಸ್ವೀಕೃತಿಗಳಿಗಾಗಿ ಮತ್ತು ಸ್ಲೈಡಿಂಗ್ ವಿಂಡೋ ಕಾರ್ಯವಿಧಾನಕ್ಕಾಗಿ ಪ್ರತ್ಯೇಕ 32-ಬಿಟ್ ಅನುಕ್ರಮ ಸಂಖ್ಯೆಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ, ಅದನ್ನು ನಂತರ ಚರ್ಚಿಸಲಾಗುವುದು.

ಕಳುಹಿಸುವ ಮತ್ತು ಸ್ವೀಕರಿಸುವ TCP ಘಟಕಗಳು ವಿಭಾಗಗಳ ರೂಪದಲ್ಲಿ ಡೇಟಾವನ್ನು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳುತ್ತವೆ. ಒಂದು ವಿಭಾಗವು ಸ್ಥಿರ 20-ಬೈಟ್ ಹೆಡರ್ ಅನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ (ಜೊತೆಗೆ ಐಚ್ಛಿಕ ಭಾಗ), ಇದನ್ನು ಡೇಟಾ ಬೈಟ್‌ಗಳು ಅನುಸರಿಸಬಹುದು. ವಿಭಾಗಗಳ ಗಾತ್ರವನ್ನು TCP ಸಾಫ್ಟ್‌ವೇರ್ ನಿರ್ಧರಿಸುತ್ತದೆ. ಇದು ಹಲವಾರು ಬರವಣಿಗೆಯ ಕಾರ್ಯಾಚರಣೆಗಳ ಪರಿಣಾಮವಾಗಿ ಪಡೆದ ಡೇಟಾವನ್ನು ಒಂದು ವಿಭಾಗಕ್ಕೆ ಸಂಯೋಜಿಸಬಹುದು ಅಥವಾ ಇದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ, ಹಲವಾರು ವಿಭಾಗಗಳಲ್ಲಿ ಒಂದು ಬರಹದ ಫಲಿತಾಂಶವನ್ನು ವಿತರಿಸಬಹುದು. ವಿಭಾಗಗಳ ಗಾತ್ರವು ಎರಡು ಮಿತಿಗಳಿಂದ ಸೀಮಿತವಾಗಿದೆ. ಮೊದಲಿಗೆ, TCP ಹೆಡರ್ ಸೇರಿದಂತೆ ಪ್ರತಿಯೊಂದು ವಿಭಾಗವು IP ಪ್ಯಾಕೆಟ್‌ನ 65,515-ಬೈಟ್ ಪೇಲೋಡ್ ಕ್ಷೇತ್ರಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗಬೇಕು. ಎರಡನೆಯದಾಗಿ, ಪ್ರತಿ ನೆಟ್‌ವರ್ಕ್ ಗರಿಷ್ಠ ವರ್ಗಾವಣೆ ಘಟಕವನ್ನು (MTU) ಹೊಂದಿದೆ ಮತ್ತು ಪ್ರತಿ ವಿಭಾಗವು MTU ಗೆ ಹೊಂದಿಕೆಯಾಗಬೇಕು. ಪ್ರಾಯೋಗಿಕವಾಗಿ, ಗರಿಷ್ಠ ಪ್ರಸರಣ ಘಟಕದ ಗಾತ್ರವು ವಿಶಿಷ್ಟವಾಗಿ 1500 ಬೈಟ್‌ಗಳಾಗಿರುತ್ತದೆ (ಇದು ಈಥರ್ನೆಟ್ ಪೇಲೋಡ್ ಕ್ಷೇತ್ರದ ಗಾತ್ರಕ್ಕೆ ಅನುರೂಪವಾಗಿದೆ), ಮತ್ತು ಹೀಗೆ ವಿಭಾಗದ ಗಾತ್ರದ ಮೇಲಿನ ಮಿತಿಯನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ.

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

ಮುಂದಿನ ನಿರೀಕ್ಷಿತ ವಿಭಾಗದ ಅನುಕ್ರಮ ಸಂಖ್ಯೆಗೆ ಸಮಾನವಾದ ಸ್ವೀಕೃತಿ. ಸ್ವೀಕೃತಿಯ ಅವಧಿ ಮುಗಿದರೆ, ಕಳುಹಿಸುವವರು ವಿಭಾಗವನ್ನು ಮರುಕಳುಹಿಸುತ್ತಾರೆ.

ಈ ಪ್ರೋಟೋಕಾಲ್ ಸರಳವಾಗಿ ತೋರುತ್ತದೆಯಾದರೂ, ಹೆಚ್ಚು ವಿವರವಾಗಿ ಪರಿಶೀಲಿಸಬೇಕಾದ ಹಲವಾರು ವಿವರಗಳಿವೆ. ವಿಭಾಗಗಳು ತಪ್ಪಾದ ಕ್ರಮದಲ್ಲಿ ಬರಬಹುದು. ಆದ್ದರಿಂದ, ಉದಾಹರಣೆಗೆ, 3072 ರಿಂದ 4095 ಬೈಟ್‌ಗಳು ಈಗಾಗಲೇ ಬಂದಿರುವ ಸಾಧ್ಯತೆಯಿದೆ, ಆದರೆ ಅವರಿಗೆ ಸ್ವೀಕೃತಿಯನ್ನು ಕಳುಹಿಸಲಾಗುವುದಿಲ್ಲ ಏಕೆಂದರೆ ಬೈಟ್‌ಗಳು 2048 ರಿಂದ 3071 ಇನ್ನೂ ಸ್ವೀಕರಿಸಲಾಗಿಲ್ಲ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಸೆಗ್‌ಮೆಂಟ್‌ಗಳು ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ದೀರ್ಘಕಾಲ ಉಳಿಯಬಹುದು, ಕಳುಹಿಸುವವರು ಸಮಯ ಮೀರುತ್ತಾರೆ ಮತ್ತು ಅವುಗಳನ್ನು ಮತ್ತೆ ರವಾನಿಸುತ್ತಾರೆ. ಮರುಪ್ರಸಾರ ಮಾಡಲಾದ ವಿಭಾಗವು ವಿಭಿನ್ನ ಶ್ರೇಣಿಯ ತುಣುಕುಗಳನ್ನು ಒಳಗೊಂಡಿರಬಹುದು, ಆದ್ದರಿಂದ ಈಗಾಗಲೇ ಸರಿಯಾಗಿ ಸ್ವೀಕರಿಸಿದ ಬೈಟ್ ಸಂಖ್ಯೆಗಳನ್ನು ನಿರ್ಧರಿಸಲು ಬಹಳ ಎಚ್ಚರಿಕೆಯ ಆಡಳಿತದ ಅಗತ್ಯವಿದೆ. ಆದಾಗ್ಯೂ, ಸ್ಟ್ರೀಮ್‌ನಲ್ಲಿರುವ ಪ್ರತಿಯೊಂದು ಬೈಟ್ ಅನ್ನು ಅದರ ಆಫ್‌ಸೆಟ್‌ನಿಂದ ಅನನ್ಯವಾಗಿ ಗುರುತಿಸಲಾಗಿರುವುದರಿಂದ, ಈ ಕಾರ್ಯವು ಕಾರ್ಯಸಾಧ್ಯವಾಗಿದೆ.

TCP ಈ ಸಮಸ್ಯೆಗಳನ್ನು ನಿಭಾಯಿಸಲು ಮತ್ತು ಅವುಗಳನ್ನು ಸಮರ್ಥವಾಗಿ ಪರಿಹರಿಸಲು ಶಕ್ತವಾಗಿರಬೇಕು. TCP ಸ್ಟ್ರೀಮ್‌ಗಳ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಅತ್ಯುತ್ತಮವಾಗಿಸಲು ಸಾಕಷ್ಟು ಪ್ರಯತ್ನಗಳನ್ನು ವ್ಯಯಿಸಲಾಗಿದೆ. ಮುಂದಿನ ವಿಭಾಗದಲ್ಲಿ, TCP ಪ್ರೋಟೋಕಾಲ್‌ನ ವಿವಿಧ ಅಳವಡಿಕೆಗಳಲ್ಲಿ ಬಳಸಲಾಗುವ ಹಲವಾರು ಅಲ್ಗಾರಿದಮ್‌ಗಳನ್ನು ನಾವು ಚರ್ಚಿಸುತ್ತೇವೆ.

TCP ವಿಭಾಗದ ಹೆಡರ್

ಪ್ರತಿಯೊಂದು ವಿಭಾಗವು 20-ಬೈಟ್ ಸ್ಥಿರ-ಫಾರ್ಮ್ಯಾಟ್ ಹೆಡರ್‌ನೊಂದಿಗೆ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ಇದನ್ನು ಹೆಚ್ಚುವರಿ ಕ್ಷೇತ್ರಗಳು ಅನುಸರಿಸಬಹುದು. ಹೆಚ್ಚುವರಿ ಕ್ಷೇತ್ರಗಳ ನಂತರ 65,535 - 20 - 20 = 65,495 ಬೈಟ್‌ಗಳ ಡೇಟಾ ಇರಬಹುದು, ಅಲ್ಲಿ ಮೊದಲ 20 ಬೈಟ್‌ಗಳು IP ಹೆಡರ್ ಮತ್ತು ಎರಡನೆಯದು TCP ಹೆಡರ್. ವಿಭಾಗಗಳು ಡೇಟಾವನ್ನು ಹೊಂದಿರದಿರಬಹುದು. ಅಂತಹ ವಿಭಾಗಗಳನ್ನು ಹೆಚ್ಚಾಗಿ ಸ್ವೀಕೃತಿಗಳನ್ನು ರವಾನಿಸಲು ಮತ್ತು ಸಂದೇಶಗಳನ್ನು ನಿಯಂತ್ರಿಸಲು ಬಳಸಲಾಗುತ್ತದೆ.

ಕ್ಷೇತ್ರದಿಂದ TCP ಹೆಡರ್ ಕ್ಷೇತ್ರವನ್ನು ನೋಡೋಣ. ರಿಸೀವರ್ ಪೋರ್ಟ್ ಮತ್ತು ಸೋರ್ಸ್ ಪೋರ್ಟ್ ಕ್ಷೇತ್ರಗಳು ಸ್ಥಳೀಯ ಸಂಪರ್ಕದ ಅಂತಿಮ ಬಿಂದುಗಳ ಗುರುತಿಸುವಿಕೆಗಳಾಗಿವೆ. ಹೋಸ್ಟ್ IP ವಿಳಾಸದೊಂದಿಗೆ ಪೋರ್ಟ್ ಸಂಖ್ಯೆಯು ವಿಶಿಷ್ಟವಾದ 48-ಬಿಟ್ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಐಡೆಂಟಿಫೈಯರ್ ಅನ್ನು ರೂಪಿಸುತ್ತದೆ. ಅಂತಹ ಗುರುತಿಸುವಿಕೆಗಳ ಜೋಡಿ, ಮೂಲ ಮತ್ತು ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಸಂಬಂಧಿಸಿದೆ, ಸಂಪರ್ಕವನ್ನು ಅನನ್ಯವಾಗಿ ಗುರುತಿಸುತ್ತದೆ.

ಅನುಕ್ರಮ ಸಂಖ್ಯೆ ಮತ್ತು ದೃಢೀಕರಣ ಸಂಖ್ಯೆ ಕ್ಷೇತ್ರಗಳು ತಮ್ಮ ಸಾಮಾನ್ಯ ಕಾರ್ಯಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತವೆ. ಸ್ವೀಕೃತಿ ಸಂಖ್ಯೆ ಕ್ಷೇತ್ರವು ನಿರೀಕ್ಷಿತ ಮುಂದಿನ ಬೈಟ್ ಅನ್ನು ಸೂಚಿಸುತ್ತದೆ, ಸ್ವೀಕರಿಸಿದ ಕೊನೆಯ ಬೈಟ್ ಅಲ್ಲ. ಎರಡೂ 32-ಬಿಟ್ ಆಗಿರುತ್ತವೆ ಏಕೆಂದರೆ TCP ಸ್ಟ್ರೀಮ್‌ನಲ್ಲಿನ ಪ್ರತಿ ಬೈಟ್ ಡೇಟಾ ಸಂಖ್ಯೆ ಇದೆ.

TCP ಹೆಡರ್ ಉದ್ದದ ಕ್ಷೇತ್ರವು TCP ಹೆಡರ್‌ನ ಗಾತ್ರವನ್ನು ಹೊಂದಿದೆ, ಇದನ್ನು 32-ಬಿಟ್ ಪದಗಳಲ್ಲಿ ವ್ಯಕ್ತಪಡಿಸಲಾಗುತ್ತದೆ. ಈ ಮಾಹಿತಿಯು ಅವಶ್ಯಕವಾಗಿದೆ ಏಕೆಂದರೆ ಐಚ್ಛಿಕ ಕ್ಷೇತ್ರಗಳ ಕ್ಷೇತ್ರ ಮತ್ತು ಅದರೊಂದಿಗೆ ಸಂಪೂರ್ಣ ಹೆಡರ್, ವೇರಿಯಬಲ್ ಉದ್ದವನ್ನು ಹೊಂದಿರಬಹುದು. ಮೂಲಭೂತವಾಗಿ, ಈ ಕ್ಷೇತ್ರವು ವಿಭಾಗದ ಪ್ರಾರಂಭದಿಂದ ಡೇಟಾ ಕ್ಷೇತ್ರಕ್ಕೆ ಆಫ್‌ಸೆಟ್ ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ, ಇದನ್ನು 32-ಬಿಟ್ ಪದಗಳಲ್ಲಿ ಅಳೆಯಲಾಗುತ್ತದೆ. ಇದು ಶೀರ್ಷಿಕೆಯ ಉದ್ದದಂತೆಯೇ ಇರುತ್ತದೆ.

ಮುಂದೆ ಬಳಕೆಯಾಗದ 6-ಬಿಟ್ ಕ್ಷೇತ್ರ ಬರುತ್ತದೆ. ಈ ಕ್ಷೇತ್ರವು ಕಾಲು ಶತಮಾನದಿಂದ ಉಳಿದುಕೊಂಡಿರುವುದು ಟಿಸಿಪಿಯ ವಿನ್ಯಾಸವನ್ನು ಎಷ್ಟು ಚೆನ್ನಾಗಿ ಯೋಚಿಸಿದೆ ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷಿಯಾಗಿದೆ.

ಇದನ್ನು ಆರು 1-ಬಿಟ್ ಫ್ಲ್ಯಾಗ್‌ಗಳು ಅನುಸರಿಸುತ್ತವೆ. ತುರ್ತು ಡೇಟಾ ಪಾಯಿಂಟರ್ ಕ್ಷೇತ್ರವನ್ನು ಬಳಸುವಾಗ URG ಬಿಟ್ ಅನ್ನು 1 ಕ್ಕೆ ಹೊಂದಿಸಲಾಗಿದೆ, ಇದು ಪ್ರಸ್ತುತ ಬೈಟ್ ಅನುಕ್ರಮ ಸಂಖ್ಯೆಯಿಂದ ತುರ್ತು ಡೇಟಾದ ಸ್ಥಳಕ್ಕೆ ಬೈಟ್ ಆಫ್‌ಸೆಟ್ ಅನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. TCP ಅಡಚಣೆ ಸಂದೇಶಗಳನ್ನು ಹೇಗೆ ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ. ಈಗಾಗಲೇ ಹೇಳಿದಂತೆ, TCP ಪ್ರೋಟೋಕಾಲ್ ಮಾತ್ರ ಸ್ವೀಕರಿಸುವವರಿಗೆ ಬಳಕೆದಾರ ಸಂಕೇತದ ವಿತರಣೆಯನ್ನು ಖಾತ್ರಿಗೊಳಿಸುತ್ತದೆ, ಅಡಚಣೆಯ ಕಾರಣದಲ್ಲಿ ಆಸಕ್ತಿಯಿಲ್ಲದೆ.

ACK ಬಿಟ್ ಅನ್ನು 1 ಕ್ಕೆ ಹೊಂದಿಸಿದರೆ, ಸ್ವೀಕೃತಿ ಸಂಖ್ಯೆ ಕ್ಷೇತ್ರವು ಅರ್ಥಪೂರ್ಣ ಡೇಟಾವನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಇಲ್ಲದಿದ್ದರೆ, ಈ ವಿಭಾಗವು ಸ್ವೀಕೃತಿಯನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ ಮತ್ತು ಸ್ವೀಕೃತಿ ಸಂಖ್ಯೆ ಕ್ಷೇತ್ರವನ್ನು ಸರಳವಾಗಿ ನಿರ್ಲಕ್ಷಿಸಲಾಗುತ್ತದೆ.

PSH ಬಿಟ್ ಮೂಲಭೂತವಾಗಿ ಪುಶ್ ಫ್ಲ್ಯಾಗ್ ಆಗಿದ್ದು, ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಸ್ವೀಕರಿಸಿದ ತಕ್ಷಣ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಡೇಟಾವನ್ನು ತಲುಪಿಸಲು ರಿಸೀವರ್‌ಗೆ ತಿಳಿಸಲು ಕಳುಹಿಸುವವರಿಗೆ ಹೇಳುತ್ತದೆ, ಬದಲಿಗೆ ಅದು ಪೂರ್ಣಗೊಳ್ಳುವವರೆಗೆ ಅದನ್ನು ಬಫರ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸುತ್ತದೆ. (ಹೆಚ್ಚಿನ ದಕ್ಷತೆಗಾಗಿ ಸ್ವೀಕರಿಸುವವರು ಬಫರ್ ಮಾಡಬಹುದು.)

RST ಬಿಟ್ ಅನ್ನು ಹೋಸ್ಟ್ ವೈಫಲ್ಯ ಅಥವಾ ಇತರ ಕಾರಣದಿಂದ ಡೆಡ್‌ಲಾಕ್ ಆಗಿರುವ ಸಂಪರ್ಕದ ಸ್ಥಿತಿಯನ್ನು ಮರುಹೊಂದಿಸಲು ಬಳಸಲಾಗುತ್ತದೆ. ಅಮಾನ್ಯ ವಿಭಾಗ ಅಥವಾ ಸಂಪರ್ಕವನ್ನು ರಚಿಸುವ ಪ್ರಯತ್ನವನ್ನು ತಿರಸ್ಕರಿಸಲು ಸಹ ಇದನ್ನು ಬಳಸಲಾಗುತ್ತದೆ. ನೀವು RST ಬಿಟ್ ಸೆಟ್‌ನೊಂದಿಗೆ ವಿಭಾಗವನ್ನು ಸ್ವೀಕರಿಸಿದರೆ, ಕೆಲವು ಸಮಸ್ಯೆ ಇದೆ.

ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸಲು SYN ಬಿಟ್ ಅನ್ನು ಬಳಸಲಾಗುತ್ತದೆ. ಸಂಪರ್ಕ ವಿನಂತಿಯು SYN ಬಿಟ್ = 1 ಮತ್ತು ACK ಬಿಟ್ = 0 ಅನ್ನು ಹೊಂದಿದೆ, ಅಂದರೆ ಸ್ವೀಕೃತಿ ಕ್ಷೇತ್ರವನ್ನು ಬಳಸಲಾಗುವುದಿಲ್ಲ. ಈ ವಿನಂತಿಯ ಪ್ರತಿಕ್ರಿಯೆಯು ಸ್ವೀಕೃತಿಯನ್ನು ಹೊಂದಿದೆ, ಆದ್ದರಿಂದ ಈ ಬಿಟ್‌ಗಳ ಮೌಲ್ಯಗಳು: SYN= 1, ACK- 1. ಹೀಗಾಗಿ, SYN ಬಿಟ್ ಅನ್ನು ಸಂಪರ್ಕ ವಿನಂತಿ ಮತ್ತು ಸಂಪರ್ಕವನ್ನು ಸ್ವೀಕರಿಸಿದ ವಿಭಾಗಗಳನ್ನು ಸೂಚಿಸಲು ಬಳಸಲಾಗುತ್ತದೆ ಮತ್ತು ACK ಬಿಟ್ ಅನ್ನು ಬಳಸಲಾಗುತ್ತದೆ ಅವುಗಳನ್ನು ಪರಸ್ಪರ ಪ್ರತ್ಯೇಕಿಸಲು.

ಸಂಪರ್ಕವನ್ನು ಕೊನೆಗೊಳಿಸಲು FIN ಬಿಟ್ ಅನ್ನು ಬಳಸಲಾಗುತ್ತದೆ. ಕಳುಹಿಸುವವರು ರವಾನಿಸಲು ಹೆಚ್ಚಿನ ಡೇಟಾವನ್ನು ಹೊಂದಿಲ್ಲ ಎಂದು ಇದು ಸೂಚಿಸುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಸಂಪರ್ಕವನ್ನು ಮುಚ್ಚಿದ ನಂತರವೂ, ಪ್ರಕ್ರಿಯೆಯು ಅನಿರ್ದಿಷ್ಟವಾಗಿ ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸುವುದನ್ನು ಮುಂದುವರಿಸಬಹುದು. FIN ಮತ್ತು SYN ಬಿಟ್‌ಗಳೊಂದಿಗಿನ ವಿಭಾಗಗಳು ಸರಿಯಾದ ಕ್ರಮದಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳಿಸುವುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಅನುಕ್ರಮ ಸಂಖ್ಯೆಗಳನ್ನು ಹೊಂದಿರುತ್ತವೆ.

TCP ಪ್ರೋಟೋಕಾಲ್ನಲ್ಲಿ ಹರಿವಿನ ನಿಯಂತ್ರಣವನ್ನು ವೇರಿಯಬಲ್ ಗಾತ್ರದ ಸ್ಲೈಡಿಂಗ್ ವಿಂಡೋವನ್ನು ಬಳಸಿ ಕೈಗೊಳ್ಳಲಾಗುತ್ತದೆ. ಸ್ವೀಕೃತಿ ಬೈಟ್ ನಂತರ ಎಷ್ಟು ಬೈಟ್‌ಗಳನ್ನು ಕಳುಹಿಸಬಹುದು ಎಂಬುದನ್ನು ವಿಂಡೋ ಗಾತ್ರದ ಕ್ಷೇತ್ರವು ಹೇಳುತ್ತದೆ. ವಿಂಡೋ ಗಾತ್ರದ ಕ್ಷೇತ್ರದ ಮೌಲ್ಯವು ಶೂನ್ಯವಾಗಿರಬಹುದು, ಅಂದರೆ ಸ್ವೀಕೃತಿ ಸಂಖ್ಯೆ-1 ರವರೆಗಿನ ಎಲ್ಲಾ ಬೈಟ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸಲಾಗಿದೆ, ಆದರೆ ಸ್ವೀಕರಿಸುವವರು ಪ್ರಸ್ತುತ ಕೆಲವು ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸುತ್ತಿದ್ದಾರೆ ಮತ್ತು ಉಳಿದ ಬೈಟ್‌ಗಳನ್ನು ಇನ್ನೂ ಸ್ವೀಕರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಅದೇ ಸ್ವೀಕೃತಿ ಸಂಖ್ಯೆ ಕ್ಷೇತ್ರದ ಮೌಲ್ಯ ಮತ್ತು ಶೂನ್ಯವಲ್ಲದ ವಿಂಡೋ ಗಾತ್ರದ ಕ್ಷೇತ್ರ ಮೌಲ್ಯದೊಂದಿಗೆ ವಿಭಾಗವನ್ನು ಕಳುಹಿಸುವ ಮೂಲಕ ಮುಂದಿನ ಪ್ರಸರಣಕ್ಕೆ ಅನುಮತಿಯನ್ನು ಪಡೆಯಬಹುದು.

ಕೆಲವು ಪ್ರೋಟೋಕಾಲ್‌ಗಳಲ್ಲಿ, ಫ್ರೇಮ್ ಸ್ವೀಕೃತಿಗಳು ಪ್ರಸರಣವನ್ನು ಮುಂದುವರಿಸಲು ಅನುಮತಿಗಳೊಂದಿಗೆ ಸಂಬಂಧ ಹೊಂದಿವೆ. ಈ ಸಂಬಂಧವು ಈ ಪ್ರೋಟೋಕಾಲ್‌ಗಳಲ್ಲಿ ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಸ್ಥಿರವಾದ ಸ್ಲೈಡಿಂಗ್ ವಿಂಡೋ ಗಾತ್ರದ ಪರಿಣಾಮವಾಗಿದೆ. TCP ಯಲ್ಲಿ, ಡೇಟಾವನ್ನು ರವಾನಿಸಲು ಅನುಮತಿಗಳಿಂದ ಸ್ವೀಕೃತಿಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಲಾಗುತ್ತದೆ. ಮೂಲಭೂತವಾಗಿ, ಸ್ವೀಕರಿಸುವವರು ಹೀಗೆ ಹೇಳಬಹುದು, "ನಾನು k-ro ವರೆಗೆ ಬೈಟ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೇನೆ, ಆದರೆ ಇದೀಗ ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸುವುದನ್ನು ಮುಂದುವರಿಸಲು ನಾನು ಬಯಸುವುದಿಲ್ಲ." ಈ ವಿಭಾಗವು (ವೇರಿಯಬಲ್ ಗಾತ್ರದ ಸ್ಲೈಡಿಂಗ್ ವಿಂಡೋದಂತೆ ವ್ಯಕ್ತಪಡಿಸಲಾಗುತ್ತದೆ) ಪ್ರೋಟೋಕಾಲ್ಗೆ ಹೆಚ್ಚುವರಿ ನಮ್ಯತೆಯನ್ನು ನೀಡುತ್ತದೆ. ನಾವು ಈ ಅಂಶವನ್ನು ಕೆಳಗೆ ಹೆಚ್ಚು ವಿವರವಾಗಿ ಚರ್ಚಿಸುತ್ತೇವೆ.

ಚೆಕ್ಸಮ್ ಕ್ಷೇತ್ರವನ್ನು ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ಹೆಚ್ಚಿಸಲು ಬಳಸಲಾಗುತ್ತದೆ. ಇದು ಹೆಡರ್, ಡೇಟಾ ಮತ್ತು ಹುಸಿ ಹೆಡರ್‌ನ ಚೆಕ್‌ಸಮ್ ಅನ್ನು ಒಳಗೊಂಡಿದೆ. ಲೆಕ್ಕಾಚಾರಗಳನ್ನು ನಿರ್ವಹಿಸುವಾಗ, ಚೆಕ್‌ಸಮ್ ಕ್ಷೇತ್ರವನ್ನು ಶೂನ್ಯಕ್ಕೆ ಹೊಂದಿಸಲಾಗಿದೆ ಮತ್ತು ಅದರ ಉದ್ದವು ಬೆಸ ಸಂಖ್ಯೆಯಾಗಿದ್ದರೆ ಡೇಟಾ ಕ್ಷೇತ್ರವನ್ನು ಶೂನ್ಯ ಬೈಟ್‌ನೊಂದಿಗೆ ಪ್ಯಾಡ್ ಮಾಡಲಾಗುತ್ತದೆ. ಚೆಕ್ಸಮ್ ಅಲ್ಗಾರಿದಮ್ ಎಲ್ಲಾ 16-ಬಿಟ್ ಪದಗಳನ್ನು ಎರಡು ಪೂರಕಗಳಲ್ಲಿ ಸೇರಿಸುತ್ತದೆ ಮತ್ತು ನಂತರ ಸಂಪೂರ್ಣ ಮೊತ್ತದ ಪೂರಕವನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತದೆ. ಪರಿಣಾಮವಾಗಿ, ಸ್ವೀಕರಿಸುವವರು ಚೆಕ್ಸಮ್ ಕ್ಷೇತ್ರವನ್ನು ಒಳಗೊಂಡಂತೆ ಸಂಪೂರ್ಣ ವಿಭಾಗವನ್ನು ಪರಿಶೀಲಿಸಿದಾಗ, ಫಲಿತಾಂಶವು 0 ಆಗಿರಬೇಕು.

ಹುಸಿ-ಹೆಡರ್ 32-ಬಿಟ್ ಮೂಲ ಮತ್ತು ಗಮ್ಯಸ್ಥಾನದ IP ವಿಳಾಸಗಳು, TCP (6) ಗಾಗಿ ಪ್ರೋಟೋಕಾಲ್ ಸಂಖ್ಯೆ ಮತ್ತು TCP ವಿಭಾಗಕ್ಕೆ ಬೈಟ್ ಎಣಿಕೆ (ಹೆಡರ್ ಸೇರಿದಂತೆ) ಒಳಗೊಂಡಿದೆ. TCP ಚೆಕ್‌ಸಮ್‌ನಲ್ಲಿ ಹುಸಿ-ಹೆಡರ್ ಅನ್ನು ಸೇರಿಸುವುದು ತಪ್ಪಾಗಿ ವಿತರಿಸಲಾದ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ, ಆದರೂ ಇದು ಪ್ರೋಟೋಕಾಲ್ ಕ್ರಮಾನುಗತವನ್ನು ಮುರಿಯುತ್ತದೆ ಏಕೆಂದರೆ ಅದರಲ್ಲಿರುವ IP ವಿಳಾಸಗಳು IP ಲೇಯರ್‌ಗೆ ಸೇರಿರುತ್ತವೆ, TCP ಲೇಯರ್ ಅಲ್ಲ. UDP ಚೆಕ್‌ಸಮ್‌ಗಾಗಿ ಅದೇ ಹುಸಿ-ಹೆಡರ್ ಅನ್ನು ಬಳಸುತ್ತದೆ.

ಐಚ್ಛಿಕ ಕ್ಷೇತ್ರಗಳ ಕ್ಷೇತ್ರವು ಪ್ರಮಾಣಿತ ಶಿರೋಲೇಖದಿಂದ ಒಳಗೊಂಡಿರದ ಹೆಚ್ಚುವರಿ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ. ಈ ಕ್ಷೇತ್ರಗಳಲ್ಲಿ ಒಂದನ್ನು ಬಳಸಿಕೊಂಡು, ಪ್ರತಿ ಹೋಸ್ಟ್ ಸ್ವೀಕರಿಸಬಹುದಾದ ಗರಿಷ್ಠ ಪೇಲೋಡ್ ಕ್ಷೇತ್ರ ಗಾತ್ರವನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಬಹುದು. ಬಳಸಿದ ವಿಭಾಗಗಳ ಗಾತ್ರವು ದೊಡ್ಡದಾಗಿದೆ, ದಕ್ಷತೆಯು ಹೆಚ್ಚಾಗುತ್ತದೆ ಏಕೆಂದರೆ ಇದು 20-ಬೈಟ್ ಹೆಡರ್‌ಗಳ ಓವರ್‌ಹೆಡ್ ಅನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ, ಆದರೆ ಎಲ್ಲಾ ಹೋಸ್ಟ್‌ಗಳು ದೊಡ್ಡ ವಿಭಾಗಗಳನ್ನು ಸ್ವೀಕರಿಸುವುದಿಲ್ಲ. ಕನೆಕ್ಷನ್ ಸೆಟಪ್ ಸಮಯದಲ್ಲಿ ಹೋಸ್ಟ್‌ಗಳು ಪರಸ್ಪರ ಗರಿಷ್ಠ ಪೇಲೋಡ್ ಫೀಲ್ಡ್ ಗಾತ್ರವನ್ನು ಸಂವಹಿಸಬಹುದು. ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಈ ಗಾತ್ರವು 536 ಬೈಟ್‌ಗಳು. ಎಲ್ಲಾ ಹೋಸ್ಟ್‌ಗಳು 536 + 20 = 556 ಬೈಟ್‌ಗಳ TCP ವಿಭಾಗಗಳನ್ನು ಸ್ವೀಕರಿಸುವ ಅಗತ್ಯವಿದೆ. ಪ್ರತಿಯೊಂದು ದಿಕ್ಕು ತನ್ನದೇ ಆದ ಗರಿಷ್ಠ ಪೇಲೋಡ್ ಕ್ಷೇತ್ರ ಗಾತ್ರವನ್ನು ಹೊಂದಬಹುದು.

ಹೆಚ್ಚಿನ ವರ್ಗಾವಣೆ ದರಗಳು ಮತ್ತು/ಅಥವಾ ಹೆಚ್ಚಿನ ಲೇಟೆನ್ಸಿ ಹೊಂದಿರುವ ಸಾಲುಗಳಿಗಾಗಿ, 64 KB ವಿಂಡೋ ತುಂಬಾ ಚಿಕ್ಕದಾಗಿದೆ. ಹೀಗಾಗಿ, TZ ಲೈನ್‌ಗೆ (44.736 Mbit/s), ಪೂರ್ಣ ವಿಂಡೋವನ್ನು ಕೇವಲ 12 ms ನಲ್ಲಿ ಸಾಲಿಗೆ ರವಾನಿಸಬಹುದು. ರೌಂಡ್ ಟ್ರಿಪ್ ಸಮಯವು 50 ms ಆಗಿದ್ದರೆ (ಟ್ರಾನ್ಸ್ಕಾಂಟಿನೆಂಟಲ್ ಆಪ್ಟಿಕಲ್ ಕೇಬಲ್‌ಗೆ ವಿಶಿಷ್ಟವಾಗಿದೆ), ಕಳುಹಿಸುವವರು ಸ್ವೀಕೃತಿಗಾಗಿ ಕಾಯುವ ಸಮಯದ 3/4 ಅನ್ನು ಕಳೆಯುತ್ತಾರೆ. ಉಪಗ್ರಹದ ಮೂಲಕ ಸಂವಹನ ಮಾಡುವಾಗ, ಪರಿಸ್ಥಿತಿ ಇನ್ನೂ ಕೆಟ್ಟದಾಗಿರುತ್ತದೆ. ಒಂದು ದೊಡ್ಡ ವಿಂಡೋ ಗಾತ್ರವು ದಕ್ಷತೆಯನ್ನು ಸುಧಾರಿಸುತ್ತದೆ, ಆದರೆ 16-ಬಿಟ್ ವಿಂಡೋ ಗಾತ್ರ ಕ್ಷೇತ್ರವು ಇದನ್ನು ಅನುಮತಿಸುವುದಿಲ್ಲ. RFC 1323 ಹೊಸ ವಿಂಡೋ ಸ್ಕೇಲ್ ಪ್ಯಾರಾಮೀಟರ್ ಅನ್ನು ಪ್ರಸ್ತಾಪಿಸಿತು, ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸುವಾಗ ಅದರ ಮೌಲ್ಯವನ್ನು ಎರಡು ಹೋಸ್ಟ್‌ಗಳು ಒಪ್ಪಿಕೊಳ್ಳಬಹುದು. ಈ ಸಂಖ್ಯೆಯು ವಿಂಡೋ ಗಾತ್ರ ಕ್ಷೇತ್ರವನ್ನು ಎಡಕ್ಕೆ 14 ಬಿಟ್‌ಗಳವರೆಗೆ ಬದಲಾಯಿಸಲು ಅನುಮತಿಸುತ್ತದೆ, ಇದು ವಿಂಡೋ ಗಾತ್ರವನ್ನು 230 ಬೈಟ್‌ಗಳಿಗೆ (1 GB) ವಿಸ್ತರಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. ಪ್ರಸ್ತುತ, ಹೆಚ್ಚಿನ TCP ಪ್ರೋಟೋಕಾಲ್ ಅನುಷ್ಠಾನಗಳು ಈ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಬೆಂಬಲಿಸುತ್ತವೆ.

RFC 1106 ರಲ್ಲಿ ಪ್ರಸ್ತಾಪಿಸಲಾದ ಮತ್ತು ಈಗ ವ್ಯಾಪಕವಾಗಿ ಬಳಸಲಾಗುವ ಮತ್ತೊಂದು ಆಯ್ಕೆಯು ಬ್ಯಾಕ್‌ಟ್ರ್ಯಾಕಿಂಗ್ ಬದಲಿಗೆ ಆಯ್ದ ಮರುಪ್ರಯತ್ನದ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಬಳಸುವುದು, ಗಮ್ಯಸ್ಥಾನವು ಒಂದು ದೊಡ್ಡ ಸಂಖ್ಯೆಯ ಉತ್ತಮ ವಿಭಾಗಗಳನ್ನು ಪಡೆದರೆ, ಸಾಮಾನ್ಯ TCP ಪ್ರೋಟೋಕಾಲ್ ಅಂತಿಮವಾಗಿ ಸಮಯ ಮೀರುತ್ತದೆ. ಸರಿಯಾಗಿ ಸ್ವೀಕರಿಸಿದ ವಿಭಾಗಗಳನ್ನು ಒಳಗೊಂಡಂತೆ ಎಲ್ಲಾ ಅಂಗೀಕರಿಸದ ವಿಭಾಗಗಳನ್ನು ಮರುಪ್ರಸಾರ ಮಾಡಿ. RFC 1106 ಋಣಾತ್ಮಕ ಸ್ವೀಕೃತಿಗಳ (NAK) ಬಳಕೆಯನ್ನು ಪ್ರಸ್ತಾಪಿಸಿತು, ಸ್ವೀಕರಿಸುವವರಿಗೆ ಒಂದೇ ವಿಭಾಗ ಅಥವಾ ಬಹು ವಿಭಾಗಗಳನ್ನು ವಿನಂತಿಸಲು ಅವಕಾಶ ನೀಡುತ್ತದೆ. ಒಮ್ಮೆ ಸ್ವೀಕರಿಸಿದ ನಂತರ, ಸ್ವೀಕರಿಸುವ ಪಕ್ಷವು ಬಫರ್‌ನಲ್ಲಿ ಸಂಗ್ರಹವಾಗಿರುವ ಎಲ್ಲಾ ಡೇಟಾವನ್ನು ಅಂಗೀಕರಿಸಬಹುದು, ಹೀಗಾಗಿ ಮರುಪ್ರಸಾರಿಸಿದ ಡೇಟಾದ ಪ್ರಮಾಣವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.

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

ಹಲೋ, ನನ್ನ ಹೆಸರು ಗ್ಲೆನ್ ಫೀಡ್ಲರ್ ಮತ್ತು ನನ್ನ ಆನ್‌ಲೈನ್ ಪುಸ್ತಕ, ಗೇಮ್ ಡೆವಲಪರ್‌ಗಳಿಗಾಗಿ ನೆಟ್‌ವರ್ಕ್ ಪ್ರೋಗ್ರಾಮಿಂಗ್‌ನಲ್ಲಿನ ಮೊದಲ ಲೇಖನಕ್ಕೆ ನಾನು ನಿಮ್ಮನ್ನು ಸ್ವಾಗತಿಸುತ್ತೇನೆ.

ಈ ಲೇಖನದಲ್ಲಿ, ನಾವು ನೆಟ್‌ವರ್ಕ್ ಪ್ರೋಗ್ರಾಮಿಂಗ್‌ನ ಮೂಲಭೂತ ಅಂಶಗಳೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ - ನೆಟ್‌ವರ್ಕ್ ಮೂಲಕ ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸುವುದು ಮತ್ತು ರವಾನಿಸುವುದು. ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸುವುದು ಮತ್ತು ರವಾನಿಸುವುದು ನೆಟ್‌ವರ್ಕ್ ಪ್ರೋಗ್ರಾಮರ್‌ಗಳು ಮಾಡುವ ಸಂಪೂರ್ಣ ಶ್ರೇಣಿಯ ಕಾರ್ಯಗಳ ಅತ್ಯಂತ ಮೂಲಭೂತ ಮತ್ತು ಸರಳವಾದ ಭಾಗವಾಗಿದೆ, ಆದರೆ ಯಾವ ರೀತಿಯಲ್ಲಿ ಮುಂದುವರಿಯುವುದು ಉತ್ತಮ ಎಂದು ನಿರ್ಧರಿಸಲು ಕಷ್ಟವಾಗುತ್ತದೆ. ಈ ಭಾಗಕ್ಕೆ ಸಾಕಷ್ಟು ಗಮನ ಕೊಡಿ - ನೀವು ತಪ್ಪು ತಿಳುವಳಿಕೆಯನ್ನು ಬಿಟ್ಟರೆ, ಅದು ನಂತರ ನಿಮ್ಮ ಮಲ್ಟಿಪ್ಲೇಯರ್ ಆಟಕ್ಕೆ ಭೀಕರ ಪರಿಣಾಮಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು!

ಸಾಕೆಟ್‌ಗಳ ಬಗ್ಗೆ ನೀವು ಈಗಾಗಲೇ ಏನನ್ನಾದರೂ ಕೇಳಿರಬಹುದು ಮತ್ತು ಅವುಗಳು ಎರಡು ಮುಖ್ಯ ವಿಧಗಳಲ್ಲಿ ಬರುತ್ತವೆ ಎಂದು ನಿಮಗೆ ತಿಳಿದಿರಬಹುದು - TCP ಮತ್ತು UDP. ಮಲ್ಟಿಪ್ಲೇಯರ್ ಆಟವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವಾಗ ನೀವು ನಿರ್ಧರಿಸಬೇಕಾದ ಮೊದಲ ವಿಷಯವೆಂದರೆ ಯಾವ ರೀತಿಯ ಸಾಕೆಟ್‌ಗಳನ್ನು ಬಳಸಬೇಕು - TCP, UDP, ಅಥವಾ ಎರಡೂ?

ಸಾಕೆಟ್ ಪ್ರಕಾರದ ಆಯ್ಕೆಯು ನೀವು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತಿರುವ ಆಟದ ಪ್ರಕಾರವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಅವಲಂಬಿಸಿರುತ್ತದೆ. ಈ ಲೇಖನಗಳ ಸರಣಿಯಲ್ಲಿ, ನೀವು ಆಕ್ಷನ್ ಆಟವನ್ನು ಬರೆಯುತ್ತಿದ್ದೀರಿ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ - ಹ್ಯಾಲೊ, ಯುದ್ಧಭೂಮಿ 1942, ಕ್ವೇಕ್, ಅನ್ರಿಯಲ್, ಕೌಂಟರ್‌ಸ್ಟ್ರೈಕ್, ಟೀಮ್ ಫೋರ್ಟ್ರೆಸ್, ಇತ್ಯಾದಿ.

ಈಗ ನಾವು ಪ್ರತಿಯೊಂದು ರೀತಿಯ ಸಾಕೆಟ್‌ಗಳ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಹತ್ತಿರದಿಂದ ನೋಡುತ್ತೇವೆ (ನಾವು ಆಕ್ಷನ್-ಶೈಲಿಯ ಆಟವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತಿದ್ದೇವೆ ಎಂಬ ಅಂಶವನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಂಡು), ಮತ್ತು ಇಂಟರ್ನೆಟ್ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದರ ವಿವರಗಳಿಗೆ ಸ್ವಲ್ಪ ಆಳವಾಗಿ ಹೋಗುತ್ತೇವೆ. ವಿವರವಾದ ವಿಮರ್ಶೆಯ ನಂತರ, ಸರಿಯಾದ ಆಯ್ಕೆಯು ಸ್ಪಷ್ಟವಾಗುತ್ತದೆ!

TCP ಎಂದರೆ "ಟ್ರಾನ್ಸ್ಮಿಷನ್ ಕಂಟ್ರೋಲ್ ಪ್ರೋಟೋಕಾಲ್" ಮತ್ತು IP ಎಂದರೆ "ಇಂಟರ್ನೆಟ್ ಪ್ರೋಟೋಕಾಲ್". ವೆಬ್ ಬ್ರೌಸಿಂಗ್‌ನಿಂದ ಹಿಡಿದು IRC ಮತ್ತು ಇಮೇಲ್ ಸಂವಹನಗಳವರೆಗೆ ನೀವು ಆನ್‌ಲೈನ್‌ನಲ್ಲಿ ಮಾಡುವ ಬಹುತೇಕ ಎಲ್ಲವನ್ನೂ ಅವರು ಒಟ್ಟಾಗಿ ಬೆಂಬಲಿಸುತ್ತಾರೆ - ಎಲ್ಲವೂ TCP/IP ನಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿದೆ.

ನೀವು ಎಂದಾದರೂ TCP ಸಾಕೆಟ್‌ಗಳನ್ನು ಬಳಸಿದ್ದರೆ, TCP ಒಂದು ವಿಶ್ವಾಸಾರ್ಹ ಸಂಪರ್ಕದ ತತ್ವವನ್ನು ಬಳಸುವ ಪ್ರೋಟೋಕಾಲ್ ಎಂದು ನೀವು ತಿಳಿದಿರಬೇಕು. ಇದರರ್ಥ ನೀವು ಎರಡು ಕಂಪ್ಯೂಟರ್‌ಗಳ ನಡುವೆ ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸಿ, ನಂತರ ಅವುಗಳ ನಡುವೆ ಡೇಟಾವನ್ನು ಕಳುಹಿಸುತ್ತೀರಿ, ನೀವು ಒಂದು ಕಂಪ್ಯೂಟರ್‌ನಲ್ಲಿನ ಫೈಲ್‌ಗೆ ಮಾಹಿತಿಯನ್ನು ಬರೆಯುತ್ತಿದ್ದಂತೆ ಮತ್ತು ಅದೇ ಫೈಲ್‌ನಿಂದ ಇನ್ನೊಂದು ಫೈಲ್‌ನಿಂದ ಓದುತ್ತಿರುವಂತೆ.

ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಸಂಪರ್ಕವನ್ನು ವಿಶ್ವಾಸಾರ್ಹ ಮತ್ತು ಸ್ಥಿರವೆಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ - ಅಂದರೆ, ನೀವು ಕಳುಹಿಸುವ ಎಲ್ಲಾ ಮಾಹಿತಿಯು ಅದನ್ನು ಕಳುಹಿಸಿದ ಅದೇ ಕ್ರಮದಲ್ಲಿ ಸ್ವೀಕರಿಸುವವರನ್ನು ತಲುಪಲು ಖಾತರಿಪಡಿಸುತ್ತದೆ. ಅಲ್ಲದೆ, ಟಿಸಿಪಿ ಸಂಪರ್ಕವನ್ನು ಡೇಟಾದ ನಿರಂತರ ಸ್ಟ್ರೀಮ್ ಎಂದು ಪರಿಗಣಿಸಬಹುದು - ಪ್ರೋಟೋಕಾಲ್ ಸ್ವತಃ ಡೇಟಾವನ್ನು ಪ್ಯಾಕೆಟ್‌ಗಳಾಗಿ ಒಡೆಯುವ ಮತ್ತು ನೆಟ್‌ವರ್ಕ್ ಮೂಲಕ ಕಳುಹಿಸುವುದನ್ನು ನೋಡಿಕೊಳ್ಳುತ್ತದೆ.

ಮತ್ತೊಮ್ಮೆ - ಎಲ್ಲವೂ ಸಾಮಾನ್ಯ ಬರವಣಿಗೆ ಅಥವಾ ಫೈಲ್‌ನಿಂದ ಓದುವಷ್ಟು ಸರಳವಾಗಿದೆ. ಎಲಿಮೆಂಟರಿ ವ್ಯಾಟ್ಸನ್!

ಆದರೆ ಈ ಬಳಕೆಯ ಸುಲಭತೆಯು "ಹುಡ್ ಅಡಿಯಲ್ಲಿ" ನಿಜವಾಗಿ ಏನಾಗುತ್ತದೆ ಎನ್ನುವುದಕ್ಕಿಂತ ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನವಾಗಿದೆ, ಕಡಿಮೆ ಮಟ್ಟದಲ್ಲಿ - IP ಪ್ರೋಟೋಕಾಲ್ ಮಟ್ಟ.

ಈ ಹಂತದಲ್ಲಿ ಸಂಪರ್ಕದ ಪರಿಕಲ್ಪನೆ ಇಲ್ಲ - ಬದಲಿಗೆ ಪ್ರತ್ಯೇಕ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಒಂದು ಕಂಪ್ಯೂಟರ್ನಿಂದ ಇನ್ನೊಂದಕ್ಕೆ ರವಾನಿಸಲಾಗುತ್ತದೆ. ಜನರು ತುಂಬಿದ ಕೋಣೆಯಲ್ಲಿ ಒಬ್ಬ ವ್ಯಕ್ತಿಯಿಂದ ಇನ್ನೊಬ್ಬರಿಗೆ ಟಿಪ್ಪಣಿಯನ್ನು ರವಾನಿಸುವಂತೆ ನೀವು ಈ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಯೋಚಿಸಬಹುದು: ಕೊನೆಯಲ್ಲಿ ಟಿಪ್ಪಣಿ ಸರಿಯಾದ ವ್ಯಕ್ತಿಗೆ ಸಿಗುತ್ತದೆ, ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ ಅನೇಕ ಕೈಗಳ ಮೂಲಕ ಹಾದುಹೋಗುತ್ತದೆ.

ಆದಾಗ್ಯೂ, ಟಿಪ್ಪಣಿ ವಿಳಾಸದಾರರಿಗೆ ತಲುಪುತ್ತದೆ ಎಂಬುದಕ್ಕೆ ಯಾವುದೇ ಗ್ಯಾರಂಟಿ ಇಲ್ಲ. ಕಳುಹಿಸುವವರು ಬರುತ್ತಾರೆ ಎಂಬ ಭರವಸೆಯಲ್ಲಿ ಟಿಪ್ಪಣಿಯನ್ನು ಕಳುಹಿಸುತ್ತಾರೆ, ಆದರೆ ಸಂದೇಶವು ಬಂದಿದೆಯೋ ಇಲ್ಲವೋ ಎಂದು ಸಹ ತಿಳಿದಿಲ್ಲ - ಸ್ವೀಕರಿಸುವವರು ಮತ್ತೆ ಬರೆಯಲು ನಿರ್ಧರಿಸುವವರೆಗೆ.
ಸ್ವಾಭಾವಿಕವಾಗಿ, ವಾಸ್ತವದಲ್ಲಿ ಎಲ್ಲವೂ ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಜಟಿಲವಾಗಿದೆ, ಏಕೆಂದರೆ ಕಳುಹಿಸುವ ಕಂಪ್ಯೂಟರ್‌ಗೆ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಕಂಪ್ಯೂಟರ್‌ಗಳ ನಿಖರವಾದ ಅನುಕ್ರಮ ತಿಳಿದಿಲ್ಲ, ಅದರ ಮೂಲಕ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ರವಾನಿಸಬೇಕು ಇದರಿಂದ ಅದು ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ಬರುತ್ತದೆ. ಕೆಲವೊಮ್ಮೆ IP ಒಂದೇ ಪ್ಯಾಕೆಟ್‌ನ ಬಹು ಪ್ರತಿಗಳನ್ನು ರವಾನಿಸುತ್ತದೆ, ಇದು ಗಮ್ಯಸ್ಥಾನವನ್ನು ತಲುಪಲು ವಿಭಿನ್ನ ಮಾರ್ಗಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು - ಮತ್ತು ವಿಭಿನ್ನ ಸಮಯಗಳಲ್ಲಿ ಬರುವ ಸಾಧ್ಯತೆಯಿದೆ.

ನಾವು ಕಂಪ್ಯೂಟರ್‌ಗಳ ನಡುವೆ ಮಾಹಿತಿಯನ್ನು ಫೈಲ್ ಓದುವ/ಬರೆಯುವ ಶೈಲಿಯಲ್ಲಿ ವರ್ಗಾಯಿಸಲು ಬಯಸಿದರೆ, ಆದರೆ ವೈಯಕ್ತಿಕ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ನೇರವಾಗಿ ಕಳುಹಿಸುವ ಮತ್ತು ಸ್ವೀಕರಿಸುವ ಮೂಲಕ?

ಸರಿ, ನಾವು ಇದನ್ನು UDP ಬಳಸಿ ಮಾಡಬಹುದು. ಯುಡಿಪಿ ಎಂದರೆ "ಬಳಕೆದಾರ ಡೇಟಾಗ್ರಾಮ್ ಪ್ರೋಟೋಕಾಲ್" ಮತ್ತು ಇದು ಐಪಿ (ಟಿಸಿಪಿ ನಂತಹ) ಮೇಲೆ ಚಲಿಸುತ್ತದೆ, ಆದರೆ ಒಂದು ಟನ್ ಕಾರ್ಯವನ್ನು ಸೇರಿಸುವ ಬದಲು ಇದು ಐಪಿಗೆ ಕೇವಲ ಒಂದು ಸಣ್ಣ ಆಡ್-ಆನ್ ಆಗಿದೆ.

UDP ಅನ್ನು ಬಳಸಿಕೊಂಡು, ನಾವು ನಿರ್ದಿಷ್ಟ IP ವಿಳಾಸ (ಉದಾಹರಣೆಗೆ, 112.140.20.10) ಮತ್ತು ಪೋರ್ಟ್ (ಉದಾಹರಣೆಗೆ, 52423) ಗೆ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಕಳುಹಿಸಬಹುದು ಮತ್ತು ಅದು ತನ್ನ ಗಮ್ಯಸ್ಥಾನವನ್ನು ತಲುಪುವವರೆಗೆ (ಅಥವಾ ಕಳೆದುಹೋಗುವವರೆಗೆ) ಅದನ್ನು ಕಂಪ್ಯೂಟರ್‌ನಿಂದ ಕಂಪ್ಯೂಟರ್‌ಗೆ ರವಾನಿಸಲಾಗುತ್ತದೆ. ದಾರಿ).

ಅದೇ ಸಮಯದಲ್ಲಿ, ರಿಸೀವರ್ ಬದಿಯಲ್ಲಿ ನಾವು ಕುಳಿತು ಕಾಯುತ್ತೇವೆ, ನಿರ್ದಿಷ್ಟ ಪೋರ್ಟ್ ಅನ್ನು ಕೇಳುತ್ತೇವೆ (ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ 52423), ಮತ್ತು ಯಾರೊಬ್ಬರಿಂದ ಪ್ಯಾಕೆಟ್ ಬಂದಾಗ (ಯಾವುದೇ ಸಂಪರ್ಕಗಳನ್ನು ಬಳಸಲಾಗುವುದಿಲ್ಲ ಎಂದು ನೆನಪಿಡಿ), ಇದರೊಂದಿಗೆ ನಾವು ಅಧಿಸೂಚನೆಯನ್ನು ಸ್ವೀಕರಿಸುತ್ತೇವೆ ಕಳುಹಿಸುವ ಕಂಪ್ಯೂಟರ್‌ನ ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್, ಪ್ಯಾಕೆಟ್ ಗಾತ್ರ, ಮತ್ತು ಅದರ ನಂತರ ನಾವು ಈ ಪ್ಯಾಕೆಟ್‌ನಿಂದ ಡೇಟಾವನ್ನು ಓದಬಹುದು.

UDP ಪ್ರೋಟೋಕಾಲ್ ಡೇಟಾ ವಿತರಣೆಯನ್ನು ಖಾತರಿಪಡಿಸುವುದಿಲ್ಲ. ಪ್ರಾಯೋಗಿಕವಾಗಿ, ಹೆಚ್ಚಿನ ಪ್ಯಾಕೆಟ್‌ಗಳು ಸಹಜವಾಗಿ ಬರುತ್ತವೆ, ಆದರೆ ಯಾವಾಗಲೂ ಸುಮಾರು 1-5% ನಷ್ಟು ನಷ್ಟವಾಗುತ್ತದೆ, ಮತ್ತು ಕೆಲವೊಮ್ಮೆ ಪ್ಯಾಕೆಟ್‌ಗಳು ಬರದ ಅವಧಿಗಳಿವೆ (ಕಳುಹಿಸುವವರು ಮತ್ತು ಸ್ವೀಕರಿಸುವವರ ನಡುವೆ ಇರಬಹುದು ಎಂಬುದನ್ನು ನೆನಪಿಡಿ ಸಾವಿರಾರು ಕಂಪ್ಯೂಟರ್‌ಗಳಾಗಿರಬಹುದು, ಅವುಗಳಲ್ಲಿ ಯಾವುದಾದರೂ ಅದು ವಿಫಲವಾಗಬಹುದು ಅಥವಾ ಒಡೆಯಬಹುದು).

ಅಲ್ಲದೆ, ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ವಿತರಿಸುವ ಕ್ರಮವನ್ನು UDP ಖಾತರಿಪಡಿಸುವುದಿಲ್ಲ. ನೀವು ಐದು ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಕ್ರಮವಾಗಿ ಕಳುಹಿಸಬಹುದು - 1, 2, 3, 4, 5 - ಆದರೆ ಅವು ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನ ಕ್ರಮದಲ್ಲಿ ಬರಬಹುದು - ಉದಾಹರಣೆಗೆ, 3, 1, 2, 5, 4. ಮತ್ತೆ, ಪ್ರಾಯೋಗಿಕವಾಗಿ, ಅವು ಹೆಚ್ಚಾಗಿ ಹೆಚ್ಚಿನ ಸಮಯ ಸರಿಯಾದ ಕ್ರಮದಲ್ಲಿ ಬರುತ್ತದೆ, ಆದರೆ ನೀವು ಅದನ್ನು ಅವಲಂಬಿಸಲಾಗುವುದಿಲ್ಲ!

ಅಂತಿಮವಾಗಿ, ಯುಡಿಪಿ ಐಪಿಗೆ ಹೆಚ್ಚಿನದನ್ನು ಸೇರಿಸದಿದ್ದರೂ, ಇದು ಒಂದು ವಿಷಯವನ್ನು ಖಾತರಿಪಡಿಸುತ್ತದೆ. ನೀವು ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡಿದರೆ, ಅದು ಸಂಪೂರ್ಣವಾಗಿ ಬರುತ್ತದೆ ಅಥವಾ ಇಲ್ಲ. ಆದ್ದರಿಂದ, ನೀವು ಇನ್ನೊಂದು ಕಂಪ್ಯೂಟರ್‌ಗೆ 256 ಬೈಟ್ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಕಳುಹಿಸಿದರೆ, ಅದು ಪ್ಯಾಕೆಟ್‌ನಿಂದ ಮೊದಲ 100 ಬೈಟ್‌ಗಳನ್ನು ಮಾತ್ರ ಸ್ವೀಕರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ - ಅದು ಎಲ್ಲಾ 256 ಬೈಟ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸಬೇಕು. UDP ಪ್ರೋಟೋಕಾಲ್ ಖಾತರಿಪಡಿಸುವ ಏಕೈಕ ವಿಷಯ ಇದು - ಉಳಿದಂತೆ ನಿಮ್ಮ ಹೆಗಲ ಮೇಲೆ ಬೀಳುತ್ತದೆ.

ಆದ್ದರಿಂದ ನಾವು ನಿರ್ಧರಿಸಬೇಕಾಗಿದೆ - ನಾವು TCP ಅಥವಾ UDP ಸಾಕೆಟ್‌ಗಳನ್ನು ಬಳಸಬೇಕೇ? ಅವರ ಗುಣಲಕ್ಷಣಗಳನ್ನು ನೋಡೋಣ:

• ಸಂಪರ್ಕ ತತ್ವವನ್ನು ಬಳಸುತ್ತದೆ
• ವಿತರಣೆ ಮತ್ತು ಟರ್ನ್ಅರೌಂಡ್ ಅನ್ನು ಖಾತರಿಪಡಿಸುತ್ತದೆ
• ಮಾಹಿತಿಯನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಪ್ಯಾಕೆಟ್‌ಗಳಾಗಿ ವಿಭಜಿಸುತ್ತದೆ
• ಡೇಟಾವನ್ನು ತುಂಬಾ ತೀವ್ರವಾಗಿ ಕಳುಹಿಸಲಾಗಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ (ಡೇಟಾ ಹರಿವಿನ ನಿಯಂತ್ರಣ)
• ಬಳಸಲು ಸುಲಭ - ಫೈಲ್‌ನಿಂದ ಬರೆಯುವುದು/ಓದುವುದು

UDP:

• ಸಂಪರ್ಕ ತತ್ವವನ್ನು ಬಳಸುವುದಿಲ್ಲ - ನೀವು ಅದನ್ನು ಕೈಯಾರೆ ಕಾರ್ಯಗತಗೊಳಿಸಬೇಕಾಗುತ್ತದೆ
• ಪ್ಯಾಕೇಜ್‌ಗಳ ವಿತರಣೆ ಮತ್ತು ವಿತರಣೆಯ ಆದೇಶವನ್ನು ಖಾತರಿಪಡಿಸುವುದಿಲ್ಲ - ಅವರು ತಪ್ಪಾದ ಕ್ರಮದಲ್ಲಿ, ನಕಲುಗಳೊಂದಿಗೆ ಬರಬಹುದು ಅಥವಾ ಬರದೇ ಇರಬಹುದು!
• ನೀವು ಡೇಟಾವನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಪ್ಯಾಕೆಟ್‌ಗಳಾಗಿ ವಿಭಜಿಸಬೇಕು ಮತ್ತು ಅವುಗಳನ್ನು ಕಳುಹಿಸಬೇಕು
• ಡೇಟಾವನ್ನು ತುಂಬಾ ತೀವ್ರವಾಗಿ ಕಳುಹಿಸದಂತೆ ನೀವು ಜಾಗರೂಕರಾಗಿರಬೇಕು
• ಪ್ಯಾಕೆಟ್ ಕಳೆದುಹೋದರೆ, ನೀವು ಅದನ್ನು ಹೇಗಾದರೂ ಟ್ರ್ಯಾಕ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ ಮತ್ತು ಅಗತ್ಯವಿದ್ದರೆ, ಅದನ್ನು ಮರುಕಳುಹಿಸಿ

ಅಂತಹ ಪಟ್ಟಿಯೊಂದಿಗೆ, ಪರಿಹಾರವು ಸ್ಪಷ್ಟವಾಗಿ ತೋರುತ್ತದೆ - TCP ನಮಗೆ ಅಗತ್ಯವಿರುವ ಎಲ್ಲಾ ಕಾರ್ಯಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಬಳಸಲು ಸುಲಭವಾಗಿದೆ, UDP ಅನ್ನು ಬಳಸುವಾಗ ಮೊದಲಿನಿಂದಲೂ ಎಲ್ಲವನ್ನೂ ಕೈಯಾರೆ ಬರೆಯುವ ಮೂಲಕ ಮೂಲವ್ಯಾಧಿಗೆ ಭರವಸೆ ನೀಡುತ್ತದೆ. ಆದ್ದರಿಂದ ನಾವು TCP ಅನ್ನು ಬಳಸುತ್ತೇವೆ, ಸರಿ?

ಆದರೆ ಇಲ್ಲ.

ಮಲ್ಟಿಪ್ಲೇಯರ್ ಆಟವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವಾಗ TCP ಅನ್ನು ಬಳಸುವುದು ಬಹುಶಃ ನೀವು ಮಾಡಬಹುದಾದ ಕೆಟ್ಟ ತಪ್ಪು. ಏಕೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, TCP ಅನ್ನು ಬಳಸಲು ತುಂಬಾ ಸುಲಭವಾಗುವಂತೆ ಮಾಡುವುದನ್ನು ನೋಡೋಣ!

TCP ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ

ಟಿಸಿಪಿ ಮತ್ತು ಯುಡಿಪಿ ಎರಡೂ ಐಪಿಯ ಮೇಲೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ, ಆದರೆ ವಾಸ್ತವದಲ್ಲಿ ಅವು ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನವಾಗಿವೆ. UDP IP ಯಂತೆಯೇ ವರ್ತಿಸುತ್ತದೆ, ಆದರೆ TCP ಬಳಕೆದಾರರನ್ನು ಎಲ್ಲಾ ಪ್ಯಾಕೆಟ್ ಸಮಸ್ಯೆಗಳಿಂದ ದೂರವಿಡುತ್ತದೆ, ಪರಸ್ಪರ ಕ್ರಿಯೆಯನ್ನು ಫೈಲ್ ಅನ್ನು ಓದುವುದು/ಬರೆಯುವಂತೆ ಮಾಡುತ್ತದೆ.

ಹಾಗಾದರೆ ಅವನು ಅದನ್ನು ಹೇಗೆ ಮಾಡುತ್ತಾನೆ?

ಮೊದಲಿಗೆ, TCP ಡೇಟಾ ಸ್ಟ್ರೀಮ್ ಅಮೂರ್ತತೆಯನ್ನು ಬಳಸುತ್ತದೆ - ನೀವು ಆ ಸ್ಟ್ರೀಮ್‌ಗೆ ಡೇಟಾದ ಬೈಟ್‌ಗಳನ್ನು ಸರಳವಾಗಿ ಬರೆಯಬಹುದು ಮತ್ತು TCP ಅದು ತನ್ನ ಗಮ್ಯಸ್ಥಾನವನ್ನು ತಲುಪುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ. ಏಕೆಂದರೆ IP ಪ್ಯಾಕೆಟ್‌ಗಳಲ್ಲಿ ಡೇಟಾವನ್ನು ರವಾನಿಸುತ್ತದೆ ಮತ್ತು TCP IP ಮೇಲೆ ಚಲಿಸುತ್ತದೆ, TCP ಬಳಕೆದಾರರ ಇನ್‌ಪುಟ್ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಪ್ರತ್ಯೇಕ ಪ್ಯಾಕೆಟ್‌ಗಳಾಗಿ ಒಡೆಯಬೇಕು. ಆದ್ದರಿಂದ, TCP ಒಳಗೆ, ಕೆಲವು ತರ್ಕವು ಡೇಟಾವನ್ನು ಸರದಿಯಲ್ಲಿ ಸಂಗ್ರಹಿಸುತ್ತದೆ ಮತ್ತು ಅದರಲ್ಲಿ ಸಾಕಷ್ಟು ಇದ್ದಾಗ, ಅದು ಪ್ಯಾಕೆಟ್ ಅನ್ನು ರೂಪಿಸುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಕಳುಹಿಸುತ್ತದೆ.

ನಾವು ಚಿಕ್ಕ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ವರ್ಗಾಯಿಸಬೇಕಾದರೆ ಈ ನಡವಳಿಕೆಯು ನಮ್ಮ ಮಲ್ಟಿಪ್ಲೇಯರ್ ಆಟಕ್ಕೆ ಸಮಸ್ಯೆಯಾಗಬಹುದು. ಒಂದು ನಿರ್ದಿಷ್ಟ ಗಾತ್ರದ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ರೂಪಿಸಲು ಸಾಕಷ್ಟು ಸಂಗ್ರಹವಾಗುವವರೆಗೆ ನಮ್ಮ ಡೇಟಾವನ್ನು ರವಾನಿಸದಿರಲು TCP ನಿರ್ಧರಿಸುತ್ತದೆ (ಉದಾಹರಣೆಗೆ, ನೂರಕ್ಕೂ ಹೆಚ್ಚು ಬೈಟ್‌ಗಳು). ಮತ್ತು ಇದು ಒಂದು ದೊಡ್ಡ ಸಮಸ್ಯೆಯಾಗಿದೆ, ಏಕೆಂದರೆ ಕ್ಲೈಂಟ್‌ನಿಂದ (ಪ್ಲೇಯರ್ ಕೀಸ್ಟ್ರೋಕ್‌ಗಳು) ಡೇಟಾವನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ಸರ್ವರ್‌ಗೆ ವರ್ಗಾಯಿಸುವುದು ಅವಶ್ಯಕ, ಮತ್ತು ಪ್ರೋಟೋಕಾಲ್‌ನಿಂದ ಡೇಟಾ ಬಫರಿಂಗ್‌ನಿಂದಾಗಿ ವಿಳಂಬಗಳಿದ್ದರೆ, ಕ್ಲೈಂಟ್ ಬದಿಯಲ್ಲಿರುವ ಆಟಗಾರನಿಗೆ ಆಟವು ಆಹ್ಲಾದಕರ ರೀತಿಯಲ್ಲಿ ಹೆಚ್ಚು ಆಗುವುದಿಲ್ಲ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಆಟದ ವಸ್ತುಗಳನ್ನು ನವೀಕರಿಸುವುದು ವಿಳಂಬ ಮತ್ತು ವಿರಳವಾಗಿ ಸಂಭವಿಸುತ್ತದೆ - ಆದರೆ ನಾವು ಸಮಯಕ್ಕೆ ಮತ್ತು ಆಗಾಗ್ಗೆ ವಸ್ತುಗಳನ್ನು ನವೀಕರಿಸಬೇಕಾಗುತ್ತದೆ.

TCP ಇದನ್ನು ಸರಿಪಡಿಸಲು ಒಂದು ಆಯ್ಕೆಯನ್ನು ಹೊಂದಿದೆ - “TCP_NODELAY”. ಕಳುಹಿಸುವ ಸರದಿಯಲ್ಲಿ ಡೇಟಾ ಸಂಗ್ರಹಗೊಳ್ಳಲು ಕಾಯಬೇಡಿ, ಆದರೆ ಅದನ್ನು ತಕ್ಷಣವೇ ಕಳುಹಿಸಲು ಇದು ಪ್ರೋಟೋಕಾಲ್‌ಗೆ ಹೇಳುತ್ತದೆ.

ದುರದೃಷ್ಟವಶಾತ್, ಈ ಆಯ್ಕೆಯನ್ನು ಸ್ಥಾಪಿಸಿದ್ದರೂ ಸಹ, ಆನ್‌ಲೈನ್ ಆಟಗಳಲ್ಲಿ ಬಳಸಿದಾಗ TCP ಬಹಳಷ್ಟು ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿದೆ.

ಎಲ್ಲಾ ಸಮಸ್ಯೆಗಳ ಮೂಲವು TCP ಕಳೆದುಹೋದ ಅಥವಾ ಔಟ್-ಆಫ್-ಆರ್ಡರ್ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸುವ ವಿಧಾನದಲ್ಲಿದೆ, ಇದು ವಿಶ್ವಾಸಾರ್ಹ ಮತ್ತು ಸ್ಥಿರವಾದ ಸಂಪರ್ಕದ ಭ್ರಮೆಯನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ.

ಸಂಪರ್ಕದ ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು TCP ಹೇಗೆ ಖಚಿತಪಡಿಸುತ್ತದೆ

ಪ್ರಸಾರ ಮಾಡುವಾಗ, TCP ಡೇಟಾ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಪ್ರತ್ಯೇಕ ಪ್ಯಾಕೆಟ್‌ಗಳಾಗಿ ಒಡೆಯುತ್ತದೆ, ವಿಶ್ವಾಸಾರ್ಹವಲ್ಲದ IP ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಅವುಗಳನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ನಂತರ ಸ್ವೀಕರಿಸಿದ ಕಂಪ್ಯೂಟರ್ನಲ್ಲಿ ಸ್ವೀಕರಿಸಿದ ಪ್ಯಾಕೆಟ್ಗಳಿಂದ ಮೂಲ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಪುನರ್ನಿರ್ಮಿಸುತ್ತದೆ.

ಆದರೆ ಒಂದು ಪ್ಯಾಕೆಟ್ ಬರದಿದ್ದರೆ ಏನಾಗುತ್ತದೆ? ಅಥವಾ ಪ್ಯಾಕೇಜ್‌ಗಳು ಕ್ರಮಬದ್ಧವಾಗಿಲ್ಲದಿದ್ದರೆ ಅಥವಾ ನಕಲುಗಳೊಂದಿಗೆ ಬಂದರೆ?

TCP ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದರ ವಿವರಗಳನ್ನು ಆಳವಾಗಿ ಪರಿಶೀಲಿಸದೆಯೇ (ಮತ್ತು ಇದು ನಿಜವಾಗಿಯೂ ಬಹಳ ಸಂಕೀರ್ಣವಾದ ವಿಷಯವಾಗಿದೆ - ನೀವು ಅದನ್ನು TCP/IP ಇಲ್ಲಸ್ಟ್ರೇಟೆಡ್‌ನಲ್ಲಿ ಓದಬಹುದು), ಪ್ರಕ್ರಿಯೆಯು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ: TCP ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಕಳುಹಿಸುತ್ತದೆ, ಪ್ಯಾಕೆಟ್ ಬರಲಿಲ್ಲ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ , ಮತ್ತು ಅದೇ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಸ್ವೀಕರಿಸುವವರಿಗೆ ಮರುಕಳುಹಿಸುತ್ತದೆ. ಸ್ವೀಕರಿಸುವವರ ಕಡೆಯಿಂದ ನಕಲಿ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ತೆಗೆದುಹಾಕಲಾಗುತ್ತದೆ ಮತ್ತು ಆದೇಶದಿಂದ ಹೊರಗಿರುವ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಮರುಕ್ರಮಗೊಳಿಸಲಾಗುತ್ತದೆ ಆದ್ದರಿಂದ ಎಲ್ಲವೂ ಇರಬೇಕಾದಂತೆ - ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ಮತ್ತು ಕ್ರಮವಾಗಿ.

ಸಮಸ್ಯೆಯೆಂದರೆ, TCP ಡೇಟಾ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಈ ರೀತಿಯಲ್ಲಿ "ಸಿಂಕ್ರೊನೈಸ್" ಮಾಡಿದಾಗ, ಒಂದು ಪ್ಯಾಕೆಟ್ ಕಳೆದುಹೋದರೆ, ಕಳೆದುಹೋದ ಪ್ಯಾಕೆಟ್ ಮರುಕಳಿಸುವವರೆಗೆ (ಮತ್ತು ಗಮ್ಯಸ್ಥಾನವನ್ನು ಸ್ವೀಕರಿಸುವವರೆಗೆ) ಪ್ರಸರಣವು ನಿಲ್ಲುತ್ತದೆ. ಕಾಯುತ್ತಿರುವಾಗ ಹೊಸ ಡೇಟಾ ಬಂದರೆ, ಅದು ಸರದಿಯಲ್ಲಿರುತ್ತದೆ ಮತ್ತು ಕಳೆದುಹೋದ ಪ್ಯಾಕೆಟ್ ಬರುವವರೆಗೆ ಅದನ್ನು ಓದಲು ನಿಮಗೆ ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಮರುಕಳುಹಿಸಲು ಎಷ್ಟು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ? ಇದು ಪ್ಯಾಕೆಟ್‌ನ ರೌಂಡ್-ಟ್ರಿಪ್ ಸಮಯವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ (ಯಾವ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಮರುಕಳುಹಿಸಬೇಕೆಂದು TCP ನಿರ್ಧರಿಸಿದಾಗ), ಜೊತೆಗೆ ಕಳೆದುಹೋದ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಮರು-ವಿತರಿಸಲು ಸಮಯವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಆದ್ದರಿಂದ, ಕಂಪ್ಯೂಟರ್‌ಗಳ ನಡುವಿನ ಪಿಂಗ್ 125 ಎಂಎಸ್ ಆಗಿದ್ದರೆ, ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಮರುಪ್ರಸಾರ ಮಾಡುವುದು ಸೆಕೆಂಡಿನ ಐದನೇ ಒಂದು ಭಾಗವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಕೆಟ್ಟ ಸಂದರ್ಭದಲ್ಲಿ ಅರ್ಧ ಸೆಕೆಂಡ್ ವರೆಗೆ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ (ರೆಸೆಂಟ್ ಪ್ಯಾಕೆಟ್ ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಕಳೆದುಹೋದರೆ ಊಹಿಸಿ). ವೆಸೇಲುಖಾ!

ಮಲ್ಟಿಪ್ಲೇಯರ್ ಆಟಗಳಿಗೆ ನೀವು TCP ಅನ್ನು ಏಕೆ ಬಳಸಬಾರದು

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

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

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

ದುರದೃಷ್ಟವಶಾತ್, TCP ಯ ಈ ನಡವಳಿಕೆಯನ್ನು ಬದಲಾಯಿಸಲು ಯಾವುದೇ ಮಾರ್ಗವಿಲ್ಲ, ಮತ್ತು ಇದು TCP ಯ ಅರ್ಥವಾಗಿರುವುದರಿಂದ ಅಗತ್ಯವಿಲ್ಲ. ಇಂಟರ್ನೆಟ್ ಮೂಲಕ ಡೇಟಾ ಪ್ರಸರಣವನ್ನು ವಿಶ್ವಾಸಾರ್ಹ ಮತ್ತು ಸ್ಥಿರವಾದ ಡೇಟಾ ಹರಿವು ಮಾಡಲು ಇದು ಅವಶ್ಯಕವಾಗಿದೆ.
ಆದರೆ ನಮಗೆ ವಿಶ್ವಾಸಾರ್ಹ ಮತ್ತು ಸ್ಥಿರವಾದ ಡೇಟಾ ಸ್ಟ್ರೀಮ್ ಅಗತ್ಯವಿಲ್ಲ.

ಕ್ಲೈಂಟ್‌ನಿಂದ ಸರ್ವರ್‌ಗೆ ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ಪಡೆಯಲು ನಮಗೆ ಡೇಟಾ ಅಗತ್ಯವಿದೆ, ಮತ್ತು ಡೇಟಾವನ್ನು ಮರುಕಳಿಸುವುದಕ್ಕಾಗಿ ನಾವು ಕಾಯಲು ಬಯಸುವುದಿಲ್ಲ.
ಅದಕ್ಕಾಗಿಯೇ ನೀವು ಮಲ್ಟಿಪ್ಲೇಯರ್ ಆಟಗಳಿಗೆ TCP ಅನ್ನು ಎಂದಿಗೂ ಬಳಸಬಾರದು.

ಆದರೆ ನಿಲ್ಲು! ನಾನು UDP ಮತ್ತು TCP ಎರಡನ್ನೂ ಏಕೆ ಒಟ್ಟಿಗೆ ಬಳಸಬಾರದು?

ಬಳಕೆದಾರರ ಕ್ಲಿಕ್‌ಗಳು ಮತ್ತು ಗೇಮ್ ವರ್ಲ್ಡ್ ಸ್ಟೇಟ್‌ನಂತಹ ನೈಜ-ಸಮಯದ ಆಟದ ಡೇಟಾಗೆ, ಪ್ರಸ್ತುತ ಡೇಟಾ ಮಾತ್ರ ಮುಖ್ಯವಾಗಿದೆ, ಆದರೆ ಇತರ ರೀತಿಯ ಡೇಟಾಗೆ, ಉದಾಹರಣೆಗೆ ಒಂದು ಕಂಪ್ಯೂಟರ್‌ನಿಂದ ಇನ್ನೊಂದಕ್ಕೆ ಕಳುಹಿಸಲಾದ ಆಜ್ಞೆಗಳ ಸೆಟ್‌ಗಳು, ಚಾನಲ್‌ನ ವಿಶ್ವಾಸಾರ್ಹತೆ ಮತ್ತು ಸ್ಥಿರತೆ ಬಹಳ ಮುಖ್ಯವಾಗಬಹುದು.

ಸಹಜವಾಗಿ, ಬಳಕೆದಾರರ ಇನ್‌ಪುಟ್ ಮತ್ತು ವರ್ಲ್ಡ್ ಸ್ಟೇಟ್ ಡೇಟಾಗಾಗಿ UDP ಅನ್ನು ಬಳಸಲು ಇದು ಪ್ರಲೋಭನಕಾರಿಯಾಗಿದೆ ಮತ್ತು ಡೇಟಾಕ್ಕಾಗಿ TCP ಅನ್ನು ಡೆಲಿವರಿ ಮಾಡಲಾಗುವುದು ಎಂದು ಖಾತರಿಪಡಿಸಬೇಕು. ನೀವು ಕಮಾಂಡ್‌ಗಳ ಬಹು "ಥ್ರೆಡ್‌ಗಳನ್ನು" ಮಾಡಬಹುದು ಎಂದು ನೀವು ಯೋಚಿಸುತ್ತಿರಬಹುದು - ಉದಾಹರಣೆಗೆ, ಒಂದು ಹಂತಗಳನ್ನು ಲೋಡ್ ಮಾಡಲು, ಇನ್ನೊಂದು AI ಆಜ್ಞೆಗಳಿಗೆ. ನೀವು ಯೋಚಿಸುತ್ತಿದ್ದೀರಿ, “ಒಂದು ಹಂತವನ್ನು ಲೋಡ್ ಮಾಡಲು ಡೇಟಾ ಪ್ಯಾಕೆಟ್ ಕಳೆದುಹೋದರೆ, AI ತಂಡಗಳು ಸಾಲಿನಲ್ಲಿ ಕಾಯುವ ಅಗತ್ಯವಿಲ್ಲ, ಏಕೆಂದರೆ ಅವುಗಳು ಸಂಪೂರ್ಣವಾಗಿ ಸಂಬಂಧವಿಲ್ಲ!” ಈ ಸಂದರ್ಭದಲ್ಲಿ, ನೀವು ಸರಿ, ಮತ್ತು ನೀವು ಪ್ರತಿ ಕಮಾಂಡ್ ಸ್ಟ್ರೀಮ್ಗೆ TCP ಸಾಕೆಟ್ ಅನ್ನು ರಚಿಸಲು ನಿರ್ಧರಿಸಬಹುದು.

ಮೊದಲ ನೋಟದಲ್ಲಿ, ಇದು ಉತ್ತಮ ಉಪಾಯವಾಗಿದೆ. ಆದರೆ ಸಮಸ್ಯೆಯೆಂದರೆ TCP ಮತ್ತು UDP ಎರಡೂ IP ಯ ಮೇಲೆ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದರಿಂದ, ಎರಡೂ ಪ್ರೋಟೋಕಾಲ್‌ಗಳ ಪ್ಯಾಕೆಟ್‌ಗಳು ಪರಸ್ಪರ ಪ್ರಭಾವ ಬೀರುತ್ತವೆ - ಈಗಾಗಲೇ IP ಮಟ್ಟದಲ್ಲಿ. ಈ ಪರಿಣಾಮವು ಎಷ್ಟು ನಿಖರವಾಗಿ ಪ್ರಕಟವಾಗುತ್ತದೆ ಎಂಬುದು ಬಹಳ ಸಂಕೀರ್ಣವಾದ ಪ್ರಶ್ನೆಯಾಗಿದೆ ಮತ್ತು ಇದು TCP ಯಲ್ಲಿನ ವಿಶ್ವಾಸಾರ್ಹತೆಯ ಕಾರ್ಯವಿಧಾನಗಳಿಗೆ ಸಂಬಂಧಿಸಿದೆ. ಆದರೆ, ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ, TCP ಬಳಕೆಯು ಸಾಮಾನ್ಯವಾಗಿ UDP ಪ್ಯಾಕೆಟ್ ನಷ್ಟಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ ಎಂದು ತಿಳಿದಿರಲಿ. ನೀವು ಇದರ ಬಗ್ಗೆ ಇನ್ನಷ್ಟು ತಿಳಿದುಕೊಳ್ಳಲು ಬಯಸಿದರೆ, ನೀವು ಈ ಲೇಖನವನ್ನು ಓದಬಹುದು.

ತೀರ್ಮಾನ

ನಾನು ಕೇವಲ UDP ಅನ್ನು ಬಳಸದೆ, UDP ಅನ್ನು ಮಾತ್ರ ಬಳಸುವುದನ್ನು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ ಮತ್ತು ಬೇರೇನೂ ಇಲ್ಲ. TCP ಮತ್ತು UDP ಅನ್ನು ಒಟ್ಟಿಗೆ ಬಳಸಬೇಡಿ - ಬದಲಿಗೆ, UDP ಆಧಾರದ ಮೇಲೆ ನಿಮಗೆ ಅಗತ್ಯವಿರುವ TCP ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಹೇಗೆ ಕಾರ್ಯಗತಗೊಳಿಸಬೇಕು ಎಂಬುದನ್ನು ತಿಳಿಯಿರಿ.

ಮುಂದಿನ ಲೇಖನಗಳಲ್ಲಿ ಇದನ್ನು ಹೇಗೆ ಮಾಡಬೇಕೆಂದು ನಾನು ನಿಮಗೆ ಹೇಳುತ್ತೇನೆ - UDP- ಆಧಾರಿತ ಸಂಪರ್ಕಗಳನ್ನು ಬಳಸಿಕೊಂಡು ನಿಮ್ಮ ಸ್ವಂತ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವುದರಿಂದ, ಪ್ರಸರಣ ವಿಶ್ವಾಸಾರ್ಹತೆ ಮತ್ತು ಡೇಟಾ ಹರಿವಿನ ನಿಯಂತ್ರಣವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವುದು.