IoT, נעפּל און וואלקנס: לאָמיר רעדן וועגן טעכנאָלאָגיע?

די אַנטוויקלונג פון טעקנאַלאַדזשיז אין די פעלד פון ווייכווארג און ייַזנוואַרג, די ימערדזשאַנס פון נייַע קאָמוניקאַציע פּראָטאָקאָלס האָבן געפֿירט צו די יקספּאַנשאַן פון די אינטערנעט פון טהינגס (יאָט). די נומער פון דעוויסעס איז גראָוינג טאָג צו טאָג, און זיי דזשענערייט אַ ריזיק סומע פון ​​דאַטן. דעריבער, עס איז אַ נויט פֿאַר אַ באַקוועם סיסטעם אַרקאַטעקטשער וואָס איז ביכולת צו פּראַסעסינג, סטאָרינג און טראַנסמיטינג די דאַטן.

נאָוואַדייַס, וואָלקן באַדינונגס זענען געניצט פֿאַר די צוועקן. אָבער, די ינקריסינגלי פאָלקס נעפּל קאַמפּיוטינג (נעפּל) פּאַראַדיגם איז ביכולת צו דערגאַנג וואָלקן סאַלושאַנז דורך סקיילינג און אָפּטימיזינג די IoT ינפראַסטראַקטשער.

וואלקנס זענען ביכולת צו פאַרמאַכן רובֿ IoT ריקוועס. פֿאַר בייַשפּיל, צו צושטעלן מאָניטאָרינג פון סערוויסעס, שנעל פּראַסעסינג פון קיין סומע פון ​​דאַטן דזשענערייטאַד דורך דעוויסעס, ווי געזונט ווי זייער וויזשוואַלאַזיישאַן. נעפּל קאַמפּיוטינג איז מער עפעקטיוו אין סאַלווינג פאַקטיש-צייט פּראָבלעמס. זיי צושטעלן שנעל ענטפער צו ריקוועס און מינימאַל פאַרהאַלטן אין דאַטן פּראַסעסינג. אַז איז, נעפּל קאַמפּלאַמאַנץ די "וואָלקן", יקספּאַנדז זייַן קייפּאַבילאַטיז.

אָבער, די הויפּט קשיא איז אַנדערש: ווי זאָל אַלע דעם ינטעראַקט אין דעם קאָנטעקסט פון IoT? וואָס קאָמוניקאַציע פּראָטאָקאָלס וועט זיין מערסט עפעקטיוו ווען ארבעטן אין אַ יונאַפייד IoT-Fog-Cloud סיסטעם?

טראָץ די סימפּלי דאַמאַנאַנס פון הטטפּ, אַ גרויס נומער פון אנדערע סאַלושאַנז זענען געניצט אין IoT, Fog און קלאָוד סיסטעמען. דאָס איז ווייַל IoT מוזן פאַרבינדן די פאַנגקשאַנאַליטי פון אַ פאַרשיידנקייַט פון מיטל סענסאָרס מיט זיכערהייט, ינטעראָפּעראַביליטי און אנדערע באַניצער באדערפענישן.

אָבער עס איז פשוט קיין איין געדאַנק פון דער רעפֿערענץ אַרקאַטעקטשער און קאָמוניקאַציע נאָרמאַל. דערפֿאַר, קריייטינג אַ נייַע פּראָטאָקאָל אָדער מאָדיפיצירן אַ יגזיסטינג פּראָטאָקאָל פֿאַר ספּעציפיש IoT טאַסקס איז איינער פון די מערסט וויכטיק טאַסקס פֿאַר די IT קהל.

וואָס פּראָטאָקאָלס זענען דערווייַל אין נוצן און וואָס קענען זיי פאָרשלאָגן? זאל ס פיגור עס אויס. אָבער קודם, לאָמיר דיסקוטירן די פּרינציפּן פון אַן יקאָוסיסטאַם אין וואָס וואלקנס, נעפּל און די אינטערנעט פון טינגז ינטעראַקט.

יאָט נעפּל-צו-וואָלקן (F2C) אַרטשיטעקטורע

איר האָט מיסטאָמע באמערקט ווי פיל מי איז געשטעלט אין ויספאָרשן די בענעפיץ און בענעפיץ פֿאַרבונדן מיט די באַרדאַסדיק און קאָואָרדאַנייטיד פאַרוואַלטונג פון IoT, וואלקנס און נעפּל. אויב ניט, דאָ זענען דריי סטאַנדערדיזיישאַן ינישאַטיווז: OpenFog קאָנסאָרטיום, עדזש קאַמפּיוטינג קאָנסאָרטיום и mF2C H2020.

אויב פריער בלויז 2 לעוועלס זענען קאַנסידערד, וואלקנס און סוף דעוויסעס, די פארגעלייגט אַרקאַטעקטשער ינטראַדוסיז אַ נייַע מדרגה - נעפּל קאַמפּיוטינג. אין דער זעלביקער צייט, די נעפּל מדרגה קענען זיין צעטיילט אין עטלעכע סאַבלעוועלס, דיפּענדינג אויף די ספּיסיפיקס פון רעסורסן אָדער אַ גאַנג פון פּאַלאַסיז וואָס באַשטימען די נוצן פון פאַרשידענע דעוויסעס אין די סאַבלעוועלס.

