ಸಾಫ್ಟ್‌ವೇರ್ ಮತ್ತು ಹಾರ್ಡ್‌ವೇರ್ ಕ್ಷೇತ್ರದಲ್ಲಿನ ತಂತ್ರಜ್ಞಾನಗಳ ಅಭಿವೃದ್ಧಿ, ಹೊಸ ಸಂವಹನ ಪ್ರೋಟೋಕಾಲ್ಗಳ ಹೊರಹೊಮ್ಮುವಿಕೆ ಇಂಟರ್ನೆಟ್ ಆಫ್ ಥಿಂಗ್ಸ್ (ಐಒಟಿ) ವಿಸ್ತರಣೆಗೆ ಕಾರಣವಾಗಿದೆ. ಸಾಧನಗಳ ಸಂಖ್ಯೆಯು ದಿನದಿಂದ ದಿನಕ್ಕೆ ಬೆಳೆಯುತ್ತಿದೆ ಮತ್ತು ಅವುಗಳು ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದ ಡೇಟಾವನ್ನು ಉತ್ಪಾದಿಸುತ್ತಿವೆ. ಆದ್ದರಿಂದ, ಈ ಡೇಟಾವನ್ನು ಸಂಸ್ಕರಿಸುವ, ಸಂಗ್ರಹಿಸುವ ಮತ್ತು ರವಾನಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿರುವ ಅನುಕೂಲಕರವಾದ ಸಿಸ್ಟಮ್ ಆರ್ಕಿಟೆಕ್ಚರ್ನ ಅವಶ್ಯಕತೆಯಿದೆ.
ಈಗ ಕ್ಲೌಡ್ ಸೇವೆಗಳನ್ನು ಈ ಉದ್ದೇಶಗಳಿಗಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಹೆಚ್ಚು ಜನಪ್ರಿಯವಾಗಿರುವ ಫಾಗ್ ಕಂಪ್ಯೂಟಿಂಗ್ ಮಾದರಿ (ಫಾಗ್) IoT ಮೂಲಸೌಕರ್ಯವನ್ನು ಸ್ಕೇಲಿಂಗ್ ಮತ್ತು ಆಪ್ಟಿಮೈಜ್ ಮಾಡುವ ಮೂಲಕ ಕ್ಲೌಡ್ ಪರಿಹಾರಗಳನ್ನು ಪೂರೈಸುತ್ತದೆ.
ಮೋಡಗಳು ಹೆಚ್ಚಿನ IoT ವಿನಂತಿಗಳನ್ನು ಒಳಗೊಳ್ಳಲು ಸಮರ್ಥವಾಗಿವೆ. ಉದಾಹರಣೆಗೆ, ಸೇವೆಗಳ ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಒದಗಿಸಲು, ಸಾಧನಗಳಿಂದ ಉತ್ಪತ್ತಿಯಾಗುವ ಯಾವುದೇ ಪ್ರಮಾಣದ ಡೇಟಾದ ವೇಗದ ಪ್ರಕ್ರಿಯೆ, ಹಾಗೆಯೇ ಅವುಗಳ ದೃಶ್ಯೀಕರಣ. ನೈಜ-ಸಮಯದ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುವಾಗ ಫಾಗ್ ಕಂಪ್ಯೂಟಿಂಗ್ ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿದೆ. ಅವರು ವಿನಂತಿಗಳಿಗೆ ವೇಗದ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಮತ್ತು ಡೇಟಾ ಸಂಸ್ಕರಣೆಯಲ್ಲಿ ಕನಿಷ್ಠ ಸುಪ್ತತೆಯನ್ನು ಒದಗಿಸುತ್ತಾರೆ. ಅಂದರೆ, ಮಂಜು "ಮೋಡಗಳನ್ನು" ಪೂರಕಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಅದರ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ವಿಸ್ತರಿಸುತ್ತದೆ.
ಆದಾಗ್ಯೂ, ಮುಖ್ಯ ಪ್ರಶ್ನೆ ವಿಭಿನ್ನವಾಗಿದೆ: IoT ಯ ಸಂದರ್ಭದಲ್ಲಿ ಇದೆಲ್ಲವೂ ಹೇಗೆ ಸಂವಹನ ನಡೆಸಬೇಕು? ಸಂಯೋಜಿತ IoT-Fog-Cloud ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಕೆಲಸ ಮಾಡುವಾಗ ಯಾವ ಸಂವಹನ ಪ್ರೋಟೋಕಾಲ್‌ಗಳು ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿರುತ್ತವೆ?
HTTP ಯ ಸ್ಪಷ್ಟ ಪ್ರಾಬಲ್ಯದ ಹೊರತಾಗಿಯೂ, IoT, ಫಾಗ್ ಮತ್ತು ಕ್ಲೌಡ್ ಸಿಸ್ಟಮ್‌ಗಳಲ್ಲಿ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಇತರ ಪರಿಹಾರಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ. ಏಕೆಂದರೆ IoT ಬಳಕೆದಾರರ ಸುರಕ್ಷತೆ, ಹೊಂದಾಣಿಕೆ ಮತ್ತು ಇತರ ಅವಶ್ಯಕತೆಗಳೊಂದಿಗೆ ವಿವಿಧ ಸಾಧನ ಸಂವೇದಕಗಳ ಕಾರ್ಯವನ್ನು ಸಂಯೋಜಿಸಬೇಕು.
ಆದರೆ ಉಲ್ಲೇಖ ಆರ್ಕಿಟೆಕ್ಚರ್ ಮತ್ತು ಸಂವಹನ ಮಾನದಂಡದ ಬಗ್ಗೆ ಯಾವುದೇ ಒಂದು ಕಲ್ಪನೆ ಇಲ್ಲ. ಆದ್ದರಿಂದ, ನಿರ್ದಿಷ್ಟ IoT ಕಾರ್ಯಗಳಿಗಾಗಿ ಹೊಸ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ರಚಿಸುವುದು ಅಥವಾ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಒಂದನ್ನು ಮಾರ್ಪಡಿಸುವುದು IT ಸಮುದಾಯವು ಎದುರಿಸುತ್ತಿರುವ ಪ್ರಮುಖ ಕಾರ್ಯಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ.
ಯಾವ ಪ್ರೋಟೋಕಾಲ್‌ಗಳು ಪ್ರಸ್ತುತ ಬಳಕೆಯಲ್ಲಿವೆ ಮತ್ತು ಅವುಗಳು ಏನು ನೀಡಬಹುದು? ಅದನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡೋಣ. ಆದರೆ ಮೊದಲು, ಮೋಡಗಳು, ಮಂಜು ಮತ್ತು ವಸ್ತುಗಳ ಇಂಟರ್ನೆಟ್ ಸಂವಹನ ನಡೆಸುವ ಪರಿಸರ ವ್ಯವಸ್ಥೆಯ ತತ್ವಗಳನ್ನು ಚರ್ಚಿಸೋಣ.
IoT ಫಾಗ್-ಟು-ಕ್ಲೌಡ್ (F2C) ಆರ್ಕಿಟೆಕ್ಚರ್
IoT, ಕ್ಲೌಡ್ ಮತ್ತು ಮಂಜಿನ ಸ್ಮಾರ್ಟ್ ಮತ್ತು ಸಂಘಟಿತ ನಿರ್ವಹಣೆಗೆ ಸಂಬಂಧಿಸಿದ ಅನುಕೂಲಗಳು ಮತ್ತು ಪ್ರಯೋಜನಗಳನ್ನು ಅನ್ವೇಷಿಸಲು ಎಷ್ಟು ಪ್ರಯತ್ನಗಳನ್ನು ಮಾಡಲಾಗುತ್ತಿದೆ ಎಂಬುದನ್ನು ನೀವು ಬಹುಶಃ ಗಮನಿಸಿರಬಹುದು. ಇಲ್ಲದಿದ್ದರೆ, ಮೂರು ಪ್ರಮಾಣೀಕರಣ ಉಪಕ್ರಮಗಳು ಇಲ್ಲಿವೆ: , и .
ಹಿಂದೆ ಕೇವಲ 2 ಹಂತಗಳನ್ನು ಪರಿಗಣಿಸಿದ್ದರೆ, ಮೋಡಗಳು ಮತ್ತು ಅಂತಿಮ ಸಾಧನಗಳು, ನಂತರ ಪ್ರಸ್ತಾವಿತ ವಾಸ್ತುಶಿಲ್ಪವು ಹೊಸ ಹಂತವನ್ನು ಪರಿಚಯಿಸುತ್ತದೆ - ಮಂಜು ಕಂಪ್ಯೂಟಿಂಗ್. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಸಂಪನ್ಮೂಲಗಳ ನಿಶ್ಚಿತಗಳು ಅಥವಾ ಈ ಉಪಹಂತಗಳಲ್ಲಿ ವಿವಿಧ ಸಾಧನಗಳ ಬಳಕೆಯನ್ನು ನಿರ್ಧರಿಸುವ ನೀತಿಗಳ ಗುಂಪನ್ನು ಅವಲಂಬಿಸಿ ಮಂಜು ಮಟ್ಟವನ್ನು ಹಲವಾರು ಉಪ ಹಂತಗಳಾಗಿ ವಿಂಗಡಿಸಬಹುದು.
ಈ ಅಮೂರ್ತತೆ ಹೇಗಿರಬಹುದು? ವಿಶಿಷ್ಟವಾದ IoT-Fog-Cloud ಪರಿಸರ ವ್ಯವಸ್ಥೆ ಇಲ್ಲಿದೆ. IoT ಸಾಧನಗಳು ಕಡಿಮೆ ಲೇಟೆನ್ಸಿ ಅಗತ್ಯವಿರುವ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು ವೇಗವಾದ ಸರ್ವರ್‌ಗಳು ಮತ್ತು ಕಂಪ್ಯೂಟಿಂಗ್ ಸಾಧನಗಳಿಗೆ ಡೇಟಾವನ್ನು ಕಳುಹಿಸುತ್ತವೆ. ಅದೇ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ, ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದ ಕಂಪ್ಯೂಟಿಂಗ್ ಸಂಪನ್ಮೂಲಗಳು ಅಥವಾ ಡೇಟಾ ಶೇಖರಣಾ ಸ್ಥಳದ ಅಗತ್ಯವಿರುವ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು ಮೋಡಗಳು ಜವಾಬ್ದಾರರಾಗಿರುತ್ತವೆ.
ಸ್ಮಾರ್ಟ್‌ಫೋನ್‌ಗಳು, ಸ್ಮಾರ್ಟ್ ವಾಚ್‌ಗಳು ಮತ್ತು ಇತರ ಗ್ಯಾಜೆಟ್‌ಗಳು ಸಹ IoT ಯ ಭಾಗವಾಗಿರಬಹುದು. ಆದರೆ ಅಂತಹ ಸಾಧನಗಳು, ನಿಯಮದಂತೆ, ದೊಡ್ಡ ಡೆವಲಪರ್ಗಳಿಂದ ಸ್ವಾಮ್ಯದ ಸಂವಹನ ಪ್ರೋಟೋಕಾಲ್ಗಳನ್ನು ಬಳಸುತ್ತವೆ. ರಚಿತವಾದ IoT ಡೇಟಾವನ್ನು REST HTTP ಪ್ರೋಟೋಕಾಲ್ ಮೂಲಕ ಮಂಜು ಪದರಕ್ಕೆ ವರ್ಗಾಯಿಸಲಾಗುತ್ತದೆ, ಇದು RESTful ಸೇವೆಗಳನ್ನು ರಚಿಸುವಾಗ ನಮ್ಯತೆ ಮತ್ತು ಪರಸ್ಪರ ಕಾರ್ಯಸಾಧ್ಯತೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ. ಸ್ಥಳೀಯ ಕಂಪ್ಯೂಟರ್‌ಗಳು, ಸರ್ವರ್‌ಗಳು ಅಥವಾ ಸರ್ವರ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಕಂಪ್ಯೂಟಿಂಗ್ ಮೂಲಸೌಕರ್ಯದೊಂದಿಗೆ ಹಿಂದುಳಿದ ಹೊಂದಾಣಿಕೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವ ಅಗತ್ಯತೆಯ ಬೆಳಕಿನಲ್ಲಿ ಇದು ಮುಖ್ಯವಾಗಿದೆ. "ಮಂಜು ನೋಡ್‌ಗಳು" ಎಂದು ಕರೆಯಲ್ಪಡುವ ಸ್ಥಳೀಯ ಸಂಪನ್ಮೂಲಗಳು ಸ್ವೀಕರಿಸಿದ ಡೇಟಾವನ್ನು ಫಿಲ್ಟರ್ ಮಾಡಿ ಮತ್ತು ಅದನ್ನು ಸ್ಥಳೀಯವಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿ ಅಥವಾ ಹೆಚ್ಚಿನ ಲೆಕ್ಕಾಚಾರಗಳಿಗಾಗಿ ಕ್ಲೌಡ್‌ಗೆ ಕಳುಹಿಸಿ.
ಮೋಡಗಳು ವಿಭಿನ್ನ ಸಂವಹನ ಪ್ರೋಟೋಕಾಲ್ಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತವೆ, ಸಾಮಾನ್ಯವಾದವು AMQP ಮತ್ತು REST HTTP. HTTP ಚೆನ್ನಾಗಿ ತಿಳಿದಿರುವ ಮತ್ತು ಇಂಟರ್ನೆಟ್‌ಗೆ ಅನುಗುಣವಾಗಿರುವುದರಿಂದ, ಪ್ರಶ್ನೆ ಉದ್ಭವಿಸಬಹುದು: "IoT ಮತ್ತು ಮಂಜು ಜೊತೆ ಕೆಲಸ ಮಾಡಲು ನಾವು ಇದನ್ನು ಬಳಸಬೇಕಲ್ಲವೇ?" ಆದಾಗ್ಯೂ, ಈ ಪ್ರೋಟೋಕಾಲ್ ಕಾರ್ಯಕ್ಷಮತೆಯ ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿದೆ. ಇದರ ಬಗ್ಗೆ ನಂತರ ಇನ್ನಷ್ಟು.
ಸಾಮಾನ್ಯವಾಗಿ, ನಮಗೆ ಅಗತ್ಯವಿರುವ ವ್ಯವಸ್ಥೆಗೆ ಸೂಕ್ತವಾದ ಸಂವಹನ ಪ್ರೋಟೋಕಾಲ್ಗಳ 2 ಮಾದರಿಗಳಿವೆ. ಇವುಗಳು ವಿನಂತಿ-ಪ್ರತಿಕ್ರಿಯೆ ಮತ್ತು ಪ್ರಕಟಿಸಲು-ಚಂದಾದಾರರಾಗಿ. ಮೊದಲ ಮಾದರಿಯು ಹೆಚ್ಚು ವ್ಯಾಪಕವಾಗಿ ಪರಿಚಿತವಾಗಿದೆ, ವಿಶೇಷವಾಗಿ ಸರ್ವರ್-ಕ್ಲೈಂಟ್ ಆರ್ಕಿಟೆಕ್ಚರ್ನಲ್ಲಿ. ಕ್ಲೈಂಟ್ ಸರ್ವರ್‌ನಿಂದ ಮಾಹಿತಿಯನ್ನು ವಿನಂತಿಸುತ್ತದೆ ಮತ್ತು ಸರ್ವರ್ ವಿನಂತಿಯನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ಅದನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆ ಸಂದೇಶವನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ. REST HTTP ಮತ್ತು CoAP ಪ್ರೋಟೋಕಾಲ್‌ಗಳು ಈ ಮಾದರಿಯಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ.
ಡೇಟಾವನ್ನು ಉತ್ಪಾದಿಸುವ ಮೂಲಗಳು ಮತ್ತು ಈ ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸುವವರ ನಡುವೆ ಅಸಮಕಾಲಿಕ, ವಿತರಿಸಿದ, ಸಡಿಲವಾದ ಜೋಡಣೆಯನ್ನು ಒದಗಿಸುವ ಅಗತ್ಯದಿಂದ ಎರಡನೇ ಮಾದರಿಯು ಹುಟ್ಟಿಕೊಂಡಿತು.
ಮಾದರಿಯು ಮೂರು ಭಾಗವಹಿಸುವವರನ್ನು ಊಹಿಸುತ್ತದೆ: ಪ್ರಕಾಶಕ (ಡೇಟಾ ಮೂಲ), ಬ್ರೋಕರ್ (ರವಾನೆದಾರ) ಮತ್ತು ಚಂದಾದಾರ (ರಿಸೀವರ್). ಇಲ್ಲಿ, ಚಂದಾದಾರರಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಕ್ಲೈಂಟ್ ಸರ್ವರ್‌ನಿಂದ ಮಾಹಿತಿಯನ್ನು ವಿನಂತಿಸಬೇಕಾಗಿಲ್ಲ. ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸುವ ಬದಲು, ಇದು ಬ್ರೋಕರ್ ಮೂಲಕ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ಕೆಲವು ಈವೆಂಟ್‌ಗಳಿಗೆ ಚಂದಾದಾರರಾಗುತ್ತದೆ, ಇದು ಎಲ್ಲಾ ಒಳಬರುವ ಸಂದೇಶಗಳನ್ನು ಫಿಲ್ಟರ್ ಮಾಡಲು ಮತ್ತು ಪ್ರಕಾಶಕರು ಮತ್ತು ಚಂದಾದಾರರ ನಡುವೆ ಅವುಗಳನ್ನು ರೂಟಿಂಗ್ ಮಾಡಲು ಕಾರಣವಾಗಿದೆ. ಮತ್ತು ಪ್ರಕಾಶಕರು, ಒಂದು ನಿರ್ದಿಷ್ಟ ವಿಷಯಕ್ಕೆ ಸಂಬಂಧಿಸಿದಂತೆ ಈವೆಂಟ್ ಸಂಭವಿಸಿದಾಗ, ಅದನ್ನು ಬ್ರೋಕರ್‌ಗೆ ಪ್ರಕಟಿಸುತ್ತಾರೆ, ಅದು ವಿನಂತಿಸಿದ ವಿಷಯದ ಡೇಟಾವನ್ನು ಚಂದಾದಾರರಿಗೆ ಕಳುಹಿಸುತ್ತದೆ.
ಮೂಲಭೂತವಾಗಿ, ಈ ವಾಸ್ತುಶಿಲ್ಪವು ಈವೆಂಟ್ ಆಧಾರಿತವಾಗಿದೆ. ಮತ್ತು ಈ ಸಂವಹನ ಮಾದರಿಯು IoT, ಕ್ಲೌಡ್, ಮಂಜುಗಳಲ್ಲಿನ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಆಸಕ್ತಿದಾಯಕವಾಗಿದೆ ಏಕೆಂದರೆ ಸ್ಕೇಲೆಬಿಲಿಟಿಯನ್ನು ಒದಗಿಸುವ ಮತ್ತು ವಿಭಿನ್ನ ಸಾಧನಗಳ ನಡುವಿನ ಪರಸ್ಪರ ಸಂಪರ್ಕವನ್ನು ಸರಳಗೊಳಿಸುವ ಸಾಮರ್ಥ್ಯ, ಡೈನಾಮಿಕ್ ಬಹು-ಹಲವು ಸಂವಹನ ಮತ್ತು ಅಸಮಕಾಲಿಕ ಸಂವಹನವನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ. MQTT, AMQP, ಮತ್ತು DDS ಅನ್ನು ಪ್ರಕಟಿಸುವ-ಚಂದಾದಾರಿಕೆ ಮಾದರಿಯನ್ನು ಬಳಸುವ ಕೆಲವು ಅತ್ಯಂತ ಪ್ರಸಿದ್ಧವಾದ ಪ್ರಮಾಣಿತ ಸಂದೇಶ ಪ್ರೋಟೋಕಾಲ್‌ಗಳು.
ನಿಸ್ಸಂಶಯವಾಗಿ, ಪ್ರಕಟಣೆ-ಚಂದಾದಾರಿಕೆ ಮಾದರಿಯು ಬಹಳಷ್ಟು ಪ್ರಯೋಜನಗಳನ್ನು ಹೊಂದಿದೆ:
- ಪ್ರಕಾಶಕರು ಮತ್ತು ಚಂದಾದಾರರು ಪರಸ್ಪರರ ಅಸ್ತಿತ್ವದ ಬಗ್ಗೆ ತಿಳಿದುಕೊಳ್ಳಬೇಕಾಗಿಲ್ಲ;
- ಒಬ್ಬ ಚಂದಾದಾರರು ವಿವಿಧ ಪ್ರಕಟಣೆಗಳಿಂದ ಮಾಹಿತಿಯನ್ನು ಪಡೆಯಬಹುದು ಮತ್ತು ಒಬ್ಬ ಪ್ರಕಾಶಕರು ವಿವಿಧ ಚಂದಾದಾರರಿಗೆ ಡೇಟಾವನ್ನು ಕಳುಹಿಸಬಹುದು (ಹಲವು-ಹಲವು ತತ್ವ);
- ಪ್ರಕಾಶಕರು ಮತ್ತು ಚಂದಾದಾರರು ಸಂವಹನ ನಡೆಸಲು ಅದೇ ಸಮಯದಲ್ಲಿ ಸಕ್ರಿಯವಾಗಿರಬೇಕಾಗಿಲ್ಲ, ಏಕೆಂದರೆ ಬ್ರೋಕರ್ (ಸರಣಿ ವ್ಯವಸ್ಥೆಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದ್ದಾರೆ) ಪ್ರಸ್ತುತ ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಸಂಪರ್ಕ ಹೊಂದಿಲ್ಲದ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಸಂದೇಶವನ್ನು ಸಂಗ್ರಹಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.
ಆದಾಗ್ಯೂ, ವಿನಂತಿ-ಪ್ರತಿಕ್ರಿಯೆ ಮಾದರಿಯು ಅದರ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿದೆ. ಬಹು ಕ್ಲೈಂಟ್ ವಿನಂತಿಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಸರ್ವರ್ ಸೈಡ್ನ ಸಾಮರ್ಥ್ಯವು ಸಮಸ್ಯೆಯಾಗದ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಸಾಬೀತಾದ, ವಿಶ್ವಾಸಾರ್ಹ ಪರಿಹಾರಗಳನ್ನು ಬಳಸುವುದು ಅರ್ಥಪೂರ್ಣವಾಗಿದೆ.
ಎರಡೂ ಮಾದರಿಗಳನ್ನು ಬೆಂಬಲಿಸುವ ಪ್ರೋಟೋಕಾಲ್‌ಗಳೂ ಇವೆ. ಉದಾಹರಣೆಗೆ, "ಸರ್ವರ್ ಪುಶ್" ಆಯ್ಕೆಯನ್ನು ಬೆಂಬಲಿಸುವ XMPP ಮತ್ತು HTTP 2.0. IETF ಸಹ CoAP ಅನ್ನು ಬಿಡುಗಡೆ ಮಾಡಿದೆ. ಸಂದೇಶ ಕಳುಹಿಸುವಿಕೆಯ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವ ಪ್ರಯತ್ನದಲ್ಲಿ, ವೆಬ್‌ಸಾಕೆಟ್‌ಗಳ ಪ್ರೋಟೋಕಾಲ್ ಅಥವಾ QUIC (ಕ್ವಿಕ್ UDP ಇಂಟರ್ನೆಟ್ ಸಂಪರ್ಕಗಳು) ಮೂಲಕ HTTP ಪ್ರೋಟೋಕಾಲ್‌ನ ಬಳಕೆಯಂತಹ ಹಲವಾರು ಇತರ ಪರಿಹಾರಗಳನ್ನು ರಚಿಸಲಾಗಿದೆ.
ವೆಬ್‌ಸಾಕೆಟ್‌ಗಳ ಸಂದರ್ಭದಲ್ಲಿ, ಸರ್ವರ್‌ನಿಂದ ವೆಬ್ ಕ್ಲೈಂಟ್‌ಗೆ ನೈಜ ಸಮಯದಲ್ಲಿ ಡೇಟಾವನ್ನು ವರ್ಗಾಯಿಸಲು ಬಳಸಲಾಗುತ್ತದೆ ಮತ್ತು ಏಕಕಾಲಿಕ ದ್ವಿಮುಖ ಸಂವಹನದೊಂದಿಗೆ ನಿರಂತರ ಸಂಪರ್ಕಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ, ಇದು ಸೀಮಿತ ಕಂಪ್ಯೂಟಿಂಗ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೊಂದಿರುವ ಸಾಧನಗಳಿಗೆ ಉದ್ದೇಶಿಸಿಲ್ಲ. QUIC ಸಹ ಗಮನಕ್ಕೆ ಅರ್ಹವಾಗಿದೆ, ಏಕೆಂದರೆ ಹೊಸ ಸಾರಿಗೆ ಪ್ರೋಟೋಕಾಲ್ ಬಹಳಷ್ಟು ಹೊಸ ಅವಕಾಶಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ. ಆದರೆ QUIC ಅನ್ನು ಇನ್ನೂ ಪ್ರಮಾಣೀಕರಿಸಲಾಗಿಲ್ಲವಾದ್ದರಿಂದ, IoT ಪರಿಹಾರಗಳ ಮೇಲೆ ಅದರ ಸಂಭವನೀಯ ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು ಪ್ರಭಾವವನ್ನು ಊಹಿಸಲು ಇದು ಅಕಾಲಿಕವಾಗಿದೆ. ಆದ್ದರಿಂದ ನಾವು ಭವಿಷ್ಯದ ದೃಷ್ಟಿಯಿಂದ WebSockets ಮತ್ತು QUIC ಅನ್ನು ಮನಸ್ಸಿನಲ್ಲಿಟ್ಟುಕೊಳ್ಳುತ್ತೇವೆ, ಆದರೆ ನಾವು ಇದೀಗ ಅದನ್ನು ಹೆಚ್ಚು ವಿವರವಾಗಿ ಅಧ್ಯಯನ ಮಾಡುವುದಿಲ್ಲ.
ಜಗತ್ತಿನಲ್ಲಿ ಯಾರು ಮೋಹಕರಾಗಿದ್ದಾರೆ: ಪ್ರೋಟೋಕಾಲ್ಗಳನ್ನು ಹೋಲಿಸುವುದು
ಈಗ ಪ್ರೋಟೋಕಾಲ್ಗಳ ಸಾಮರ್ಥ್ಯ ಮತ್ತು ದೌರ್ಬಲ್ಯಗಳ ಬಗ್ಗೆ ಮಾತನಾಡೋಣ. ಮುಂದೆ ನೋಡುತ್ತಿರುವಾಗ, ಸ್ಪಷ್ಟ ನಾಯಕ ಯಾರೂ ಇಲ್ಲ ಎಂದು ತಕ್ಷಣವೇ ಕಾಯ್ದಿರಿಸೋಣ. ಪ್ರತಿಯೊಂದು ಪ್ರೋಟೋಕಾಲ್ ಕೆಲವು ಅನುಕೂಲಗಳು/ಅನುಕೂಲಗಳನ್ನು ಹೊಂದಿದೆ.
ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯ
ಸಂವಹನ ಪ್ರೋಟೋಕಾಲ್ಗಳ ಪ್ರಮುಖ ಗುಣಲಕ್ಷಣಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ, ವಿಶೇಷವಾಗಿ ಇಂಟರ್ನೆಟ್ ಆಫ್ ಥಿಂಗ್ಸ್‌ಗೆ ಸಂಬಂಧಿಸಿದಂತೆ, ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯ. ಆದರೆ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಪ್ರೋಟೋಕಾಲ್‌ಗಳಲ್ಲಿ, ವಿಭಿನ್ನ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡುವಾಗ ಕನಿಷ್ಠ ಮಟ್ಟದ ಸುಪ್ತತೆಯನ್ನು ಪ್ರದರ್ಶಿಸುವ ಸ್ಪಷ್ಟ ವಿಜೇತರು ಇಲ್ಲ. ಆದರೆ ಪ್ರೋಟೋಕಾಲ್ ಸಾಮರ್ಥ್ಯಗಳ ಸಂಶೋಧನೆ ಮತ್ತು ಹೋಲಿಕೆಗಳ ಸಂಪೂರ್ಣ ಗುಂಪೇ ಇದೆ.
ಉದಾಹರಣೆಗೆ, IoT ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ HTTP ಮತ್ತು MQTT ಯ ಪರಿಣಾಮಕಾರಿತ್ವದ ಹೋಲಿಕೆಗಳು MQTT ಗಾಗಿ ವಿನಂತಿಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯವು HTTP ಗಿಂತ ಕಡಿಮೆಯಾಗಿದೆ ಎಂದು ತೋರಿಸಿದೆ. ಮತ್ತು ಯಾವಾಗ MQTT ಮತ್ತು CoAP ನ ರೌಂಡ್ ಟ್ರಿಪ್ ಸಮಯ (RTT) CoAP ನ ಸರಾಸರಿ RTT MQTT ಗಿಂತ 20% ಕಡಿಮೆಯಾಗಿದೆ ಎಂದು ಬಹಿರಂಗಪಡಿಸಿದೆ.
ಇತರೆ MQTT ಮತ್ತು CoAP ಪ್ರೋಟೋಕಾಲ್‌ಗಳಿಗಾಗಿ RTT ಯೊಂದಿಗೆ ಎರಡು ಸನ್ನಿವೇಶಗಳಲ್ಲಿ ಕೈಗೊಳ್ಳಲಾಯಿತು: ಸ್ಥಳೀಯ ನೆಟ್ವರ್ಕ್ ಮತ್ತು IoT ನೆಟ್ವರ್ಕ್. IoT ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಸರಾಸರಿ RTT 2-3 ಪಟ್ಟು ಹೆಚ್ಚಾಗಿದೆ ಎಂದು ಅದು ಬದಲಾಯಿತು. CoAP ಗೆ ಹೋಲಿಸಿದರೆ QoS0 ನೊಂದಿಗೆ MQTT ಕಡಿಮೆ ಫಲಿತಾಂಶವನ್ನು ತೋರಿಸಿದೆ ಮತ್ತು QoS1 ನೊಂದಿಗೆ MQTT ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು ಸಾರಿಗೆ ಲೇಯರ್‌ಗಳಲ್ಲಿ ACK ಗಳ ಕಾರಣದಿಂದಾಗಿ ಹೆಚ್ಚಿನ RTT ಅನ್ನು ತೋರಿಸಿದೆ. ವಿಭಿನ್ನ QoS ಹಂತಗಳಿಗೆ, ದಟ್ಟಣೆ ಇಲ್ಲದ ನೆಟ್ವರ್ಕ್ ಲೇಟೆನ್ಸಿ MQTT ಗಾಗಿ ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳು ಮತ್ತು CoAP ಗಾಗಿ ನೂರಾರು ಮೈಕ್ರೋಸೆಕೆಂಡ್‌ಗಳು. ಆದಾಗ್ಯೂ, ಕಡಿಮೆ ವಿಶ್ವಾಸಾರ್ಹ ನೆಟ್ವರ್ಕ್ಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡುವಾಗ, TCP ಯ ಮೇಲೆ ಚಾಲನೆಯಲ್ಲಿರುವ MQTT ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನ ಫಲಿತಾಂಶವನ್ನು ತೋರಿಸುತ್ತದೆ ಎಂದು ನೆನಪಿನಲ್ಲಿಟ್ಟುಕೊಳ್ಳುವುದು ಯೋಗ್ಯವಾಗಿದೆ.
ಪೇಲೋಡ್ ಅನ್ನು ಹೆಚ್ಚಿಸುವ ಮೂಲಕ AMQP ಮತ್ತು MQTT ಪ್ರೋಟೋಕಾಲ್‌ಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯವು ಲಘು ಲೋಡ್‌ನೊಂದಿಗೆ ಸುಪ್ತತೆಯ ಮಟ್ಟವು ಬಹುತೇಕ ಒಂದೇ ಆಗಿರುತ್ತದೆ ಎಂದು ತೋರಿಸಿದೆ. ಆದರೆ ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದ ಡೇಟಾವನ್ನು ವರ್ಗಾಯಿಸುವಾಗ, MQTT ಕಡಿಮೆ ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯವನ್ನು ಪ್ರದರ್ಶಿಸುತ್ತದೆ. ಇನ್ನೊಂದರಲ್ಲಿ ಅನಿಲ ಸಂವೇದಕಗಳು, ಹವಾಮಾನ ಸಂವೇದಕಗಳು, ಸ್ಥಳ ಸಂವೇದಕಗಳು (GPS) ಮತ್ತು ಮೊಬೈಲ್ ನೆಟ್ವರ್ಕ್ ಇಂಟರ್ಫೇಸ್ (GPRS) ಹೊಂದಿದ ವಾಹನಗಳ ಮೇಲ್ಭಾಗದಲ್ಲಿ ನಿಯೋಜಿಸಲಾದ ಸಾಧನಗಳೊಂದಿಗೆ ಯಂತ್ರದಿಂದ ಯಂತ್ರದ ಸಂವಹನ ಸನ್ನಿವೇಶದಲ್ಲಿ CoAP ಅನ್ನು HTTP ಗೆ ಹೋಲಿಸಲಾಗಿದೆ. ಮೊಬೈಲ್ ನೆಟ್ವರ್ಕ್ ಮೂಲಕ CoAP ಸಂದೇಶವನ್ನು ರವಾನಿಸಲು ಬೇಕಾದ ಸಮಯವು HTTP ಸಂದೇಶಗಳನ್ನು ಬಳಸಲು ಬೇಕಾದ ಸಮಯಕ್ಕಿಂತ ಮೂರು ಪಟ್ಟು ಕಡಿಮೆಯಾಗಿದೆ.
ಎರಡಲ್ಲ, ಮೂರು ಪ್ರೋಟೋಕಾಲ್ಗಳನ್ನು ಹೋಲಿಸಿದ ಅಧ್ಯಯನಗಳನ್ನು ನಡೆಸಲಾಗಿದೆ. ಉದಾಹರಣೆಗೆ, ನೆಟ್ವರ್ಕ್ ಎಮ್ಯುಲೇಟರ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ವೈದ್ಯಕೀಯ ಅಪ್ಲಿಕೇಶನ್ ಸನ್ನಿವೇಶದಲ್ಲಿ IoT ಪ್ರೋಟೋಕಾಲ್ಗಳ MQTT, DDS ಮತ್ತು CoAP ನ ಕಾರ್ಯಕ್ಷಮತೆ. ವಿವಿಧ ಕಳಪೆ ನೆಟ್ವರ್ಕ್ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ಪರೀಕ್ಷಿತ ಟೆಲಿಮೆಟ್ರಿ ಲೇಟೆನ್ಸಿ ವಿಷಯದಲ್ಲಿ DDS MQTT ಯನ್ನು ಮೀರಿಸಿದೆ. UDP-ಆಧಾರಿತ CoAP ವೇಗದ ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯಗಳ ಅಗತ್ಯವಿರುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಆದಾಗ್ಯೂ, UDP-ಆಧಾರಿತವಾದ ಕಾರಣ, ಗಮನಾರ್ಹವಾದ ಅನಿರೀಕ್ಷಿತ ಪ್ಯಾಕೆಟ್ ನಷ್ಟವಾಗಿದೆ.
ಥ್ರೋಪುಟ್
ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ದಕ್ಷತೆಯ ವಿಷಯದಲ್ಲಿ MQTT ಮತ್ತು CoAP ಅನ್ನು ಪ್ರತಿ ಸಂದೇಶಕ್ಕೆ ರವಾನಿಸಲಾದ ಒಟ್ಟು ಡೇಟಾದ ಲೆಕ್ಕಾಚಾರದಂತೆ ನಡೆಸಲಾಯಿತು. ಸಣ್ಣ ಸಂದೇಶಗಳನ್ನು ರವಾನಿಸುವಾಗ CoAP MQTT ಗಿಂತ ಕಡಿಮೆ ಥ್ರೋಪುಟ್ ಅನ್ನು ತೋರಿಸಿದೆ. ಆದರೆ ವರ್ಗಾವಣೆಗೊಂಡ ಒಟ್ಟು ಬೈಟ್‌ಗಳ ಸಂಖ್ಯೆಯ ಉಪಯುಕ್ತ ಮಾಹಿತಿ ಬೈಟ್‌ಗಳ ಸಂಖ್ಯೆಯ ಅನುಪಾತಕ್ಕೆ ಸಂಬಂಧಿಸಿದಂತೆ ಪ್ರೋಟೋಕಾಲ್ಗಳ ದಕ್ಷತೆಯನ್ನು ಹೋಲಿಸಿದಾಗ, CoAP ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿದೆ.
ನಲ್ಲಿ MQTT, DDS (ಸಾರಿಗೆ ಪ್ರೋಟೋಕಾಲ್ ಆಗಿ TCP ಯೊಂದಿಗೆ) ಮತ್ತು CoAP ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು, CoAP ಸಾಮಾನ್ಯವಾಗಿ ತುಲನಾತ್ಮಕವಾಗಿ ಕಡಿಮೆ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಬಳಕೆಯನ್ನು ತೋರಿಸಿದೆ ಎಂದು ಕಂಡುಬಂದಿದೆ, ಇದು ಹೆಚ್ಚಿದ ನೆಟ್ವರ್ಕ್ ಪ್ಯಾಕೆಟ್ ನಷ್ಟ ಅಥವಾ ಹೆಚ್ಚಿದ ನೆಟ್ವರ್ಕ್ ಲೇಟೆನ್ಸಿಯೊಂದಿಗೆ ಹೆಚ್ಚಾಗುವುದಿಲ್ಲ, MQTT ಮತ್ತು DDS ಗಿಂತ ಭಿನ್ನವಾಗಿ. ಉಲ್ಲೇಖಿಸಲಾದ ಸನ್ನಿವೇಶಗಳಲ್ಲಿ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಬಳಕೆಯ ಹೆಚ್ಚಳ. ಮತ್ತೊಂದು ಸನ್ನಿವೇಶದಲ್ಲಿ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಸಾಧನಗಳು ಏಕಕಾಲದಲ್ಲಿ ಡೇಟಾವನ್ನು ರವಾನಿಸುತ್ತದೆ, ಇದು IoT ಪರಿಸರದಲ್ಲಿ ವಿಶಿಷ್ಟವಾಗಿದೆ. ಹೆಚ್ಚಿನ ಬಳಕೆಗಾಗಿ CoAP ಅನ್ನು ಬಳಸುವುದು ಉತ್ತಮ ಎಂದು ಫಲಿತಾಂಶಗಳು ತೋರಿಸಿವೆ.
ಲೈಟ್ ಲೋಡ್ ಅಡಿಯಲ್ಲಿ, CoAP ಕನಿಷ್ಠ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಅನ್ನು ಬಳಸಿತು, ನಂತರ MQTT ಮತ್ತು REST HTTP. ಆದಾಗ್ಯೂ, ಪೇಲೋಡ್‌ಗಳ ಗಾತ್ರವು ಹೆಚ್ಚಾದಾಗ, REST HTTP ಉತ್ತಮ ಫಲಿತಾಂಶಗಳನ್ನು ನೀಡಿತು.
ವಿದ್ಯುತ್ ಬಳಕೆ
ಶಕ್ತಿಯ ಬಳಕೆಯ ಸಮಸ್ಯೆಯು ಯಾವಾಗಲೂ ಹೆಚ್ಚಿನ ಪ್ರಾಮುಖ್ಯತೆಯನ್ನು ಹೊಂದಿದೆ, ಮತ್ತು ವಿಶೇಷವಾಗಿ IoT ವ್ಯವಸ್ಥೆಯಲ್ಲಿ. ಒಂದು ವೇಳೆ MQTT ಮತ್ತು HTTP ವಿದ್ಯುಚ್ಛಕ್ತಿಯನ್ನು ಬಳಸಿದರೆ, HTTP ಹೆಚ್ಚು ಬಳಸುತ್ತದೆ. ಮತ್ತು CoAP ಹೆಚ್ಚು MQTT ಗೆ ಹೋಲಿಸಿದರೆ, ವಿದ್ಯುತ್ ನಿರ್ವಹಣೆಯನ್ನು ಅನುಮತಿಸುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಸರಳ ಸನ್ನಿವೇಶಗಳಲ್ಲಿ, ಇಂಟರ್ನೆಟ್ ಆಫ್ ಥಿಂಗ್ಸ್ ನೆಟ್ವರ್ಕ್ಗಳಲ್ಲಿ ಮಾಹಿತಿಯನ್ನು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳಲು MQTT ಹೆಚ್ಚು ಸೂಕ್ತವಾಗಿದೆ, ವಿಶೇಷವಾಗಿ ಯಾವುದೇ ವಿದ್ಯುತ್ ನಿರ್ಬಂಧಗಳಿಲ್ಲದಿದ್ದರೆ.
ಮೊಬೈಲ್ ಅಥವಾ ಅಸ್ಥಿರ ವೈರ್‌ಲೆಸ್ ನೆಟ್ವರ್ಕ್ ಟೆಸ್ಟ್‌ಬೆಡ್‌ನಲ್ಲಿ AMQP ಮತ್ತು MQTT ಯ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಹೋಲಿಸಿದ ಪ್ರಯೋಗವು AMQP ಹೆಚ್ಚು ಸುರಕ್ಷತಾ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ನೀಡುತ್ತದೆ ಮತ್ತು MQTT ಹೆಚ್ಚು ಶಕ್ತಿಯ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿದೆ ಎಂದು ಕಂಡುಹಿಡಿದಿದೆ.
ಭದ್ರತೆ
ಇಂಟರ್ನೆಟ್ ಆಫ್ ಥಿಂಗ್ಸ್ ಮತ್ತು ಮಂಜು/ಕ್ಲೌಡ್ ಕಂಪ್ಯೂಟಿಂಗ್ ವಿಷಯವನ್ನು ಅಧ್ಯಯನ ಮಾಡುವಾಗ ಭದ್ರತೆಯು ಮತ್ತೊಂದು ನಿರ್ಣಾಯಕ ಸಮಸ್ಯೆಯಾಗಿದೆ. ಭದ್ರತಾ ಕಾರ್ಯವಿಧಾನವು ಸಾಮಾನ್ಯವಾಗಿ HTTP, MQTT, AMQP ಮತ್ತು XMPP ನಲ್ಲಿ TLS ಅಥವಾ CoAP ನಲ್ಲಿ DTLS ಅನ್ನು ಆಧರಿಸಿದೆ ಮತ್ತು DDS ರೂಪಾಂತರಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ.
ಬೆಂಬಲಿತ ಸೈಫರ್ ಸೂಟ್‌ಗಳು ಮತ್ತು ಕೀಗಳನ್ನು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳಲು ಕ್ಲೈಂಟ್ ಮತ್ತು ಸರ್ವರ್ ಬದಿಗಳ ನಡುವೆ ಸಂವಹನವನ್ನು ಸ್ಥಾಪಿಸುವ ಪ್ರಕ್ರಿಯೆಯೊಂದಿಗೆ TLS ಮತ್ತು DTLS ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ಸುರಕ್ಷಿತ ಚಾನಲ್‌ನಲ್ಲಿ ಮತ್ತಷ್ಟು ಸಂವಹನವು ಸಂಭವಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಎರಡೂ ಪಕ್ಷಗಳು ಸೆಟ್‌ಗಳನ್ನು ಮಾತುಕತೆ ನಡೆಸುತ್ತವೆ. ಎರಡರ ನಡುವಿನ ವ್ಯತ್ಯಾಸವು UDP-ಆಧಾರಿತ DTLS ಅನ್ನು ವಿಶ್ವಾಸಾರ್ಹವಲ್ಲದ ಸಂಪರ್ಕದಲ್ಲಿ ಕೆಲಸ ಮಾಡಲು ಅನುಮತಿಸುವ ಸಣ್ಣ ಮಾರ್ಪಾಡುಗಳಲ್ಲಿದೆ.
ನಲ್ಲಿ TLS ಮತ್ತು DTLS ನ ಹಲವಾರು ವಿಭಿನ್ನ ಅಳವಡಿಕೆಗಳು TLS ಉತ್ತಮ ಕೆಲಸವನ್ನು ಮಾಡಿದೆ ಎಂದು ಕಂಡುಹಿಡಿದಿದೆ. ಅದರ ದೋಷ ಸಹಿಷ್ಣುತೆಯಿಂದಾಗಿ DTLS ಮೇಲಿನ ದಾಳಿಗಳು ಹೆಚ್ಚು ಯಶಸ್ವಿಯಾಗಿವೆ.
ಆದಾಗ್ಯೂ, ಈ ಪ್ರೋಟೋಕಾಲ್‌ಗಳೊಂದಿಗಿನ ದೊಡ್ಡ ಸಮಸ್ಯೆಯೆಂದರೆ, ಅವುಗಳನ್ನು ಮೂಲತಃ IoT ನಲ್ಲಿ ಬಳಸಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿಲ್ಲ ಮತ್ತು ಮಂಜು ಅಥವಾ ಮೋಡದಲ್ಲಿ ಕೆಲಸ ಮಾಡಲು ಉದ್ದೇಶಿಸಿರಲಿಲ್ಲ. ಹ್ಯಾಂಡ್ಶೇಕಿಂಗ್ ಮೂಲಕ, ಅವರು ಪ್ರತಿ ಸಂಪರ್ಕ ಸ್ಥಾಪನೆಯೊಂದಿಗೆ ಹೆಚ್ಚುವರಿ ದಟ್ಟಣೆಯನ್ನು ಸೇರಿಸುತ್ತಾರೆ, ಇದು ಕಂಪ್ಯೂಟಿಂಗ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹರಿಸುತ್ತವೆ. ಸರಾಸರಿಯಾಗಿ, ಸುರಕ್ಷತಾ ಲೇಯರ್ ಇಲ್ಲದ ಸಂವಹನಗಳಿಗೆ ಹೋಲಿಸಿದರೆ ಓವರ್‌ಹೆಡ್‌ನಲ್ಲಿ TLS ಗೆ 6,5% ಮತ್ತು DTLS ಗೆ 11% ಹೆಚ್ಚಳವಾಗಿದೆ. ಸಂಪನ್ಮೂಲ-ಸಮೃದ್ಧ ಪರಿಸರದಲ್ಲಿ, ಅವು ಸಾಮಾನ್ಯವಾಗಿ ನೆಲೆಗೊಂಡಿವೆ ಮಟ್ಟದಲ್ಲಿ, ಇದು ಸಮಸ್ಯೆಯಾಗುವುದಿಲ್ಲ, ಆದರೆ IoT ಮತ್ತು ಮಂಜು ಮಟ್ಟದ ನಡುವಿನ ಸಂಪರ್ಕದಲ್ಲಿ, ಇದು ಪ್ರಮುಖ ಮಿತಿಯಾಗಿದೆ.
ಯಾವುದನ್ನು ಆರಿಸಬೇಕು? ಸ್ಪಷ್ಟ ಉತ್ತರವಿಲ್ಲ. MQTT ಮತ್ತು HTTP ಗಳು ಇತರ ಪ್ರೋಟೋಕಾಲ್‌ಗಳಿಗೆ ಹೋಲಿಸಿದರೆ ತುಲನಾತ್ಮಕವಾಗಿ ಹೆಚ್ಚು ಪ್ರಬುದ್ಧ ಮತ್ತು ಹೆಚ್ಚು ಸ್ಥಿರವಾದ IoT ಪರಿಹಾರಗಳನ್ನು ಪರಿಗಣಿಸುವುದರಿಂದ ಹೆಚ್ಚು ಭರವಸೆಯ ಪ್ರೋಟೋಕಾಲ್‌ಗಳಾಗಿವೆ.
ಏಕೀಕೃತ ಸಂವಹನ ಪ್ರೋಟೋಕಾಲ್ ಆಧಾರಿತ ಪರಿಹಾರಗಳು
ಏಕ-ಪ್ರೋಟೋಕಾಲ್ ಪರಿಹಾರದ ಅಭ್ಯಾಸವು ಅನೇಕ ಅನಾನುಕೂಲಗಳನ್ನು ಹೊಂದಿದೆ. ಉದಾಹರಣೆಗೆ, ನಿರ್ಬಂಧಿತ ಪರಿಸರಕ್ಕೆ ಸೂಕ್ತವಾದ ಪ್ರೋಟೋಕಾಲ್ ಕಟ್ಟುನಿಟ್ಟಾದ ಭದ್ರತಾ ಅವಶ್ಯಕತೆಗಳನ್ನು ಹೊಂದಿರುವ ಡೊಮೇನ್‌ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸದಿರಬಹುದು. ಇದನ್ನು ಮನಸ್ಸಿನಲ್ಲಿಟ್ಟುಕೊಂಡು, MQTT ಮತ್ತು REST HTTP ಹೊರತುಪಡಿಸಿ, IoT ಯಲ್ಲಿನ ಫಾಗ್-ಟು-ಕ್ಲೌಡ್ ಪರಿಸರ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಬಹುತೇಕ ಎಲ್ಲಾ ಏಕ-ಪ್ರೋಟೋಕಾಲ್ ಪರಿಹಾರಗಳನ್ನು ತ್ಯಜಿಸಲು ನಮಗೆ ಉಳಿದಿದೆ.
ಏಕ-ಪ್ರೋಟೋಕಾಲ್ ಪರಿಹಾರವಾಗಿ REST HTTP
IoT-to-Fog ಸ್ಪೇಸ್‌ನಲ್ಲಿ REST HTTP ವಿನಂತಿಗಳು ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆಗಳು ಹೇಗೆ ಸಂವಹನ ನಡೆಸುತ್ತವೆ ಎಂಬುದಕ್ಕೆ ಉತ್ತಮ ಉದಾಹರಣೆಯಿದೆ: . ಪ್ರಾಣಿಗಳು ಧರಿಸಬಹುದಾದ ಸಂವೇದಕಗಳನ್ನು (ಐಒಟಿ ಕ್ಲೈಂಟ್, ಸಿ) ಹೊಂದಿದ್ದು, ಸ್ಮಾರ್ಟ್ ಫಾರ್ಮಿಂಗ್ ಸಿಸ್ಟಮ್ (ಫಾಗ್ ಸರ್ವರ್, ಎಸ್) ಮೂಲಕ ಕ್ಲೌಡ್ ಕಂಪ್ಯೂಟಿಂಗ್ ಮೂಲಕ ನಿಯಂತ್ರಿಸಲಾಗುತ್ತದೆ.
POST ವಿಧಾನದ ಹೆಡರ್ ಮಾರ್ಪಡಿಸಲು ಸಂಪನ್ಮೂಲವನ್ನು (/ಫಾರ್ಮ್/ಪ್ರಾಣಿಗಳು) ಹಾಗೆಯೇ HTTP ಆವೃತ್ತಿ ಮತ್ತು ವಿಷಯ ಪ್ರಕಾರವನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ, ಈ ಸಂದರ್ಭದಲ್ಲಿ ಸಿಸ್ಟಮ್ ನಿರ್ವಹಿಸಬೇಕಾದ ಪ್ರಾಣಿ ಫಾರ್ಮ್ ಅನ್ನು ಪ್ರತಿನಿಧಿಸುವ JSON ವಸ್ತುವಾಗಿದೆ (ಡಲ್ಸಿನಿಯಾ/ಹಸು) . HTTPS ಸ್ಥಿತಿ ಕೋಡ್ 201 (ಸಂಪನ್ಮೂಲವನ್ನು ರಚಿಸಲಾಗಿದೆ) ಕಳುಹಿಸುವ ಮೂಲಕ ವಿನಂತಿಯು ಯಶಸ್ವಿಯಾಗಿದೆ ಎಂದು ಸರ್ವರ್‌ನಿಂದ ಪ್ರತಿಕ್ರಿಯೆ ಸೂಚಿಸುತ್ತದೆ. GET ವಿಧಾನವು URI ಯಲ್ಲಿ ವಿನಂತಿಸಿದ ಸಂಪನ್ಮೂಲವನ್ನು ಮಾತ್ರ ನಿರ್ದಿಷ್ಟಪಡಿಸಬೇಕು (ಉದಾಹರಣೆಗೆ, /farm/animals/1), ಇದು ಸರ್ವರ್‌ನಿಂದ ಆ ID ಯೊಂದಿಗೆ ಪ್ರಾಣಿಗಳ JSON ಪ್ರಾತಿನಿಧ್ಯವನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ.
ಕೆಲವು ನಿರ್ದಿಷ್ಟ ಸಂಪನ್ಮೂಲ ದಾಖಲೆಯನ್ನು ನವೀಕರಿಸಬೇಕಾದಾಗ PUT ವಿಧಾನವನ್ನು ಬಳಸಲಾಗುತ್ತದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಸಂಪನ್ಮೂಲವು ಬದಲಾಯಿಸಬೇಕಾದ ನಿಯತಾಂಕ ಮತ್ತು ಪ್ರಸ್ತುತ ಮೌಲ್ಯಕ್ಕಾಗಿ URI ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ (ಉದಾಹರಣೆಗೆ, ಹಸು ಪ್ರಸ್ತುತ ನಡೆದುಕೊಂಡು ಹೋಗುತ್ತಿದೆ ಎಂದು ಸೂಚಿಸುತ್ತದೆ, /ಫಾರ್ಮ್/ಪ್ರಾಣಿಗಳು/1? ರಾಜ್ಯ=ವಾಕಿಂಗ್). ಅಂತಿಮವಾಗಿ, DELETE ವಿಧಾನವನ್ನು GET ವಿಧಾನಕ್ಕೆ ಸಮಾನವಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ, ಆದರೆ ಕಾರ್ಯಾಚರಣೆಯ ಪರಿಣಾಮವಾಗಿ ಸಂಪನ್ಮೂಲವನ್ನು ಸರಳವಾಗಿ ಅಳಿಸುತ್ತದೆ.
ಏಕ-ಪ್ರೋಟೋಕಾಲ್ ಪರಿಹಾರವಾಗಿ MQTT
ಅದೇ ಸ್ಮಾರ್ಟ್ ಫಾರ್ಮ್ ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳೋಣ, ಆದರೆ REST HTTP ಬದಲಿಗೆ ನಾವು MQTT ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ. ಸ್ಥಾಪಿಸಲಾದ ಸೊಳ್ಳೆ ಲೈಬ್ರರಿಯೊಂದಿಗೆ ಸ್ಥಳೀಯ ಸರ್ವರ್ ಬ್ರೋಕರ್ ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಈ ಉದಾಹರಣೆಯಲ್ಲಿ, ಸರಳವಾದ ಕಂಪ್ಯೂಟರ್ (ಫಾರ್ಮ್ ಸರ್ವರ್ ಎಂದು ಉಲ್ಲೇಖಿಸಲಾಗುತ್ತದೆ) ರಾಸ್ಪ್ಬೆರಿ ಪೈ MQTT ಕ್ಲೈಂಟ್ ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಇದನ್ನು Paho MQTT ಲೈಬ್ರರಿಯ ಸ್ಥಾಪನೆಯ ಮೂಲಕ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ, ಇದು ಸೊಳ್ಳೆ ಬ್ರೋಕರ್‌ನೊಂದಿಗೆ ಸಂಪೂರ್ಣವಾಗಿ ಹೊಂದಿಕೊಳ್ಳುತ್ತದೆ.
ಈ ಕ್ಲೈಂಟ್ ಸಂವೇದನಾ ಮತ್ತು ಕಂಪ್ಯೂಟಿಂಗ್ ಸಾಮರ್ಥ್ಯಗಳೊಂದಿಗೆ ಸಾಧನವನ್ನು ಪ್ರತಿನಿಧಿಸುವ IoT ಅಮೂರ್ತ ಪದರಕ್ಕೆ ಅನುರೂಪವಾಗಿದೆ. ಮತ್ತೊಂದೆಡೆ, ಮಧ್ಯವರ್ತಿಯು ಹೆಚ್ಚಿನ ಮಟ್ಟದ ಅಮೂರ್ತತೆಗೆ ಅನುರೂಪವಾಗಿದೆ, ಹೆಚ್ಚಿನ ಸಂಸ್ಕರಣೆ ಮತ್ತು ಶೇಖರಣಾ ಸಾಮರ್ಥ್ಯದಿಂದ ನಿರೂಪಿಸಲ್ಪಟ್ಟ ಮಂಜು ಕಂಪ್ಯೂಟಿಂಗ್ ನೋಡ್ ಅನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತದೆ.
ಪ್ರಸ್ತಾವಿತ ಸ್ಮಾರ್ಟ್ ಫಾರ್ಮ್ ಸನ್ನಿವೇಶದಲ್ಲಿ, ರಾಸ್ಪ್ಬೆರಿ ಪೈ ಅಕ್ಸೆಲೆರೊಮೀಟರ್, ಜಿಪಿಎಸ್ ಮತ್ತು ತಾಪಮಾನ ಸಂವೇದಕಗಳಿಗೆ ಸಂಪರ್ಕಿಸುತ್ತದೆ ಮತ್ತು ಈ ಸಂವೇದಕಗಳಿಂದ ಡೇಟಾವನ್ನು ಮಂಜು ನೋಡ್‌ಗೆ ಪ್ರಕಟಿಸುತ್ತದೆ. ನಿಮಗೆ ತಿಳಿದಿರುವಂತೆ, MQTT ವಿಷಯಗಳನ್ನು ಕ್ರಮಾನುಗತವಾಗಿ ಪರಿಗಣಿಸುತ್ತದೆ. ಒಂದೇ MQTT ಪ್ರಕಾಶಕರು ನಿರ್ದಿಷ್ಟ ವಿಷಯಗಳಿಗೆ ಸಂದೇಶಗಳನ್ನು ಪ್ರಕಟಿಸಬಹುದು. ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಅವುಗಳಲ್ಲಿ ಮೂರು ಇವೆ. ಪ್ರಾಣಿಗಳ ಕೊಟ್ಟಿಗೆಯಲ್ಲಿನ ತಾಪಮಾನವನ್ನು ಅಳೆಯುವ ಸಂವೇದಕಕ್ಕಾಗಿ, ಕ್ಲೈಂಟ್ ಒಂದು ಥೀಮ್ ಅನ್ನು ಆಯ್ಕೆಮಾಡುತ್ತದೆ (ಅನಿಮಲ್ಫಾರ್ಮ್/ಶೆಡ್/ತಾಪಮಾನ). ಅಕ್ಸೆಲೆರೊಮೀಟರ್ ಮೂಲಕ ಜಿಪಿಎಸ್ ಸ್ಥಳ ಮತ್ತು ಪ್ರಾಣಿಗಳ ಚಲನೆಯನ್ನು ಅಳೆಯುವ ಸಂವೇದಕಗಳಿಗಾಗಿ, ಕ್ಲೈಂಟ್ (ಅನಿಮಲ್ಫಾರ್ಮ್/ಪ್ರಾಣಿ/ಜಿಪಿಎಸ್) ಮತ್ತು (ಪ್ರಾಣಿ/ಪ್ರಾಣಿ/ಚಲನೆ) ಗೆ ನವೀಕರಣಗಳನ್ನು ಪ್ರಕಟಿಸುತ್ತದೆ.
ಈ ಮಾಹಿತಿಯನ್ನು ಬ್ರೋಕರ್‌ಗೆ ರವಾನಿಸಲಾಗುತ್ತದೆ, ಆಸಕ್ತ ಚಂದಾದಾರರು ನಂತರ ಬಂದರೆ ಅದನ್ನು ತಾತ್ಕಾಲಿಕವಾಗಿ ಸ್ಥಳೀಯ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಬಹುದು.
ಸ್ಥಳೀಯ ಸರ್ವರ್ ಜೊತೆಗೆ, ಇದು ಮಂಜಿನಲ್ಲಿ MQTT ಬ್ರೋಕರ್ ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ರಾಸ್ಪ್ಬೆರಿ ಪಿಸ್, MQTT ಕ್ಲೈಂಟ್ಗಳಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಸಂವೇದಕ ಡೇಟಾವನ್ನು ಕಳುಹಿಸುತ್ತದೆ, ಕ್ಲೌಡ್ ಮಟ್ಟದಲ್ಲಿ ಮತ್ತೊಂದು MQTT ಬ್ರೋಕರ್ ಇರಬಹುದು. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಸ್ಥಳೀಯ ಬ್ರೋಕರ್‌ಗೆ ರವಾನೆಯಾಗುವ ಮಾಹಿತಿಯನ್ನು ತಾತ್ಕಾಲಿಕವಾಗಿ ಸ್ಥಳೀಯ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಬಹುದು ಮತ್ತು/ಅಥವಾ ಕ್ಲೌಡ್‌ಗೆ ಕಳುಹಿಸಬಹುದು. ಈ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ ಮಂಜು MQTT ಬ್ರೋಕರ್ ಅನ್ನು ಕ್ಲೌಡ್ MQTT ಬ್ರೋಕರ್‌ನೊಂದಿಗೆ ಎಲ್ಲಾ ಡೇಟಾವನ್ನು ಸಂಯೋಜಿಸಲು ಬಳಸಲಾಗುತ್ತದೆ. ಈ ಆರ್ಕಿಟೆಕ್ಚರ್‌ನೊಂದಿಗೆ, ಮೊಬೈಲ್ ಅಪ್ಲಿಕೇಶನ್ ಬಳಕೆದಾರರನ್ನು ಎರಡೂ ಬ್ರೋಕರ್‌ಗಳಿಗೆ ಚಂದಾದಾರರಾಗಬಹುದು.
ಬ್ರೋಕರ್‌ಗಳಲ್ಲಿ ಒಬ್ಬರಿಗೆ (ಉದಾಹರಣೆಗೆ, ಕ್ಲೌಡ್) ಸಂಪರ್ಕವು ವಿಫಲವಾದರೆ, ಅಂತಿಮ ಬಳಕೆದಾರರು ಇತರರಿಂದ (ಮಂಜು) ಮಾಹಿತಿಯನ್ನು ಸ್ವೀಕರಿಸುತ್ತಾರೆ. ಇದು ಸಂಯೋಜಿತ ಮಂಜು ಮತ್ತು ಕ್ಲೌಡ್ ಕಂಪ್ಯೂಟಿಂಗ್ ವ್ಯವಸ್ಥೆಗಳ ವಿಶಿಷ್ಟ ಲಕ್ಷಣವಾಗಿದೆ. ಡೀಫಾಲ್ಟ್ ಆಗಿ, ಮೊದಲು ಮಂಜು MQTT ಬ್ರೋಕರ್‌ಗೆ ಸಂಪರ್ಕಿಸಲು ಮೊಬೈಲ್ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು ಮತ್ತು ಅದು ವಿಫಲವಾದರೆ, ಕ್ಲೌಡ್ MQTT ಬ್ರೋಕರ್‌ಗೆ ಸಂಪರ್ಕಿಸಲು. ಈ ಪರಿಹಾರವು IoT-F2C ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ಕೇವಲ ಒಂದು.
ಬಹು ಪ್ರೋಟೋಕಾಲ್ ಪರಿಹಾರಗಳು
ಏಕ ಪ್ರೋಟೋಕಾಲ್ ಪರಿಹಾರಗಳು ಅವುಗಳ ಸುಲಭವಾದ ಅನುಷ್ಠಾನದಿಂದಾಗಿ ಜನಪ್ರಿಯವಾಗಿವೆ. ಆದರೆ IoT-F2C ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ವಿಭಿನ್ನ ಪ್ರೋಟೋಕಾಲ್ಗಳನ್ನು ಸಂಯೋಜಿಸಲು ಇದು ಅರ್ಥಪೂರ್ಣವಾಗಿದೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ. ವಿಭಿನ್ನ ಪ್ರೋಟೋಕಾಲ್‌ಗಳು ವಿಭಿನ್ನ ಹಂತಗಳಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸಬಹುದು ಎಂಬುದು ಕಲ್ಪನೆ. ಉದಾಹರಣೆಗೆ, ಮೂರು ಅಮೂರ್ತತೆಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಿ: IoT, ಮಂಜು ಮತ್ತು ಕ್ಲೌಡ್ ಕಂಪ್ಯೂಟಿಂಗ್ ಪದರಗಳು. IoT ಮಟ್ಟದ ಸಾಧನಗಳನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಸೀಮಿತವೆಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ. ಈ ಅವಲೋಕನಕ್ಕಾಗಿ, IoT ಶ್ರೇಣಿಗಳನ್ನು ಅತ್ಯಂತ ನಿರ್ಬಂಧಿತ, ಕ್ಲೌಡ್ ಕಡಿಮೆ ನಿರ್ಬಂಧಿತ ಮತ್ತು ಮಂಜು ಕಂಪ್ಯೂಟಿಂಗ್ ಅನ್ನು "ಮಧ್ಯದಲ್ಲಿ ಎಲ್ಲೋ" ಎಂದು ಪರಿಗಣಿಸೋಣ. IoT ಮತ್ತು ಮಂಜು ಅಮೂರ್ತತೆಗಳ ನಡುವೆ, ಪ್ರಸ್ತುತ ಪ್ರೋಟೋಕಾಲ್ ಪರಿಹಾರಗಳಲ್ಲಿ MQTT, CoAP ಮತ್ತು XMPP ಸೇರಿವೆ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ. ಮಂಜು ಮತ್ತು ಮೋಡದ ನಡುವೆ, ಮತ್ತೊಂದೆಡೆ, AMQP REST HTTP ಜೊತೆಗೆ ಬಳಸಲಾಗುವ ಮುಖ್ಯ ಪ್ರೋಟೋಕಾಲ್‌ಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ, ಅದರ ನಮ್ಯತೆಯಿಂದಾಗಿ IoT ಮತ್ತು ಮಂಜು ಪದರಗಳ ನಡುವೆಯೂ ಇದನ್ನು ಬಳಸಲಾಗುತ್ತದೆ.
ಇಲ್ಲಿ ಮುಖ್ಯ ಸಮಸ್ಯೆ ಪ್ರೋಟೋಕಾಲ್ಗಳ ಪರಸ್ಪರ ಕಾರ್ಯಸಾಧ್ಯತೆ ಮತ್ತು ಒಂದು ಪ್ರೋಟೋಕಾಲ್ನಿಂದ ಇನ್ನೊಂದಕ್ಕೆ ಸಂದೇಶಗಳನ್ನು ವರ್ಗಾಯಿಸುವ ಸುಲಭವಾಗಿದೆ. ತಾತ್ತ್ವಿಕವಾಗಿ, ಭವಿಷ್ಯದಲ್ಲಿ, ಕ್ಲೌಡ್ ಮತ್ತು ಮಂಜು ಸಂಪನ್ಮೂಲಗಳೊಂದಿಗೆ ಇಂಟರ್ನೆಟ್ ಆಫ್ ಥಿಂಗ್ಸ್ ಸಿಸ್ಟಮ್ನ ಆರ್ಕಿಟೆಕ್ಚರ್ ಬಳಸಿದ ಸಂವಹನ ಪ್ರೋಟೋಕಾಲ್ನಿಂದ ಸ್ವತಂತ್ರವಾಗಿರುತ್ತದೆ ಮತ್ತು ವಿಭಿನ್ನ ಪ್ರೋಟೋಕಾಲ್ಗಳ ನಡುವೆ ಉತ್ತಮ ಪರಸ್ಪರ ಕಾರ್ಯಸಾಧ್ಯತೆಯನ್ನು ಖಚಿತಪಡಿಸುತ್ತದೆ.
ಇದು ಪ್ರಸ್ತುತವಲ್ಲದ ಕಾರಣ, ಗಮನಾರ್ಹ ವ್ಯತ್ಯಾಸಗಳನ್ನು ಹೊಂದಿರದ ಪ್ರೋಟೋಕಾಲ್ಗಳನ್ನು ಸಂಯೋಜಿಸಲು ಇದು ಅರ್ಥಪೂರ್ಣವಾಗಿದೆ. ಈ ನಿಟ್ಟಿನಲ್ಲಿ, ಒಂದು ಸಂಭಾವ್ಯ ಪರಿಹಾರವು ಒಂದೇ ವಾಸ್ತುಶಿಲ್ಪದ ಶೈಲಿಯನ್ನು ಅನುಸರಿಸುವ ಎರಡು ಪ್ರೋಟೋಕಾಲ್ಗಳ ಸಂಯೋಜನೆಯನ್ನು ಆಧರಿಸಿದೆ, REST HTTP ಮತ್ತು CoAP. ಮತ್ತೊಂದು ಪ್ರಸ್ತಾವಿತ ಪರಿಹಾರವು ಎರಡು ಪ್ರೋಟೋಕಾಲ್ಗಳ ಸಂಯೋಜನೆಯನ್ನು ಆಧರಿಸಿದೆ, ಅದು ಪ್ರಕಟಿಸಲು-ಚಂದಾದಾರರಾಗಲು ಸಂವಹನವನ್ನು ನೀಡುತ್ತದೆ, MQTT ಮತ್ತು AMQP. ಒಂದೇ ರೀತಿಯ ಪರಿಕಲ್ಪನೆಗಳನ್ನು ಬಳಸುವುದರಿಂದ (MQTT ಮತ್ತು AMQP ಎರಡೂ ಬ್ರೋಕರ್‌ಗಳನ್ನು ಬಳಸುತ್ತವೆ, CoAP ಮತ್ತು HTTP REST ಅನ್ನು ಬಳಸುತ್ತವೆ) ಈ ಸಂಯೋಜನೆಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಸುಲಭವಾಗುತ್ತದೆ ಮತ್ತು ಕಡಿಮೆ ಏಕೀಕರಣ ಪ್ರಯತ್ನದ ಅಗತ್ಯವಿರುತ್ತದೆ.
ಚಿತ್ರ (a) ಎರಡು ವಿನಂತಿ-ಪ್ರತಿಕ್ರಿಯೆ ಆಧಾರಿತ ಮಾದರಿಗಳನ್ನು ತೋರಿಸುತ್ತದೆ, HTTP ಮತ್ತು CoAP, ಮತ್ತು IoT-F2C ಪರಿಹಾರದಲ್ಲಿ ಅವುಗಳ ಸಂಭಾವ್ಯ ನಿಯೋಜನೆ. HTTP ಆಧುನಿಕ ನೆಟ್ವರ್ಕ್ಗಳಲ್ಲಿ ಅತ್ಯಂತ ಪ್ರಸಿದ್ಧವಾದ ಮತ್ತು ಅಳವಡಿಸಿಕೊಂಡ ಪ್ರೋಟೋಕಾಲ್‌ಗಳಲ್ಲಿ ಒಂದಾಗಿರುವುದರಿಂದ, ಅದನ್ನು ಇತರ ಸಂದೇಶ ಕಳುಹಿಸುವ ಪ್ರೋಟೋಕಾಲ್‌ಗಳಿಂದ ಸಂಪೂರ್ಣವಾಗಿ ಬದಲಾಯಿಸುವ ಸಾಧ್ಯತೆಯಿಲ್ಲ. ಮೋಡ ಮತ್ತು ಮಂಜಿನ ನಡುವೆ ಇರುವ ಶಕ್ತಿಯುತ ಸಾಧನಗಳನ್ನು ಪ್ರತಿನಿಧಿಸುವ ನೋಡ್‌ಗಳಲ್ಲಿ, REST HTTP ಒಂದು ಸ್ಮಾರ್ಟ್ ಪರಿಹಾರವಾಗಿದೆ.
ಮತ್ತೊಂದೆಡೆ, ಮಂಜು ಮತ್ತು IoT ಪದರಗಳ ನಡುವೆ ಸಂವಹನ ಮಾಡುವ ಸೀಮಿತ ಕಂಪ್ಯೂಟಿಂಗ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೊಂದಿರುವ ಸಾಧನಗಳಿಗೆ, CoAP ಅನ್ನು ಬಳಸುವುದು ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿದೆ. CoAP ಯ ಒಂದು ದೊಡ್ಡ ಪ್ರಯೋಜನವೆಂದರೆ ವಾಸ್ತವವಾಗಿ HTTP ಯೊಂದಿಗೆ ಅದರ ಹೊಂದಾಣಿಕೆಯಾಗಿದೆ, ಏಕೆಂದರೆ ಎರಡೂ ಪ್ರೋಟೋಕಾಲ್‌ಗಳು REST ತತ್ವಗಳನ್ನು ಆಧರಿಸಿವೆ.
ಚಿತ್ರ (b) MQTT ಮತ್ತು AMQP ಸೇರಿದಂತೆ ಒಂದೇ ಸನ್ನಿವೇಶದಲ್ಲಿ ಎರಡು ಪ್ರಕಟಣೆ-ಚಂದಾದಾರ ಸಂವಹನ ಮಾದರಿಗಳನ್ನು ತೋರಿಸುತ್ತದೆ. ಪ್ರತಿ ಅಮೂರ್ತ ಪದರದಲ್ಲಿ ನೋಡ್‌ಗಳ ನಡುವಿನ ಸಂವಹನಕ್ಕಾಗಿ ಎರಡೂ ಪ್ರೋಟೋಕಾಲ್ಗಳನ್ನು ಕಾಲ್ಪನಿಕವಾಗಿ ಬಳಸಬಹುದಾದರೂ, ಕಾರ್ಯಕ್ಷಮತೆಯ ಆಧಾರದ ಮೇಲೆ ಅವುಗಳ ಸ್ಥಾನವನ್ನು ನಿರ್ಧರಿಸಬೇಕು. MQTT ಅನ್ನು ಸೀಮಿತ ಕಂಪ್ಯೂಟಿಂಗ್ ಸಂಪನ್ಮೂಲಗಳೊಂದಿಗೆ ಸಾಧನಗಳಿಗೆ ಹಗುರವಾದ ಪ್ರೋಟೋಕಾಲ್ ಆಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ, ಆದ್ದರಿಂದ ಇದನ್ನು IoT-Fog ಸಂವಹನಕ್ಕಾಗಿ ಬಳಸಬಹುದು. AMQP ಹೆಚ್ಚು ಶಕ್ತಿಯುತ ಸಾಧನಗಳಿಗೆ ಹೆಚ್ಚು ಸೂಕ್ತವಾಗಿದೆ, ಇದು ಮಂಜು ಮತ್ತು ಮೋಡದ ನೋಡ್‌ಗಳ ನಡುವೆ ಆದರ್ಶಪ್ರಾಯವಾಗಿ ಇರಿಸುತ್ತದೆ. MQTT ಬದಲಿಗೆ, XMPP ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು IoT ನಲ್ಲಿ ಬಳಸಬಹುದು ಏಕೆಂದರೆ ಇದು ಹಗುರವೆಂದು ಪರಿಗಣಿಸಲಾಗಿದೆ. ಆದರೆ ಅಂತಹ ಸನ್ನಿವೇಶಗಳಲ್ಲಿ ಇದನ್ನು ವ್ಯಾಪಕವಾಗಿ ಬಳಸಲಾಗುವುದಿಲ್ಲ.
ಸಂಶೋಧನೆಗಳು
ಸೀಮಿತ ಕಂಪ್ಯೂಟಿಂಗ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೊಂದಿರುವ ಸಾಧನಗಳಿಂದ ಹಿಡಿದು ಕ್ಲೌಡ್ ಸರ್ವರ್‌ಗಳವರೆಗೆ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿನ ಎಲ್ಲಾ ಸಂವಹನಗಳನ್ನು ಒಳಗೊಳ್ಳಲು ಚರ್ಚಿಸಲಾದ ಪ್ರೋಟೋಕಾಲ್‌ಗಳಲ್ಲಿ ಒಂದು ಸಾಕಾಗುತ್ತದೆ ಎಂಬುದು ಅಸಂಭವವಾಗಿದೆ. ಡೆವಲಪರ್‌ಗಳು ಹೆಚ್ಚು ಬಳಸುವ ಎರಡು ಭರವಸೆಯ ಆಯ್ಕೆಗಳು MQTT ಮತ್ತು RESTful HTTP ಎಂದು ಅಧ್ಯಯನವು ಕಂಡುಹಿಡಿದಿದೆ. ಈ ಎರಡು ಪ್ರೋಟೋಕಾಲ್‌ಗಳು ಅತ್ಯಂತ ಪ್ರಬುದ್ಧ ಮತ್ತು ಸ್ಥಿರವಾಗಿರುವುದಲ್ಲದೆ, ಅನೇಕ ಉತ್ತಮವಾಗಿ ದಾಖಲಿಸಲಾದ ಮತ್ತು ಯಶಸ್ವಿ ಅನುಷ್ಠಾನಗಳು ಮತ್ತು ಆನ್‌ಲೈನ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಒಳಗೊಂಡಿವೆ.
ಅದರ ಸ್ಥಿರತೆ ಮತ್ತು ಸರಳ ಸಂರಚನೆಯಿಂದಾಗಿ, MQTT ಒಂದು ಪ್ರೋಟೋಕಾಲ್ ಆಗಿದ್ದು, ಸೀಮಿತ ಸಾಧನಗಳೊಂದಿಗೆ IoT ಮಟ್ಟದಲ್ಲಿ ಬಳಸಿದಾಗ ಅದರ ಉತ್ತಮ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಕಾಲಾನಂತರದಲ್ಲಿ ಸಾಬೀತುಪಡಿಸಿದೆ. ಕೆಲವು ಮಂಜು ಡೊಮೇನ್‌ಗಳು ಮತ್ತು ಹೆಚ್ಚಿನ ಕ್ಲೌಡ್ ಕಂಪ್ಯೂಟಿಂಗ್‌ನಂತಹ ಸೀಮಿತ ಸಂವಹನ ಮತ್ತು ಬ್ಯಾಟರಿ ಬಳಕೆ ಸಮಸ್ಯೆಯಾಗದ ವ್ಯವಸ್ಥೆಯ ಭಾಗಗಳಲ್ಲಿ, RESTful HTTP ಸುಲಭವಾದ ಆಯ್ಕೆಯಾಗಿದೆ. CoAP ಅನ್ನು ಸಹ ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಬೇಕು ಏಕೆಂದರೆ ಇದು IoT ಸಂದೇಶ ಕಳುಹಿಸುವಿಕೆಯ ಮಾನದಂಡವಾಗಿ ವೇಗವಾಗಿ ವಿಕಸನಗೊಳ್ಳುತ್ತಿದೆ ಮತ್ತು ಇದು ಮುಂದಿನ ದಿನಗಳಲ್ಲಿ MQTT ಮತ್ತು HTTP ಯಂತೆಯೇ ಸ್ಥಿರತೆ ಮತ್ತು ಪರಿಪಕ್ವತೆಯ ಮಟ್ಟವನ್ನು ತಲುಪುವ ಸಾಧ್ಯತೆಯಿದೆ. ಆದರೆ ಪ್ರಮಾಣಿತವು ಪ್ರಸ್ತುತ ವಿಕಸನಗೊಳ್ಳುತ್ತಿದೆ, ಇದು ಅಲ್ಪಾವಧಿಯ ಹೊಂದಾಣಿಕೆಯ ಸಮಸ್ಯೆಗಳೊಂದಿಗೆ ಬರುತ್ತದೆ.
ನೀವು ಬ್ಲಾಗ್‌ನಲ್ಲಿ ಇನ್ನೇನು ಓದಬಹುದು?
→
→
→
→
→
ನಮ್ಮ ಚಂದಾದಾರರಾಗಿ -ಚಾನೆಲ್, ಮುಂದಿನ ಲೇಖನವನ್ನು ಕಳೆದುಕೊಳ್ಳದಂತೆ! ನಾವು ವಾರಕ್ಕೆ ಎರಡು ಬಾರಿ ಹೆಚ್ಚು ಬರೆಯುವುದಿಲ್ಲ ಮತ್ತು ವ್ಯವಹಾರದಲ್ಲಿ ಮಾತ್ರ.
ಮೂಲ: www.habr.com