וואָס קען דאָס אַבסטראַקציע קוקן ווי? דאָ איז אַ טיפּיש IoT-Fog-Cloud יקאָוסיסטאַם. IoT דעוויסעס שיקן דאַטן צו פאַסטער סערווערס און קאַמפּיוטינג דעוויסעס צו סאָלווע טאַסקס וואָס דאַרפן נידעריק לייטאַנסי. אין דער זעלביקער סיסטעם, וואלקנס זענען פאַראַנטוואָרטלעך פֿאַר סאַלווינג פּראָבלעמס וואָס דאַרפן אַ גרויס סומע פון ​​קאַמפּיוטינג רעסורסן אָדער סטאָרידזש פּלאַץ.

סמאַרטפאָנעס, סמאַרט וואַטשיז און אנדערע האַמצאָע קענען אויך זיין טייל פון די IoT. אָבער אַזאַ דעוויסעס טענד צו נוצן פּראַפּרייאַטערי קאָמוניקאַציע פּראָטאָקאָלס פון הויפּט דעוועלאָפּערס. די דזשענערייטאַד IoT דאַטן זענען דורכגעגאנגען צו די נעפּל שיכטע דורך די REST HTTP פּראָטאָקאָל, וואָס גיט בייגיקייַט און ינטעראָפּעראַביליטי ווען איר בויען RESTful באַדינונגס. דאָס איז וויכטיק אין ליכט פון די נויט צו ענשור צוריק קאַמפּאַטאַבילאַטי מיט יגזיסטינג קאַמפּיוטינג ינפראַסטראַקטשער פליסנדיק אויף היגע קאָמפּיוטערס, סערווערס אָדער אַ סערווער קנויל. לאקאלע רעסורסן, וואָס זענען גערופֿן "נעפּל נאָודז", פילטער די באקומען דאַטן און פּראָצעס עס לאָוקאַלי אָדער שיקן עס צו די וואָלקן פֿאַר ווייַטער חשבונות.

וואלקנס שטיצן פאַרשידענע קאָמוניקאַציע פּראָטאָקאָלס, צווישן וואָס AMQP און REST HTTP זענען די מערסט פּראָסט. זינט הטטפּ איז באַוווסט און שאַרפּאַנד פֿאַר די אינטערנעט, די קשיא קען זיין: "זאָל ניט זיין געוויינט צו אַרבעטן מיט IoT און נעפּל?". אָבער, דעם פּראָטאָקאָל האט פאָרשטעלונג ישוז. מער אויף דעם שפּעטער.

אין אַלגעמיין, עס זענען 2 מאָדעלס פון קאָמוניקאַציע פּראָטאָקאָלס פּאַסיק פֿאַר די סיסטעם מיר דאַרפֿן. די זענען בעטן-ענטפער און אַרויסגעבן-אַבאָנירן. דער ערשטער מאָדעל איז מער וויידלי באַוווסט, ספּעציעל אין די סערווער-קליענט אַרקאַטעקטשער. דער קליענט פארלאנגט אינפֿאָרמאַציע פון ​​די סערווער, און דער יענער נעמט די בעטן, פּראַסעסאַז עס און קערט אַ ענטפער אָנזאָג. REST HTTP און CoAP פּראָטאָקאָלס אַרבעט לויט דעם מאָדעל.

די צווייטע מאָדעל איז אויפגעשטאנען פון די נויט צו צושטעלן אַ ייסינגקראַנאַס, פונאנדערגעטיילט, פרייַ קאַפּלינג צווישן די קוואלן וואָס דזשענערייט דאַטן און די ריסיפּיאַנץ פון די דאַטן.

דער מאָדעל אַסומז דרייַ פּאַרטיסאַפּאַנץ: אַ אַרויסגעבער (דאַטן מקור), אַ מעקלער (דיספּאַטשער) און אַ אַבאָנענט (באַנעם). דאָ, דער קליענט אַקטינג ווי דער אַבאָנענט דאַרף נישט בעטן אינפֿאָרמאַציע פון ​​​​די סערווער. אַנשטאָט שיקן ריקוועס, עס אַבאָנירן צו זיכער געשעענישן אין די סיסטעם דורך אַ מעקלער פאַראַנטוואָרטלעך פֿאַר פילטערינג אַלע ינקאַמינג אַרטיקלען און רוטינג זיי צווישן פֿאַרלאַגן און אבאנענטן. און דער אַרויסגעבער, ווען אַ געשעעניש אַקערז שייַכות צו אַ זיכער טעמע, פּאַבלישאַז עס צו די מעקלער, וואָס סענדז דאַטן צו די אַבאָנענט אויף די געבעטן טעמע.

יסענשאַלי, דעם אַרקאַטעקטשער איז באזירט אויף געשעענישן. און דעם ינטעראַקשאַן מאָדעל איז טשיקאַווע פֿאַר אַפּלאַקיישאַנז אין IoT, וואָלקן, נעפּל ווייַל פון זיין פיייקייט צו צושטעלן סקאַלאַביליטי און פאַרפּאָשעטערן די ינטערקאַנעקשאַן צווישן פאַרשידענע דעוויסעס, שטיצן פילע-צו-פילע דינאַמיש קאָמוניקאַציע און ייסינגקראַנאַס קאָמוניקאַציע. עטלעכע פון ​​​​די מערסט באַוווסט סטאַנדערדייזד אַרויסגעבן-אַבאָנירן מעסידזשינג פּראָטאָקאָלס אַרייַננעמען MQTT, AMQP און DDS.

דאָך, די אַרויסגעבן-אַבאָנירן מאָדעל האט אַ פּלאַץ פון אַדוואַנטידזשיז:

• פֿאַרלאַגן און אבאנענטן דאַרפֿן ניט וויסן וועגן יעדער אנדערע ס עקזיסטענץ;
• איין אבאנענט קען באַקומען אינפֿאָרמאַציע פון ​​פילע פאַרשידענע אויסגאבעס, און איין אַרויסגעבער קענען שיקן דאַטן צו פילע פאַרשידענע אבאנענטן (פילע-צו-פילע פּרינציפּ);
• דער אַרויסגעבער און אַבאָנענט טאָן ניט דאַרפֿן צו זיין אַקטיוו אין דער זעלביקער צייט צו וועקסל דאַטן, ווייַל דער מעקלער (אַקטינג ווי אַ ריי סיסטעם) וועט קענען צו קראָם דעם אָנזאָג פֿאַר קלייאַנץ וואָס זענען נישט קאָננעקטעד צו די נעץ.

אָבער, די בעטן-ענטפער מאָדעל אויך האט זייַן סטרענגקטס. אין קאַסעס ווען די פיייקייט פון די סערווער זייַט צו פּראָצעס ריקוועס פון קייפל קלייאַנץ איז נישט אַ פּראָבלעם, עס איז זינען צו נוצן שוין פּראָווען פאַרלאָזלעך סאַלושאַנז.

עס זענען אויך פּראָטאָקאָלס וואָס שטיצן ביידע מאָדעלס. פֿאַר בייַשפּיל, XMPP און HTTP 2.0 שטיצן די "סערווער שטופּן" אָפּציע. די IETF האט אויך באפרייט די CoAP. עטלעכע אנדערע סאַלושאַנז זענען באשאפן אין אַן פּרווון צו סאָלווע די מעסידזשינג פּראָבלעם, אַזאַ ווי די וועבסאָקקעץ פּראָטאָקאָל אָדער ניצן די הטטפּ פּראָטאָקאָל איבער QUIC (Quick UDP Internet Connections).

אין דעם פאַל פון WebSockets, כאָטש עס איז געניצט צו אַריבערפירן דאַטן אין פאַקטיש צייט פון די סערווער צו די וועב קליענט און גיט פּערסיסטענט קאַנעקשאַנז מיט סיימאַלטייניאַס ביידירעקטיאָנאַל קאָמוניקאַציע, עס איז נישט בדעה פֿאַר דעוויסעס מיט לימיטעד קאַמפּיוטינג רעסורסן. QUIC אויך פארדינט ופמערקזאַמקייט, ווייַל די נייַ אַריבערפירן פּראָטאָקאָל גיט אַ פּלאַץ פון נייַע פֿעיִקייטן. אָבער זינט QUIC איז נאָך נישט סטאַנדערדייזד, עס איז צו פרי צו פאָרויסזאָגן זיין מעגלעך אַפּלאַקיישאַן און פּראַל אויף IoT סאַלושאַנז. אַזוי מיר לאָזן WebSockets און QUIC אין זכּרון מיט אַן אויג צו דער צוקונפֿט, אָבער מיר וועלן נישט לערנען אין מער דעטאַל נאָך.

ווער איז די קיוטיסט אין דער וועלט: קאַמפּערינג פּראָטאָקאָלס

איצט לאָזן ס רעדן וועגן די סטרענגקטס און וויקנאַסאַז פון פּראָטאָקאָלס. קוקן פאָרויס, מיר וועלן מיד מאַכן אַ רעזערוואַציע אַז עס איז קיין איין קלאָר פירער. יעדער פּראָטאָקאָל האט עטלעכע אַדוואַנידזשיז / דיסאַדוואַנטידזשיז.

ענטפער צייט

איינער פון די מערסט וויכטיק קעראַקטעריסטיקס פון קאָמוניקאַציע פּראָטאָקאָלס, ספּעציעל אין באַציונג צו די אינטערנעט פון טינגז, איז די ענטפער צייט. אָבער צווישן די יגזיסטינג פּראָטאָקאָלס, עס איז קיין קלאָר געווינער וואָס דעמאַנסטרייץ די מינימום מדרגה פון פאַרהאַלטן ווען ארבעטן אין פאַרשידענע טנאָים. אבער עס איז אַ גאַנץ בינטל פון שטודיום און קאַמפּעראַסאַנז פון פּראָטאָקאָל קייפּאַבילאַטיז.

פֿאַר בייַשפּיל, פיינדינגז קאַמפּעראַסאַנז פון די יפעקטיוונאַס פון HTTP און MQTT ווען ארבעטן מיט IoT געוויזן אַז די ענטפער צייט פֿאַר ריקוועס פֿאַר MQTT איז ווייניקער ווי פֿאַר HTTP. און ווען לערנען ארום-יאַזדע צייט (RTT) פון MQTT און CoAP, עס פארקערט אויס אַז די דורכשניטלעך RTT פון CoAP איז 20% ווייניקער ווי די פון MQTT.

אנדערע אַן עקספּערימענט מיט RTT פֿאַר די MQTT און CoAP פּראָטאָקאָלס איז דורכגעקאָכט אין צוויי סינעריאָוז: אַ היגע נעץ און אַן IoT נעץ. עס פארקערט אויס אַז די דורכשניטלעך RTT איז 2-3 מאל העכער אין די IoT נעץ. MQTT מיט QoS0 געוויזן אַ נידעריקער רעזולטאַט קאַמפּערד מיט CoAP, און MQTT מיט QoS1 געוויזן אַ העכער RTT דאַנק צו ACKs ביי די אַפּלאַקיישאַן און אַריבערפירן לייַערס. פֿאַר פאַרשידענע QoS לעוועלס, נעץ דילייז אָן קאַנדזשעסטשאַן זענען מיליסעקאַנדז פֿאַר MQTT, און הונדערטער פון מיקראָסעקאָנדס פֿאַר CoAP. אָבער, עס איז ווערט געדענקען אַז ווען ארבעטן אין ווייניקער פאַרלאָזלעך נעטוואָרקס, MQTT פליסנדיק איבער TCP וועט ווייַזן אַ גאָר אַנדערש רעזולטאַט.

פאַרגלייַך די ענטפער צייט פון די AMQP און MQTT פּראָטאָקאָלס דורך ינקריסינג די פּיילאָוד געוויזן אַז מיט אַ קליין מאַסע, די פאַרהאַלטן מדרגה איז כּמעט די זעלבע. אָבער ווען טראַנספערינג גרויס אַמאַונץ פון דאַטן, MQTT ווייזט אַ נידעריקער ענטפער צייט. אין איינער מער לערנען קאָאַפּ איז געווען קאַמפּערד מיט הטטפּ אין אַ מאַשין-צו-מאַשין סצענאַר מיט דעוויסעס דיפּלויד אויף שפּיץ פון וועהיקלעס יקוויפּט מיט גאַז סענסאָרס, וועטער סענסאָרס, אָרט (גפּס) און רירעוודיק נעץ צובינד (GPRS). די צייט וואָס עס האָט געדויערט צו שיקן אַ קאָאַפּ אָנזאָג איבער די רירעוודיק נעץ איז כּמעט דריי מאָל קירצער ווי די צייט וואָס עס האָט געדויערט צו נוצן HTTP אַרטיקלען.

שטודיום האָבן שוין געפירט אַז קאַמפּערד ניט צוויי, אָבער דריי פּראָטאָקאָלס. למשל, פאַרגלייַך פאָרשטעלונג פון IoT פּראָטאָקאָלס MQTT, DDS און CoAP אין אַ מעדיציניש אַפּלאַקיישאַן סצענאַר ניצן אַ נעץ עמולאַטאָר. DDS האט אַוטפּערפאָרמד MQTT אין טערמינען פון טעלעמעטרי לייטאַנסי טעסטעד אונטער פאַרשידן נעבעך נעץ טנאָים. UDP-באזירט קאָאַפּ געארבעט געזונט פֿאַר אַפּלאַקיישאַנז וואָס דאַרפֿן אַ שנעל ענטפער, אָבער ווייַל פון UDP-באזירט, עס איז געווען אַ באַטייטיק אַנפּרידיקטאַבאַל פּאַקאַט אָנווער.

טרופּוט

פאַרגלייַך MQTT און CoAP אין טערמינען פון באַנדווידט עפעקטיווקייַט איז דורכגעקאָכט ווי אַ כעזשבן פון די גאַנץ סומע פון ​​דאַטן טראַנסמיטטעד פּער אָנזאָג. קאָאַפּ געוויזן ווייניקער טרופּוט ווי MQTT פֿאַר קליין אַרטיקלען. אָבער ווען קאַמפּערינג די עפעקטיווקייַט פון פּראָטאָקאָלס אין טערמינען פון די פאַרהעלטעניש פון די נומער פון נוציק אינפֿאָרמאַציע ביטעס צו די גאַנץ נומער פון טראַנסמיטטעד ביטעס, קאָאַפּ איז געווען מער עפעקטיוו.

בייַ אַנאַליסיס טרופּוט ניצן MQTT, DDS (מיט TCP ווי די אַריבערפירן פּראָטאָקאָל), און CoAP געפֿונען אַז CoAP טענדיד צו ווייַזן קאַמפּעראַטיוולי נידעריקער באַנדווידט קאַנסאַמשאַן, וואָס איז נישט געוואקסן מיט געוואקסן נעץ פּאַקאַט אָנווער אָדער געוואקסן נעץ לייטאַנסי, ניט ענלעך MQTT און DDS, ווו אין די דערמאנט. סינעריאָוז עס איז געווען אַ פאַרגרעסערן אין באַנדווידט באַניץ. אן אנדער סצענאַר ינוואַלווד אַ גרויס נומער פון דעוויסעס טראַנסמיטינג דאַטן אין דער זעלביקער צייט, וואָס איז אַ טיפּיש פאַל אין IoT ינווייראַנמאַנץ. די רעזולטאַטן האָבן געוויזן אַז פֿאַר העכער לאָודינג עס איז בעסער צו נוצן CoAP.

אונטער ליכט מאַסע, CoAP געוויינט די מינדסטער באַנדווידט, נאכגעגאנגען דורך MQTT און REST HTTP. אָבער, ווי די גרייס פון די פּיילאָודז געוואקסן, REST HTTP האט די בעסטער רעזולטאַטן.

מאַכט קאָנסומפּטיאָן

די אַרויסגעבן פון ענערגיע קאַנסאַמשאַן איז שטענדיק פון גרויס וויכטיקייט, און ספּעציעל אין די IoT סיסטעם. אויב פאַרגלייַכן מאַכט קאַנסאַמשאַן פון MQTT און HTTP, הטטפּ "עסט" פיל מער. און CoAP איז מער ענערגיע עפעקטיוו קאַמפּערד צו MQTT, אַלאַוינג מאַכט פאַרוואַלטונג. אין דער זעלביקער צייט, אין פּשוט סינעריאָוז, MQTT איז מער פּאַסיק פֿאַר אינפֿאָרמאַציע וועקסל אין אינטערנעט פון טהינגס נעטוואָרקס, ספּעציעל אויב עס זענען קיין מאַכט ריסטריקשאַנז.

אנדערע אַן עקספּערימענט וואָס קאַמפּערד AMQP און MQTT קייפּאַבילאַטיז אויף אַ רירעוודיק אָדער אַנסטייבאַל וויירליס נעץ פּרובירן באַנק געוויזן אַז AMQP אָפפערס מער זיכערהייט פֿעיִקייטן, בשעת MQTT איז מער ענערגיע עפעקטיוו.

זיכערקייַט

זיכערהייט איז אן אנדער הויפּט אַרויסגעבן אין די לערנען פון די אינטערנעט פון טהינגס און נעפּל / וואָלקן קאַמפּיוטינג. די זיכערהייט מעקאַניזאַם איז טיפּיקלי באזירט אויף TLS אין HTTP, MQTT, AMQP און XMPP, אָדער DTLS אין CoAP, און שטיצט ביידע DDS אָפּציעס.

TLS און DTLS אָנהייבן מיט דעם פּראָצעס פון גרינדן אַ פֿאַרבינדונג צווישן די קליענט און די סערווער זייטן צו וועקסל שטיצט סייפער סוויץ און שליסלען. ביידע פּאַרטיעס פאַרהאַנדלען שטעלט צו ענשור אַז ווייַטער קאָמוניקאַציע נעמט אָרט אין אַ זיכער קאַנאַל. דער חילוק צווישן די צוויי איז אַ קליין מאָדיפיקאַטיאָן וואָס אַלאַוז UDP-באזירט DTLS צו אַרבעטן איבער אַ אַנרילייאַבאַל קשר.

בייַ פּרובירן אנפאלן אויף עטלעכע פאַרשידענע ימפּלאַמאַנץ פון TLS און DTLS, עס איז געווען אַז TLS האט אַ בעסער אַרבעט. אַטאַקס אויף DTLS האָבן שוין מער געראָטן רעכט צו זיין טעות טאָלעראַנץ.

אָבער, די ביגאַסט פּראָבלעם מיט די פּראָטאָקאָלס איז אַז זיי זענען נישט ערידזשנאַלי דיזיינד פֿאַר נוצן אין IoT און זענען נישט געמיינט צו אַרבעטן אין נעפּל אָדער וואָלקן. דורך כאַנדשאַקינג, זיי לייגן נאָך פאַרקער מיט יעדער קשר פאַרלייגן, וואָס דריינז קאַמפּיוטינג רעסורסן. אין דורכשניטלעך, עס איז אַ פאַרגרעסערן פון 6,5% פֿאַר TLS און 11% פֿאַר DTLS אין אָוווערכעד קאַמפּערד מיט קאָמוניקאַציע אָן אַ זיכערהייט שיכטע. אין מיטל-רייַך ינווייראַנמאַנץ וואָס זענען טיפּיקלי ליגן אויף פאַרוואָלקנט דער מדרגה, דאָס וועט נישט זיין אַ פּראָבלעם, אָבער רעכט צו דער שייכות צווישן IoT און נעפּל מדרגה, דאָס ווערט אַ וויכטיק באַגרענעצונג.

וואָס צו קלייַבן? עס איז קיין איין ענטפער. MQTT און HTTP ויסקומען צו זיין די מערסט פּראַמאַסינג פּראָטאָקאָלס ווייַל זיי זענען גערעכנט ווי לעפיערעך מער דערוואַקסן און מער סטאַביל IoT סאַלושאַנז ווי אנדערע פּראָטאָקאָלס.

סאַלושאַנז באזירט אויף אַ איין קאָמוניקאַציע פּראָטאָקאָל

די פיר פון אַ איין פּראָטאָקאָל לייזונג האט פילע דיסאַדוואַנטידזשיז. פֿאַר בייַשפּיל, אַ פּראָטאָקאָל וואָס איז פּאַסיק פֿאַר אַ לימיטעד סוויווע קען נישט אַרבעטן אין אַ פעלד וואָס האט שטרענג זיכערהייט רעקווירעמענץ. מיט דעם אין זינען, מיר זענען לינקס צו אַוועקוואַרפן כּמעט אַלע מעגלעך איין-פּראָטאָקאָל סאַלושאַנז אין די נעפּל-צו-וואָלקן יקאָוסיסטאַם אין IoT, אַחוץ פֿאַר MQTT און REST HTTP.

רעסט הטטפּ ווי אַ איין פּראָטאָקאָל לייזונג

עס איז אַ גוט בייַשפּיל פון REST HTTP בעטן / ענטפער ינטעראַקשאַן אין די IoT-to-Fog מעלוכע: קלוג פאַרם. אַנימאַלס זענען יקוויפּט מיט וועראַבאַל סענסאָרס (IOT קליענט, C) און געראטן דורך וואָלקן קאַמפּיוטינג דורך אַ קלוג פאַרמינג סיסטעם (נעפּל סערווער, S).

די POST מעטאָד כעדער ספּעציפיצירט די מיטל צו מאָדיפיצירן (/ פאַרם / אַנימאַלס), ווי געזונט ווי די HTTP ווערסיע און אינהאַלט טיפּ, וואָס אין דעם פאַל איז אַ JSON כייפעץ וואָס רעפּראַזענץ די כייַע פאַרם וואָס די סיסטעם זאָל פירן (Dulcinea / קו). דער ענטפער פון די סערווער ינדיקייץ אַז די בקשה איז געווען געראָטן מיט אַ HTTPS 201 (ריסאָרס באשאפן) סטאַטוס קאָד. דער GET אופֿן זאָל בלויז ספּעציפיצירן די געבעטן מיטל אין די URI (למשל, / פאַרם / אַנימאַלס / 1), וואָס קערט אַ JSON פאַרטרעטונג פון די כייַע מיט דעם שייַן פֿון די סערווער.

די PUT אופֿן איז געניצט ווען עטלעכע ספּעציפיש מיטל רעקאָרד דאַרף זיין דערהייַנטיקט. אין דעם פאַל, די מיטל ספּעציפיצירט די URI פֿאַר די פּאַראַמעטער צו זיין געביטן און די קראַנט ווערט (למשל, ינדיקייץ אַז די קו איז איצט גיין, /פאַרם/אַנימאַלס/1? שטאַט=גיין). צום סוף, די DELETE אופֿן איז געניצט אין דער זעלביקער וועג ווי די GET אופֿן, אָבער פשוט דיליץ די מיטל ווי אַ רעזולטאַט פון די אָפּעראַציע.

MQTT ווי אַ איין פּראָטאָקאָל לייזונג

לאָמיר נעמען די זעלבע קלוג פאַרם, אָבער אַנשטאָט פון REST HTTP מיר נוצן די MQTT פּראָטאָקאָל. די היגע סערווער מיט די Mosquitto ביבליאָטעק אינסטאַלירן אקטן ווי אַ מעקלער. אין דעם בייַשפּיל, אַ פּשוט קאָמפּיוטער (ריפערד צו ווי דער פאַרם סערווער) Raspberry Pi סערוועס ווי אַ MQTT קליענט, ימפּלאַמענאַד דורך די ינסטאַלירונג פון די Paho MQTT ביבליאָטעק, וואָס איז גאָר קאַמפּאַטאַבאַל מיט די Mosquitto מעקלער.

דער קליענט קאַנפאָרמז צו די IoT אַבסטראַקציע שיכטע רעפּריזענטינג אַ מיטל מיט ופדעקונג און קאַמפּיוטינג קייפּאַבילאַטיז. די מעדיאַטאָר, אויף די אנדערע האַנט, קאָראַספּאַנדז צו אַ העכער מדרגה פון אַבסטראַקציע, רעפּריזענטינג אַ נעפּל קאַמפּיוטינג נאָדע, קעראַקטערייזד דורך גרויס פּראַסעסינג און סטאָרידזש קאַפּאַציטעט.

אין די פארגעלייגט קלוג פאַרם סצענאַר, אַ Raspberry Pi קאַנעקץ צו אַ אַקסעלעראַמאַטער, גפּס און טעמפּעראַטור סענסאָרס און פּאַבלישאַז די דאַטן פון די סענסאָרס צו אַ נעפּל נאָדע. ווי איר מיסטאָמע וויסן, MQTT באהאנדלט טעמעס ווי אַ כייעראַרקי. איין MQTT אַרויסגעבער קענען אַרויסגעבן אַרטיקלען צו אַ ספּעציפיש גאַנג פון טעמעס. אין אונדזער פאַל, עס זענען דרייַ. פֿאַר די סענסער וואָס מעסטן די טעמפּעראַטור אין די כייַע אָפּדאַך, דער קונה סאַלעקץ אַ טעמע (אַנימאַלפאַרם / אָפּדאַך / טעמפּעראַטור). פֿאַר סענסאָרס וואָס מעסטן גפּס אָרט און כייַע באַוועגונג דורך די אַקסעלעראַמאַטער, דער קליענט וועט אַרויסגעבן דערהייַנטיקונגען צו (אַנימאַלפאַרם / כייַע / גפּס) און (אַנימאַלפאַרם / כייַע / באַוועגונג).

די אינפֿאָרמאַציע וועט זיין שערד מיט דער מעקלער, וואָס קען טעמפּערעראַלי קראָם עס אין אַ היגע דאַטאַבייס אין פאַל אן אנדער אינטערעסירט אַבאָנענט וועט דערשייַנען שפּעטער.

אין אַדישאַן צו די היגע סערווער וואָס אַקערז ווי אַ MQTT מעקלער אין די נעפּל און צו וואָס די Raspberry Pi, אַקטינג ווי MQTT קלייאַנץ, שיקן דאַטן פון סענסאָרס, עס קען זיין אן אנדער MQTT מעקלער אויף די וואָלקן מדרגה. אין דעם פאַל, די אינפֿאָרמאַציע טראַנסמיטטעד צו די היגע מעקלער קען זיין טעמפּערעראַלי סטאָרד אין אַ היגע דאַטאַבייס און / אָדער געשיקט צו די וואָלקן. דער וואָלקן MQTT מעקלער אין דעם סיטואַציע איז געניצט צו פֿאַרבינדונג אַלע דאַטן צו די וואָלקן MQTT מעקלער. מיט דעם אַרקאַטעקטשער, אַ רירעוודיק אַפּלאַקיישאַן באַניצער קענען זיין אַבאָנירן צו ביידע בראָקערס.

אין דער געשעעניש פון אַ פֿאַרבינדונג דורכפאַל מיט איינער פון די בראָקערס (למשל, וואָלקן), דער סוף באַניצער וועט באַקומען אינפֿאָרמאַציע פון ​​אנדערן (נעפּלדיק). דאָס איז אַ כאַראַקטעריסטיש שטריך פון קאַמביינד נעפּל און וואָלקן קאַמפּיוטינג סיסטעמען. דורך פעליקייַט, די רירעוודיק אַפּ קענען זיין קאַנפיגיערד צו ערשטער פאַרבינדן צו די נעפּלדיק MQTT מעקלער, און אויב נישט, צו פאַרבינדן צו די וואָלקן MQTT מעקלער. די לייזונג איז בלויז איינער פון פילע אין IoT-F2C סיסטעמען.

מולטיפּראָטאָקאָל סאַלושאַנז

איין פּראָטאָקאָל סאַלושאַנז זענען פאָלקס ווייַל פון זייער גרינגער ימפּלאַמענטיישאַן. אָבער עס איז קלאָר ווי דער טאָג אַז אין IoT-F2C סיסטעמען עס איז זינען צו פאַרבינדן פאַרשידענע פּראָטאָקאָלס. די פונט איז אַז פאַרשידענע פּראָטאָקאָלס קענען אַרבעטן אין פאַרשידענע לעוועלס. נעמען, למשל, דריי אַבסטראַקציעס: IoT, נעפּל און וואָלקן קאַמפּיוטינג לייַערס. דעוויסעס אויף די IoT מדרגה זענען בכלל גערעכנט ווי לימיטעד. פֿאַר דעם איבערבליק, לאָמיר קוקן אין IoT לייַערס ווי די מערסט ריסטריקטיוו, וואָלקן-באזירט קלענסטער ריסטריקטיוו, און נעפּל קאַמפּיוטינג ווי "ערגעץ אין צווישן". דערנאָך עס טורנס אויס אַז צווישן IoT און נעפּל אַבסטראַקציעס, קראַנט פּראָטאָקאָל סאַלושאַנז אַרייַננעמען MQTT, CoAP און XMPP. צווישן נעפּל און וואָלקן, אויף די אנדערע האַנט, AMQP איז איינער פון די הויפּט פּראָטאָקאָלס געניצט צוזאַמען מיט REST HTTP, וואָס רעכט צו זיין בייגיקייט איז אויך געניצט צווישן IoT און נעפּל לייַערס.

דער הויפּט פּראָבלעם דאָ איז די ינטעראָפּעראַביליטי פון פּראָטאָקאָלס און די יז פון טראַנספערינג אַרטיקלען פון איין פּראָטאָקאָל צו אנדערן. ידעאַללי, אין דער צוקונפֿט, די אַרקאַטעקטשער פון די IoT סיסטעם מיט וואָלקן און נעפּל רעסורסן וועט זיין פרייַ פון די געוויינט קאָמוניקאַציע פּראָטאָקאָל און וועט ענשור גוט ינטעראָפּעראַביליטי פון פאַרשידענע פּראָטאָקאָלס.

זינט דאָס איז נישט דער פאַל אין דעם מאָמענט, עס מאכט זינען צו צונויפגיסן פּראָטאָקאָלס וואָס טאָן ניט האָבן באַטייַטיק דיפעראַנסיז. צו דעם סוף, איין פּאָטענציעל לייזונג איז באזירט אויף אַ קאָמבינאַציע פון ​​​​צוויי פּראָטאָקאָלס וואָס נאָכגיין די זעלבע אַרקאַטעקטשעראַל סטיל, REST HTTP און CoAP. אן אנדער פארגעלייגט לייזונג איז באזירט אויף אַ קאָמבינאַציע פון ​​​​צוויי פּראָטאָקאָלס וואָס פאָרשלאָגן אַרויסגעבן-אַבאָנירן ינטעראַקשאַן, MQTT און AMQP. ניצן ענלעך קאַנסעפּס (ביידע MQTT און AMQP נוצן בראָקערס, CoAP און HTTP נוצן REST) ​​מאכט די קאַמבאַניישאַנז גרינגער צו ינסטרומענט און ריקווייערז ווייניקער ינאַגריישאַן מי.

פיגור (אַ) ווייזט צוויי בעטן-ענטפער מאָדעלס, הטטפּ און קאָאַפּ, און זייער מעגלעך פּלייסמאַנט אין אַן IoT-F2C לייזונג. זינט הטטפּ איז איינער פון די מערסט באַוווסט און אנגענומען פּראָטאָקאָלס אין הייַנט ס נעטוואָרקס, עס איז אַנלייקלי אַז עס וועט זיין גאָר ריפּלייסט דורך אנדערע מעסידזשינג פּראָטאָקאָלס. צווישן די נאָודז וואָס רעפּריזענטינג שטאַרק דעוויסעס צווישן וואָלקן און נעפּל, REST HTTP איז אַ גלייַך לייזונג.

אויף די אנדערע האַנט, פֿאַר קאַמפּיוטישאַנאַלי קאַנסטריינד דעוויסעס וואָס יבערגעבן צווישן נעפּל און IoT לייַערס, עס איז מער עפעקטיוו צו נוצן CoAP. איינער פון די גרויס אַדוואַנטידזשיז פון CoAP איז די קאַמפּאַטאַבילאַטי מיט הטטפּ, ווייַל ביידע פּראָטאָקאָלס זענען באזירט אויף REST פּרינסאַפּאַלז.

פיגורע (ב) ווייזט צוויי אַרויסגעבן-אַבאָנירן ינטעראַקשאַן מאָדעלס אין דער זעלביקער סצענאַר, אַרייַנגערעכנט MQTT און AMQP. כאָטש כייפּאַטעטיקלי ביידע פּראָטאָקאָלס קען זיין געוויינט צו יבערגעבן צווישן נאָודז אין יעדער מדרגה פון אַבסטראַקציע, זייער שטעלע זאָל זיין באשלאסן באזירט אויף פאָרשטעלונג. MQTT איז דיזיינד ווי אַ לייטווייט פּראָטאָקאָל פֿאַר דעוויסעס מיט לימיטעד קאַמפּיוטינג רעסורסן, אַזוי עס קענען זיין געוויינט צו יבערגעבן צווישן IoT און נעפּל. AMQP איז מער פּאַסיק פֿאַר מער שטאַרק דעוויסעס וואָס יידילי שטעלן עס צווישן נעפּל און וואָלקן נאָודז. אַנשטאָט MQTT אין IoT, איר קענען נוצן די XMPP פּראָטאָקאָל, ווייַל עס איז גערעכנט ווי לייטווייט. אבער עס איז נישט וויידלי געניצט אין אַזאַ סינעריאָוז.

פיינדינגז

עס איז אַנלייקלי אַז איינער פון די באַטראַכט פּראָטאָקאָלס וועט זיין גענוג צו דעקן אַלע קאָמוניקאַציע אין די סיסטעם, פֿון דעוויסעס מיט לימיטעד קאַמפּיוטינג רעסורסן צו וואָלקן סערווערס. די לערנען געוויזן אַז די צוויי מערסט פּראַמאַסינג אָפּציעס וואָס דעוועלאָפּערס נוצן מער אָפט זענען MQTT און RESTful HTTP. די צוויי פּראָטאָקאָלס זענען נישט בלויז די מערסט דערוואַקסן און סטאַביל, אָבער אויך אַרייַננעמען פילע געזונט-דאַקיאַמענטאַד און געראָטן ימפּלאַמאַנץ און אָנליין רעסורסן.

רעכט צו זיין פעסטקייַט און פּשוט קאַנפיגיעריישאַן, MQTT איז אַ פּראָטאָקאָל וואָס האט פּראָווען זיין העכער פאָרשטעלונג איבער צייַט ווען געוויינט אין די IoT שיכטע מיט לימיטעד דעוויסעס. אין פּאַרץ פון די סיסטעם ווו לימיטעד קאַנעקטיוויטי און באַטאַרייע קאַנסאַמשאַן זענען נישט אַן אַרויסגעבן, אַזאַ ווי עטלעכע נעפּל געביטן און רובֿ וואָלקן קאַמפּיוטינג, RESTful HTTP איז אַן גרינג ברירה. קאָאַפּ זאָל אויך זיין גענומען אין חשבון ווייַל עס איז אויך ראַפּאַדלי יוואַלווינג ווי אַ IoT מעסידזשינג נאָרמאַל און עס איז מסתּמא אַז עס וועט דערגרייכן אַ מדרגה פון פעסטקייַט און צייַטיקייַט ענלעך צו MQTT און HTTP אין דעם לעבן צוקונפֿט. אָבער דער נאָרמאַל איז איצט יוואַלווינג, וואָס קומט מיט קורץ-טערמין קאַמפּאַטאַבילאַטי ישוז.

וואָס אַנדערש קענען איר לייענען אויף דעם בלאָג? Cloud4Y

→ דער קאָמפּיוטער וועט מאַכן איר געשמאַק
→ אַי העלפּס צו לערנען די אַנימאַלס פון אפריקע
→ זומער איז כּמעט איבער. עס איז כּמעט קיין אַנליקט דאַטן לינקס
→ 4 וועגן צו ראַטעווען אויף וואָלקן באַקאַפּס
→ אויף אַ יונאַפייד פעדעראלע אינפֿאָרמאַציע מיטל מיט אינפֿאָרמאַציע וועגן די באַפעלקערונג

אַבאָנירן צו אונדזער טעלעגראַם-קאַנאַל, אַזוי נישט צו פאַרפירן דעם ווייַטער אַרטיקל! מיר שרייַבן ניט מער ווי צוויי מאָל אַ וואָך און בלויז אויף געשעפט.

מקור: www.habr.com