IoT អ័ព្ទ និងពពក៖ តោះនិយាយពីបច្ចេកវិទ្យា?

ការអភិវឌ្ឍន៍នៃបច្ចេកវិទ្យាក្នុងវិស័យសូហ្វវែរ និងផ្នែករឹង ការលេចចេញនូវពិធីការទំនាក់ទំនងថ្មីបាននាំទៅដល់ការពង្រីកអ៊ីនធឺណិតនៃអ្វីៗ (IoT) ។ ចំនួនឧបករណ៍កំពុងកើនឡើងពីមួយថ្ងៃទៅមួយថ្ងៃ ហើយពួកគេកំពុងបង្កើតទិន្នន័យយ៉ាងច្រើន។ ដូច្នេះហើយ វាមានតម្រូវការសម្រាប់ស្ថាបត្យកម្មប្រព័ន្ធងាយស្រួលដែលមានសមត្ថភាពដំណើរការ រក្សាទុក និងបញ្ជូនទិន្នន័យនេះ។

ឥឡូវនេះសេវាពពកត្រូវបានប្រើប្រាស់សម្រាប់គោលបំណងទាំងនេះ។ ទោះជាយ៉ាងណាក៏ដោយ គំរូកុំព្យូទ័រអ័ព្ទ (Fog) ដែលមានប្រជាប្រិយភាពកាន់តែខ្លាំងឡើងអាចបំពេញបន្ថែមដំណោះស្រាយលើពពកដោយការធ្វើមាត្រដ្ឋាន និងធ្វើឱ្យហេដ្ឋារចនាសម្ព័ន្ធ IoT ប្រសើរឡើង។

ពពកមានសមត្ថភាពគ្របដណ្តប់លើសំណើ IoT ភាគច្រើន។ ឧទាហរណ៍ ដើម្បីផ្តល់ការត្រួតពិនិត្យសេវាកម្ម ដំណើរការលឿននៃទិន្នន័យណាមួយដែលបង្កើតឡើងដោយឧបករណ៍ ក៏ដូចជាការមើលឃើញរបស់ពួកគេ។ ការគណនាអ័ព្ទមានប្រសិទ្ធភាពជាងនៅពេលដោះស្រាយបញ្ហាក្នុងពេលជាក់ស្តែង។ ពួកគេផ្តល់នូវការឆ្លើយតបយ៉ាងរហ័សចំពោះសំណើ និងភាពយឺតយ៉ាវតិចតួចបំផុតក្នុងដំណើរការទិន្នន័យ។ នោះគឺ Fog បំពេញបន្ថែម "ពពក" និងពង្រីកសមត្ថភាពរបស់វា។

ទោះជាយ៉ាងណាក៏ដោយ សំណួរចម្បងគឺខុសគ្នា៖ តើទាំងអស់នេះគួរធ្វើអន្តរកម្មយ៉ាងដូចម្តេចនៅក្នុងបរិបទនៃ IoT? តើពិធីការទំនាក់ទំនងអ្វីនឹងមានប្រសិទ្ធភាពបំផុតនៅពេលធ្វើការនៅក្នុងប្រព័ន្ធ IoT-Fog-Cloud រួមបញ្ចូលគ្នា?

ទោះបីជាមានភាពលេចធ្លោនៃ HTTP ក៏ដោយ ក៏វាមានដំណោះស្រាយមួយចំនួនធំផ្សេងទៀតដែលប្រើនៅក្នុងប្រព័ន្ធ IoT, Fog និង Cloud ។ នេះគឺដោយសារតែ IoT ត្រូវតែរួមបញ្ចូលគ្នានូវមុខងារនៃឧបករណ៍ចាប់សញ្ញាឧបករណ៍ផ្សេងៗជាមួយនឹងសុវត្ថិភាព ភាពត្រូវគ្នា និងតម្រូវការផ្សេងទៀតរបស់អ្នកប្រើប្រាស់។

ប៉ុន្តែមិនមានគំនិតតែមួយអំពីស្ថាបត្យកម្មយោង និងស្តង់ដារទំនាក់ទំនងទេ។ ដូច្នេះហើយ ការបង្កើតពិធីការថ្មី ឬកែប្រែដែលមានស្រាប់សម្រាប់កិច្ចការ IoT ជាក់លាក់ គឺជាកិច្ចការសំខាន់បំផុតមួយដែលប្រឈមមុខនឹងសហគមន៍ IT ។

តើពិធីការអ្វីខ្លះដែលកំពុងប្រើប្រាស់ ហើយតើពួកគេអាចផ្តល់អ្វីខ្លះ? ចូរយើងដោះស្រាយវា។ ប៉ុន្តែជាដំបូង ចូរយើងពិភាក្សាអំពីគោលការណ៍នៃប្រព័ន្ធអេកូ ដែលពពក អ័ព្ទ និងអ៊ីនធឺណិតនៃវត្ថុមានអន្តរកម្ម។

ស្ថាបត្យកម្ម IoT Fog-to-Cloud (F2C)

អ្នកប្រហែលជាបានកត់សម្គាល់ឃើញថា តើមានការខិតខំប្រឹងប្រែងច្រើនប៉ុណ្ណាក្នុងការស្វែងរកអត្ថប្រយោជន៍ និងអត្ថប្រយោជន៍ដែលទាក់ទងនឹងការគ្រប់គ្រងឆ្លាតវៃ និងការសម្របសម្រួលនៃ IoT, cloud និងអ័ព្ទ។ បើមិនដូច្នោះទេ ខាងក្រោមនេះជាគំនិតផ្តួចផ្តើមស្តង់ដារចំនួនបី៖ សម្ព័ន្ធ OpenFog, Edge Computing Consortium и mF2C H2020 គម្រោង EU.

ប្រសិនបើពីមុនមានតែ 2 កម្រិតប៉ុណ្ណោះដែលត្រូវបានពិចារណា ពពក និងឧបករណ៍បញ្ចប់ នោះស្ថាបត្យកម្មដែលបានស្នើឡើងនឹងណែនាំកម្រិតថ្មីមួយ - កុំព្យូទ័រអ័ព្ទ។ ក្នុងករណីនេះ កម្រិតអ័ព្ទអាចត្រូវបានបែងចែកទៅជាកម្រិតរងជាច្រើន អាស្រ័យលើភាពជាក់លាក់នៃធនធាន ឬសំណុំនៃគោលនយោបាយដែលកំណត់ការប្រើប្រាស់ឧបករណ៍ផ្សេងៗនៅក្នុងកម្រិតរងទាំងនេះ។

តើអរូបីនេះអាចមើលទៅដូចអ្វី? នេះគឺជាប្រព័ន្ធអេកូ IoT-Fog-Cloud ធម្មតា។ ឧបករណ៍ IoT បញ្ជូនទិន្នន័យទៅកាន់ម៉ាស៊ីនមេ និងឧបករណ៍កុំព្យូទ័រដែលលឿនជាងមុន ដើម្បីដោះស្រាយបញ្ហាដែលទាមទារភាពយឺតយ៉ាវទាប។ នៅក្នុងប្រព័ន្ធដូចគ្នា Clouds ទទួលខុសត្រូវក្នុងការដោះស្រាយបញ្ហាដែលត្រូវការធនធានកុំព្យូទ័រច្រើន ឬទំហំផ្ទុកទិន្នន័យ។

ស្មាតហ្វូន នាឡិកាឆ្លាតវៃ និងឧបករណ៍ផ្សេងទៀតក៏អាចជាផ្នែកមួយនៃ IoT ផងដែរ។ ប៉ុន្តែឧបករណ៍បែបនេះជាក្បួនប្រើពិធីការទំនាក់ទំនងដែលមានកម្មសិទ្ធិពីអ្នកអភិវឌ្ឍន៍ធំ ៗ ។ ទិន្នន័យ IoT ដែលបានបង្កើតត្រូវបានផ្ទេរទៅស្រទាប់អ័ព្ទតាមរយៈពិធីការ REST HTTP ដែលផ្តល់នូវភាពបត់បែន និងអន្តរប្រតិបត្តិការនៅពេលបង្កើតសេវាកម្ម RESTful ។ នេះមានសារៈសំខាន់ដោយសារតម្រូវការដើម្បីធានាភាពឆបគ្នាថយក្រោយជាមួយហេដ្ឋារចនាសម្ព័ន្ធកុំព្យូទ័រដែលមានស្រាប់ដែលកំពុងដំណើរការលើកុំព្យូទ័រ បណ្តាញម៉ាស៊ីនមេ ឬចង្កោមម៉ាស៊ីនមេ។ ធនធានក្នុងស្រុក ហៅថា "ថ្នាំងអ័ព្ទ" ត្រងទិន្នន័យដែលទទួលបាន ហើយដំណើរការវាក្នុងមូលដ្ឋាន ឬផ្ញើវាទៅពពកសម្រាប់ការគណនាបន្ថែម។

Clouds គាំទ្រពិធីការទំនាក់ទំនងផ្សេងៗគ្នា ដែលទូទៅបំផុតគឺ AMQP និង REST HTTP ។ ចាប់តាំងពី HTTP ត្រូវបានគេស្គាល់យ៉ាងច្បាស់ និងត្រូវបានកែសម្រួលសម្រាប់អ៊ីនធឺណិត សំណួរអាចកើតឡើង៖ "តើយើងគួរប្រើវាដើម្បីធ្វើការជាមួយ IoT និងអ័ព្ទមែនទេ?" ទោះយ៉ាងណាក៏ដោយ ពិធីការនេះមានបញ្ហាដំណើរការ។ បន្ថែមទៀតអំពីរឿងនេះនៅពេលក្រោយ។

ជាទូទៅមាន 2 គំរូនៃពិធីការទំនាក់ទំនងដែលសមរម្យសម្រាប់ប្រព័ន្ធដែលយើងត្រូវការ។ ទាំងនេះគឺជាការស្នើសុំ-ឆ្លើយតប និងបោះពុម្ពផ្សាយ-ជាវ។ គំរូទីមួយត្រូវបានគេស្គាល់យ៉ាងទូលំទូលាយ ជាពិសេសនៅក្នុងស្ថាបត្យកម្មម៉ាស៊ីនមេ។ ម៉ាស៊ីនភ្ញៀវស្នើសុំព័ត៌មានពីម៉ាស៊ីនមេ ហើយម៉ាស៊ីនមេទទួលសំណើ ដំណើរការវា និងត្រឡប់សារឆ្លើយតប។ ពិធីការ REST HTTP និង CoAP ដំណើរការលើគំរូនេះ។

គំរូទីពីរកើតឡើងពីតម្រូវការក្នុងការផ្តល់នូវការភ្ជាប់អសមកាល ការចែកចាយ និងរលុងរវាងប្រភពដែលបង្កើតទិន្នន័យ និងអ្នកទទួលទិន្នន័យនេះ។

គំរូសន្មតថាអ្នកចូលរួមបីនាក់៖ អ្នកបោះពុម្ពផ្សាយ (ប្រភពទិន្នន័យ) ឈ្មួញកណ្តាល (អ្នកបញ្ជូន) និងអតិថិជន (អ្នកទទួល) ។ នៅទីនេះ អតិថិជនដែលដើរតួជាអតិថិជនមិនចាំបាច់ស្នើសុំព័ត៌មានពីម៉ាស៊ីនមេទេ។ ជំនួសឱ្យការផ្ញើសំណើ វាជាវព្រឹត្តិការណ៍មួយចំនួននៅក្នុងប្រព័ន្ធតាមរយៈឈ្មួញកណ្តាល ដែលទទួលខុសត្រូវក្នុងការត្រងសារចូលទាំងអស់ និងបញ្ជូនវារវាងអ្នកបោះពុម្ពផ្សាយ និងអ្នកជាវ។ ហើយអ្នកបោះពុម្ពផ្សាយ នៅពេលដែលព្រឹត្តិការណ៍មួយកើតឡើងទាក់ទងនឹងប្រធានបទជាក់លាក់មួយ បោះពុម្ពវាទៅឈ្មួញកណ្តាល ដែលផ្ញើទិន្នន័យលើប្រធានបទដែលបានស្នើសុំទៅកាន់អតិថិជន។

សំខាន់ ស្ថាបត្យកម្មនេះគឺផ្អែកលើព្រឹត្តិការណ៍។ ហើយគំរូអន្តរកម្មនេះគឺគួរឱ្យចាប់អារម្មណ៍សម្រាប់កម្មវិធីនៅក្នុង IoT, cloud, fog ដោយសារតែសមត្ថភាពរបស់វាក្នុងការផ្តល់នូវលទ្ធភាពធ្វើមាត្រដ្ឋាន និងសម្រួលដល់ការភ្ជាប់ទំនាក់ទំនងរវាងឧបករណ៍ផ្សេងៗគ្នា គាំទ្រការទំនាក់ទំនងពីច្រើនទៅច្រើន និងទំនាក់ទំនងអសមកាល។ ពិធីការផ្ញើសារស្ដង់ដារល្បីបំផុតមួយចំនួនដែលប្រើគំរូបោះពុម្ពផ្សាយ-ជាវរួមមាន MQTT, AMQP និង DDS ។

ជាក់ស្តែង ម៉ូដែល Publish-Subscribe មានអត្ថប្រយោជន៍ជាច្រើន៖

• អ្នកបោះពុម្ពផ្សាយ និងអតិថិជនមិនចាំបាច់ដឹងអំពីអត្ថិភាពរបស់គ្នាទៅវិញទៅមក;
• អតិថិជនម្នាក់អាចទទួលបានព័ត៌មានពីការបោះពុម្ពផ្សេងៗគ្នាជាច្រើន ហើយអ្នកបោះពុម្ពផ្សាយម្នាក់អាចផ្ញើទិន្នន័យទៅកាន់អតិថិជនផ្សេងៗគ្នាជាច្រើន (គោលការណ៍ពីច្រើនទៅច្រើន);
• អ្នកបោះពុម្ពផ្សាយ និងអ្នកជាវ មិនចាំបាច់សកម្មក្នុងពេលតែមួយដើម្បីទំនាក់ទំនងទេ ព្រោះឈ្មួញកណ្តាល (ធ្វើការជាប្រព័ន្ធតម្រង់ជួរ) នឹងអាចរក្សាទុកសារសម្រាប់អតិថិជនដែលមិនទាន់បានភ្ជាប់ទៅបណ្តាញ។

ទោះជាយ៉ាងណាក៏ដោយ គំរូឆ្លើយតបសំណើក៏មានចំណុចខ្លាំងរបស់វាដែរ។ ក្នុងករណីដែលសមត្ថភាពរបស់ភាគីម៉ាស៊ីនមេក្នុងការដោះស្រាយសំណើអតិថិជនច្រើនមិនមែនជាបញ្ហា វាសមហេតុផលក្នុងការប្រើដំណោះស្រាយដែលអាចទុកចិត្តបាន និងច្បាស់លាស់។

វាក៏មានពិធីការដែលគាំទ្រម៉ូដែលទាំងពីរផងដែរ។ ឧទាហរណ៍ XMPP និង HTTP 2.0 ដែលគាំទ្រជម្រើស "ការជំរុញម៉ាស៊ីនមេ" ។ IETF ក៏បានចេញផ្សាយ CoAP ផងដែរ។ នៅក្នុងការប៉ុនប៉ងដើម្បីដោះស្រាយបញ្ហាការផ្ញើសារ ដំណោះស្រាយផ្សេងទៀតជាច្រើនត្រូវបានបង្កើតឡើង ដូចជាពិធីការ WebSockets ឬការប្រើប្រាស់ពិធីការ HTTP លើ QUIC (Quick UDP Internet Connections)។

ក្នុងករណី WebSockets ទោះបីជាវាត្រូវបានប្រើដើម្បីផ្ទេរទិន្នន័យក្នុងពេលវេលាជាក់ស្តែងពីម៉ាស៊ីនមេទៅម៉ាស៊ីនភ្ញៀវគេហទំព័រ និងផ្តល់នូវការតភ្ជាប់ជាប់លាប់ជាមួយនឹងការទំនាក់ទំនងទ្វេទិសក្នុងពេលដំណាលគ្នាក៏ដោយ វាមិនមានបំណងសម្រាប់ឧបករណ៍ដែលមានធនធានកុំព្យូទ័រមានកម្រិតនោះទេ។ QUIC ក៏សមនឹងទទួលបានការយកចិត្តទុកដាក់ផងដែរ ចាប់តាំងពីពិធីសារដឹកជញ្ជូនថ្មីផ្តល់នូវឱកាសថ្មីៗជាច្រើន។ ប៉ុន្តែដោយសារ QUIC មិន​ទាន់​មាន​ស្តង់ដារ វា​ជា​រឿង​ទាន់​ពេល​វេលា​ក្នុង​ការ​ទស្សន៍ទាយ​កម្មវិធី​ដែល​អាច​ធ្វើ​ទៅ​បាន និង​ផល​ប៉ះពាល់​លើ​ដំណោះស្រាយ IoT។ ដូច្នេះ យើងរក្សា WebSockets និង QUIC ក្នុងចិត្តដោយសម្លឹងមើលទៅអនាគត ប៉ុន្តែយើងនឹងមិនសិក្សាវាឱ្យលម្អិតបន្ថែមទៀតសម្រាប់ពេលនេះទេ។

តើអ្នកណាដែលគួរឱ្យស្រលាញ់បំផុតនៅក្នុងពិភពលោក: ការប្រៀបធៀបពិធីការ

ឥឡូវនេះសូមនិយាយអំពីចំណុចខ្លាំង និងចំណុចខ្សោយនៃពិធីការ។ ក្រឡេកមើលទៅមុខ អនុញ្ញាតឱ្យយើងធ្វើការកក់ទុកភ្លាមៗថាមិនមានអ្នកដឹកនាំច្បាស់លាស់ទេ។ ពិធីការនីមួយៗមានគុណសម្បត្តិ/គុណវិបត្តិមួយចំនួន។

ពេលវេលាឆ្លើយតប

លក្ខណៈសំខាន់បំផុតមួយនៃពិធីការទំនាក់ទំនង ជាពិសេសទាក់ទងនឹង Internet of Things គឺជាពេលវេលាឆ្លើយតប។ ប៉ុន្តែក្នុងចំណោមពិធីការដែលមានស្រាប់ មិនមានអ្នកឈ្នះច្បាស់លាស់ដែលបង្ហាញពីកម្រិតអប្បបរមានៃភាពយឺតយ៉ាវនៅពេលធ្វើការក្រោមលក្ខខណ្ឌផ្សេងៗ។ ប៉ុន្តែមានក្រុមទាំងមូលនៃការស្រាវជ្រាវ និងការប្រៀបធៀបសមត្ថភាពពិធីការ។

ឧទាហរណ៍ ការរកប្រាក់ចំណូល ការប្រៀបធៀបប្រសិទ្ធភាពនៃ 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 បង្ហាញពីពេលវេលាឆ្លើយតបខ្លីជាង។ នៅក្នុងមួយបន្ថែមទៀត ការស្រាវជ្រាវ CoAP ត្រូវបានគេប្រៀបធៀបទៅនឹង HTTP នៅក្នុងសេណារីយ៉ូទំនាក់ទំនងពីម៉ាស៊ីនមួយទៅម៉ាស៊ីន ជាមួយនឹងឧបករណ៍ដែលត្រូវបានដាក់ពង្រាយនៅលើកំពូលរថយន្តដែលបំពាក់ដោយឧបករណ៍ចាប់សញ្ញាឧស្ម័ន ឧបករណ៍ចាប់សញ្ញាអាកាសធាតុ ឧបករណ៍ចាប់សញ្ញាទីតាំង (GPS) និងចំណុចប្រទាក់បណ្តាញទូរស័ព្ទចល័ត (GPRS) ។ ពេលវេលាដែលត្រូវការដើម្បីបញ្ជូនសារ CoAP លើបណ្តាញទូរស័ព្ទគឺខ្លីជាងពេលវេលាដែលត្រូវការដើម្បីប្រើសារ HTTP ជិតបីដង។

ការសិក្សាត្រូវបានធ្វើឡើងដែលប្រៀបធៀបមិនមែនពីរទេប៉ុន្តែពិធីការបី។ ឧទាហរណ៍, ការប្រៀបធៀប ដំណើរការនៃពិធីការ IoT MQTT, DDS និង CoAP នៅក្នុងសេណារីយ៉ូកម្មវិធីវេជ្ជសាស្រ្តដោយប្រើកម្មវិធីត្រាប់តាមបណ្តាញ។ DDS បានដំណើរការជាង MQTT ទាក់ទងនឹងភាពយឺតនៃតេឡេម៉ែត្រដែលបានសាកល្បងក្រោមលក្ខខណ្ឌបណ្តាញមិនល្អជាច្រើន។ CoAP ដែលមានមូលដ្ឋានលើ UDP ដំណើរការបានល្អសម្រាប់កម្មវិធីដែលទាមទារពេលវេលាឆ្លើយតបរហ័ស ប៉ុន្តែដោយសារតែវាផ្អែកលើ UDP មានការខាតបង់កញ្ចប់ព័ត៌មានដែលមិនអាចទាយទុកជាមុនបាន។

កម្រិតបញ្ជូន

ប្រៀបធៀប MQTT និង CoAP នៅក្នុងលក្ខខណ្ឌនៃប្រសិទ្ធភាពកម្រិតបញ្ជូនត្រូវបានអនុវត្តជាការគណនានៃចំនួនសរុបនៃទិន្នន័យដែលបានបញ្ជូនក្នុងមួយសារ។ CoAP បានបង្ហាញលំហូរទាបជាង MQTT នៅពេលបញ្ជូនសារតូចៗ។ ប៉ុន្តែនៅពេលប្រៀបធៀបប្រសិទ្ធភាពនៃពិធីការក្នុងន័យសមាមាត្រនៃចំនួនបៃព័ត៌មានដែលមានប្រយោជន៍ទៅនឹងចំនួនសរុបនៃបៃដែលបានផ្ទេរ CoAP បានប្រែក្លាយថាមានប្រសិទ្ធភាពជាង។

នៅ ការវិភាគ ដោយប្រើ MQTT, DDS (ជាមួយ TCP ជាពិធីការដឹកជញ្ជូន) និង CoAP bandwidth វាត្រូវបានគេរកឃើញថា CoAP ជាទូទៅបង្ហាញពីការប្រើប្រាស់កម្រិតបញ្ជូនទាបជាងប្រៀបធៀប ដែលមិនកើនឡើងជាមួយនឹងការកើនឡើងនៃការបាត់បង់កញ្ចប់ព័ត៌មានបណ្តាញ ឬការកើនឡើងភាពយឺតនៃបណ្តាញ មិនដូច MQTT និង DDS ដែលមាន ការកើនឡើងនៃការប្រើប្រាស់កម្រិតបញ្ជូននៅក្នុងសេណារីយ៉ូដែលបានរៀបរាប់។ សេណារីយ៉ូមួយទៀតពាក់ព័ន្ធនឹងឧបករណ៍មួយចំនួនធំដែលបញ្ជូនទិន្នន័យក្នុងពេលដំណាលគ្នា ដែលមានលក្ខណៈធម្មតានៅក្នុងបរិស្ថាន IoT ។ លទ្ធផលបានបង្ហាញថា សម្រាប់ការប្រើប្រាស់កាន់តែខ្ពស់ វាជាការប្រសើរក្នុងការប្រើប្រាស់ CoAP ។

នៅក្រោមបន្ទុកស្រាល CoAP បានប្រើកម្រិតបញ្ជូនតិចបំផុត បន្ទាប់មកដោយ MQTT និង REST HTTP ។ ទោះជាយ៉ាងណាក៏ដោយនៅពេលដែលទំហំនៃបន្ទុកកើនឡើង REST HTTP ទទួលបានលទ្ធផលល្អបំផុត។

ការប្រើប្រាស់ថាមពល

បញ្ហានៃការប្រើប្រាស់ថាមពលតែងតែមានសារៈសំខាន់ខ្លាំង ហើយជាពិសេសនៅក្នុងប្រព័ន្ធ IoT។ ប្រសិនបើ ប្រៀបធៀប ខណៈពេលដែល MQTT និង HTTP ប្រើប្រាស់អគ្គិសនី HTTP ប្រើប្រាស់កាន់តែច្រើន។ ហើយ CoAP គឺច្រើនទៀត ថាមពលមានប្រសិទ្ធភាព បើប្រៀបធៀបទៅនឹង MQTT ដែលអនុញ្ញាតឱ្យមានការគ្រប់គ្រងថាមពល។ ទោះជាយ៉ាងណាក៏ដោយ នៅក្នុងសេណារីយ៉ូសាមញ្ញ MQTT គឺសមរម្យជាងសម្រាប់ការផ្លាស់ប្តូរព័ត៌មាននៅក្នុងបណ្តាញ Internet of Things ជាពិសេសប្រសិនបើមិនមានការរឹតបន្តឹងថាមពល។

ផ្សេងទៀត ការពិសោធន៍ដែលប្រៀបធៀបសមត្ថភាពរបស់ AMQP និង MQTT នៅលើបណ្តាញទូរស័ព្ទចល័ត ឬបណ្តាញឥតខ្សែដែលមិនស្ថិតស្ថេរបានសាកល្បងបានរកឃើញថា AMQP ផ្តល់នូវសមត្ថភាពសុវត្ថិភាពកាន់តែច្រើន ខណៈដែល MQTT មានប្រសិទ្ធភាពថាមពលជាង។

សន្តិសុខ

សុវត្ថិភាពគឺជាបញ្ហាសំខាន់មួយទៀតដែលបានលើកឡើងនៅពេលសិក្សាប្រធានបទនៃ Internet of Things និងកុំព្យូទ័រលើពពក/ពពក។ យន្តការសុវត្ថិភាពជាធម្មតាផ្អែកលើ TLS នៅក្នុង HTTP, MQTT, AMQP និង XMPP ឬ DTLS នៅក្នុង CoAP ហើយគាំទ្រវ៉ារ្យ៉ង់ DDS ទាំងពីរ។

TLS និង DTLS ចាប់ផ្តើមជាមួយនឹងដំណើរការនៃការបង្កើតទំនាក់ទំនងរវាងអតិថិជន និងភាគីម៉ាស៊ីនមេ ដើម្បីផ្លាស់ប្តូរឈុតអក្សរសម្ងាត់ និងសោដែលគាំទ្រ។ ភាគីទាំងពីរចរចាគ្នាដើម្បីធានាថាការទំនាក់ទំនងបន្ថែមទៀតកើតឡើងនៅលើបណ្តាញសុវត្ថិភាព។ ភាពខុសគ្នារវាងទាំងពីរស្ថិតនៅក្នុងការកែប្រែតូចៗដែលអនុញ្ញាតឱ្យ DTLS ដែលមានមូលដ្ឋានលើ UDP ធ្វើការលើការតភ្ជាប់ដែលមិនគួរឱ្យទុកចិត្ត។

នៅ សាកល្បងការវាយប្រហារ ការអនុវត្តផ្សេងគ្នាជាច្រើននៃ TLS និង DTLS បានរកឃើញថា TLS ធ្វើការងារបានប្រសើរជាងមុន។ ការវាយប្រហារលើ DTLS ទទួលបានជោគជ័យជាងមុន ដោយសារការអត់ធ្មត់ចំពោះកំហុសរបស់វា។

ទោះជាយ៉ាងណាក៏ដោយ បញ្ហាដ៏ធំបំផុតជាមួយពិធីការទាំងនេះគឺថា ពួកវាមិនត្រូវបានរចនាដើមឡើយសម្រាប់ប្រើប្រាស់នៅក្នុង IoT ហើយមិនមានបំណងធ្វើការនៅក្នុងអ័ព្ទ ឬពពកនោះទេ។ តាមរយៈការចាប់ដៃគ្នា ពួកគេបានបន្ថែមចរាចរណ៍បន្ថែមជាមួយនឹងការតភ្ជាប់នីមួយៗ ដែលធ្វើឲ្យបាត់បង់ធនធានកុំព្យូទ័រ។ ជាមធ្យម មានការកើនឡើង 6,5% សម្រាប់ TLS និង 11% សម្រាប់ DTLS លើសពីការទំនាក់ទំនង បើធៀបនឹងការទំនាក់ទំនងដោយគ្មានស្រទាប់សុវត្ថិភាព។ នៅក្នុងបរិស្ថានសម្បូរធនធាន ដែលជាធម្មតាមានទីតាំងនៅលើ ពពក កម្រិតនេះនឹងមិនមានបញ្ហានោះទេ ប៉ុន្តែនៅក្នុងការតភ្ជាប់រវាង IoT និងកម្រិតអ័ព្ទ វាក្លាយជាការកំណត់ដ៏សំខាន់មួយ។

តើត្រូវជ្រើសរើសអ្វី? មិនមានចម្លើយច្បាស់លាស់ទេ។ MQTT និង HTTP ហាក់ដូចជាពិធីការដ៏ជោគជ័យបំផុត ដោយសារពួកគេត្រូវបានចាត់ទុកថាជាដំណោះស្រាយ IoT មានភាពចាស់ទុំ និងមានស្ថេរភាពជាងបើប្រៀបធៀបទៅនឹងពិធីការផ្សេងទៀត។

ដំណោះស្រាយផ្អែកលើពិធីការទំនាក់ទំនងបង្រួបបង្រួម

ការអនុវត្តដំណោះស្រាយពិធីការតែមួយមានគុណវិបត្តិជាច្រើន។ ឧទាហរណ៍ ពិធីការដែលស័ក្តិសមនឹងបរិយាកាសដែលបានដាក់កំហិត ប្រហែលជាមិនដំណើរការនៅក្នុងដែនដែលមានតម្រូវការសុវត្ថិភាពតឹងរ៉ឹងនោះទេ។ ជាមួយនឹងគំនិតនេះ យើងទុកឱ្យបោះបង់ដំណោះស្រាយពិធីការតែមួយដែលអាចធ្វើទៅបានស្ទើរតែទាំងអស់នៅក្នុងប្រព័ន្ធអេកូ Fog-to-Cloud នៅក្នុង IoT លើកលែងតែ MQTT និង REST HTTP ។

REST HTTP ជាដំណោះស្រាយពិធីការតែមួយ

មានឧទាហរណ៍ដ៏ល្អមួយអំពីរបៀបដែលសំណើ និងការឆ្លើយតបរបស់ REST HTTP មានអន្តរកម្មនៅក្នុងចន្លោះ IoT-to-Fog៖ កសិដ្ឋានឆ្លាត. សត្វត្រូវបានបំពាក់ដោយឧបករណ៍ចាប់សញ្ញាដែលអាចពាក់បាន (IoT client, C) និងគ្រប់គ្រងតាមរយៈ cloud computing ដោយប្រព័ន្ធ smart farming (Fog server, S)។

បឋមកថានៃវិធីសាស្ត្រ POST បញ្ជាក់ធនធានដើម្បីកែប្រែ (/កសិដ្ឋាន/សត្វ) ក៏ដូចជាកំណែ HTTP និងប្រភេទមាតិកា ដែលក្នុងករណីនេះជាវត្ថុ JSON តំណាងឱ្យកសិដ្ឋានសត្វដែលប្រព័ន្ធត្រូវគ្រប់គ្រង (Dulcinea/cow) . ការឆ្លើយតបពីម៉ាស៊ីនមេបង្ហាញថាសំណើបានជោគជ័យដោយការផ្ញើលេខកូដស្ថានភាព HTTPS 201 (ធនធានដែលបានបង្កើត)។ វិធីសាស្ត្រ GET ត្រូវតែបញ្ជាក់តែធនធានដែលបានស្នើសុំនៅក្នុង URI (ឧទាហរណ៍ /farm/animals/1) ដែលផ្តល់លទ្ធផលតំណាង JSON នៃសត្វដែលមានលេខសម្គាល់នោះពីម៉ាស៊ីនមេ។

វិធីសាស្ត្រ PUT ត្រូវបានប្រើនៅពេលដែលកំណត់ត្រាធនធានជាក់លាក់មួយចំនួនចាំបាច់ត្រូវធ្វើបច្ចុប្បន្នភាព។ ក្នុងករណីនេះ ធនធានបញ្ជាក់ URI សម្រាប់ប៉ារ៉ាម៉ែត្រដែលត្រូវផ្លាស់ប្តូរ និងតម្លៃបច្ចុប្បន្ន (ឧទាហរណ៍ បង្ហាញថាគោកំពុងដើរ ​​/farm/animals/1? state=walking)។ ជាចុងក្រោយ វិធីសាស្ត្រ DELETE ត្រូវបានប្រើស្មើៗគ្នាទៅនឹងវិធីសាស្ត្រ GET ប៉ុន្តែគ្រាន់តែលុបធនធានជាលទ្ធផលនៃប្រតិបត្តិការ។

MQTT ជាដំណោះស្រាយពិធីការតែមួយ

តោះយកកសិដ្ឋានឆ្លាតវៃដូចគ្នា ប៉ុន្តែជំនួសឱ្យ REST HTTP យើងប្រើពិធីការ MQTT ។ ម៉ាស៊ីនមេក្នុងស្រុកដែលមានបណ្ណាល័យ Mosquitto ត្រូវបានដំឡើងដើរតួជាឈ្មួញកណ្តាល។ ក្នុងឧទាហរណ៍នេះ កុំព្យូទ័រសាមញ្ញមួយ (ហៅថាម៉ាស៊ីនមេកសិដ្ឋាន) Raspberry Pi បម្រើជាអតិថិជន MQTT ដែលត្រូវបានអនុវត្តតាមរយៈការដំឡើងបណ្ណាល័យ Paho MQTT ដែលអាចប្រើបានយ៉ាងពេញលេញជាមួយឈ្មួញកណ្តាល Mosquitto ។

ម៉ាស៊ីនភ្ញៀវនេះត្រូវគ្នាទៅនឹងស្រទាប់អរូបី IoT ដែលតំណាងឱ្យឧបករណ៍ដែលមានសមត្ថភាពចាប់សញ្ញា និងការគណនា។ ម៉្យាងទៀតអ្នកសម្របសម្រួលត្រូវគ្នាទៅនឹងកម្រិតខ្ពស់នៃអរូបី ដែលតំណាងឱ្យថ្នាំងកុំព្យូទ័រអ័ព្ទដែលកំណត់ដោយដំណើរការ និងសមត្ថភាពផ្ទុកកាន់តែច្រើន។

នៅក្នុងសេណារីយ៉ូកសិដ្ឋានឆ្លាតវៃដែលបានស្នើឡើង Raspberry Pi ភ្ជាប់ទៅឧបករណ៍វាស់ល្បឿន GPS និងឧបករណ៍ចាប់សញ្ញាសីតុណ្ហភាព ហើយបោះពុម្ពផ្សាយទិន្នន័យពីឧបករណ៍ចាប់សញ្ញាទាំងនេះទៅកាន់ថ្នាំងអ័ព្ទ។ ដូចដែលអ្នកបានដឹងហើយថា MQTT ចាត់ទុកប្រធានបទជាឋានានុក្រម។ អ្នកបោះពុម្ព MQTT តែមួយអាចបោះផ្សាយសារទៅសំណុំប្រធានបទជាក់លាក់មួយ។ ក្នុងករណីរបស់យើងមានបី។ សម្រាប់ឧបករណ៍ចាប់សញ្ញាដែលវាស់សីតុណ្ហភាពនៅក្នុងជង្រុកសត្វ អតិថិជនជ្រើសរើសប្រធានបទ (កសិដ្ឋានចិញ្ចឹមសត្វ/ជម្រក/សីតុណ្ហភាព)។ សម្រាប់ឧបករណ៍ចាប់សញ្ញាដែលវាស់ទីតាំង GPS និងចលនារបស់សត្វតាមរយៈឧបករណ៍វាស់ល្បឿន អតិថិជននឹងបោះផ្សាយបច្ចុប្បន្នភាពទៅ (កសិដ្ឋានចិញ្ចឹមសត្វ/សត្វ/GPS) និង (កសិដ្ឋានចិញ្ចឹមសត្វ/សត្វ/ចលនា)។

ព័ត៌មាននេះនឹងត្រូវបានបញ្ជូនទៅឈ្មួញកណ្តាល ដែលអាចរក្សាទុកវាជាបណ្ដោះអាសន្ននៅក្នុងមូលដ្ឋានទិន្នន័យក្នុងស្រុក ក្នុងករណីដែលអតិថិជនចាប់អារម្មណ៍ផ្សេងទៀតមកតាមក្រោយ។

បន្ថែមពីលើម៉ាស៊ីនមេក្នុងស្រុកដែលដើរតួជាឈ្មួញកណ្តាល MQTT នៅក្នុងអ័ព្ទ ហើយ Raspberry Pis ដែលដើរតួជាអតិថិជន MQTT ផ្ញើទិន្នន័យឧបករណ៍ចាប់សញ្ញា វាអាចមានឈ្មួញកណ្តាល MQTT ផ្សេងទៀតនៅកម្រិតពពក។ ក្នុងករណីនេះ ព័ត៌មានដែលបានបញ្ជូនទៅឈ្មួញកណ្តាលក្នុងស្រុកអាចត្រូវបានរក្សាទុកជាបណ្តោះអាសន្ននៅក្នុងមូលដ្ឋានទិន្នន័យមូលដ្ឋាន និង/ឬផ្ញើទៅកាន់ពពក។ អ័ព្ទ MQTT ឈ្មួញកណ្តាលក្នុងស្ថានភាពនេះត្រូវបានប្រើដើម្បីភ្ជាប់ទិន្នន័យទាំងអស់ជាមួយឈ្មួញកណ្តាល MQTT ពពក។ ជាមួយនឹងស្ថាបត្យកម្មនេះ អ្នកប្រើប្រាស់កម្មវិធីទូរស័ព្ទអាចជាវបានទាំងឈ្មួញកណ្តាល។

ប្រសិនបើការតភ្ជាប់ទៅឈ្មួញកណ្តាលមួយ (ឧទាហរណ៍ពពក) បរាជ័យ អ្នកប្រើប្រាស់ចុងក្រោយនឹងទទួលបានព័ត៌មានពីអ្នកផ្សេងទៀត (អ័ព្ទ)។ នេះ​ជា​លក្ខណៈ​ពិសេស​នៃ​ប្រព័ន្ធ​កុំព្យូទ័រ​ពពក និង​អ័ព្ទ​រួម​គ្នា។ តាមលំនាំដើម កម្មវិធីទូរស័ព្ទអាចត្រូវបានកំណត់រចនាសម្ព័ន្ធដើម្បីភ្ជាប់ទៅឈ្មួញកណ្តាលអ័ព្ទ MQTT ជាមុនសិន ហើយប្រសិនបើវាបរាជ័យ ដើម្បីភ្ជាប់ទៅឈ្មួញកណ្តាល MQTT ពពក។ ដំណោះស្រាយនេះគឺគ្រាន់តែជាផ្នែកមួយនៃប្រព័ន្ធ IoT-F2C ប៉ុណ្ណោះ។

ដំណោះស្រាយពហុពិធីការ

ដំណោះស្រាយពិធីការតែមួយគឺមានប្រជាប្រិយភាពដោយសារតែការអនុវត្តកាន់តែងាយស្រួលរបស់ពួកគេ។ ប៉ុន្តែវាច្បាស់ណាស់ថានៅក្នុងប្រព័ន្ធ IoT-F2C វាសមហេតុផលក្នុងការបញ្ចូលគ្នានូវពិធីការផ្សេងៗ។ គំនិតគឺថាពិធីការផ្សេងៗគ្នាអាចដំណើរការនៅកម្រិតផ្សេងៗគ្នា។ ជាឧទាហរណ៍ សូមពិចារណាអរូបីចំនួនបី៖ ស្រទាប់នៃ IoT អ័ព្ទ និងកុំព្យូទ័រលើពពក។ ឧបករណ៍នៅកម្រិត IoT ជាទូទៅត្រូវបានចាត់ទុកថាមានកម្រិត។ សម្រាប់ទិដ្ឋភាពទូទៅនេះ ចូរយើងពិចារណាថ្នាក់ IoT ថាជាការដាក់កំហិតបំផុត ពពកមានកម្រិតទាបបំផុត និងការគណនាអ័ព្ទជា "កន្លែងណាមួយនៅកណ្តាល"។ វាប្រែថារវាង IoT និងអ័ព្ទអ័ព្ទ ដំណោះស្រាយពិធីការបច្ចុប្បន្នរួមមាន MQTT, CoAP និង XMPP ។ រវាងអ័ព្ទ និងពពក ម្យ៉ាងវិញទៀត AMQP គឺជាពិធីការចម្បងមួយដែលត្រូវបានប្រើប្រាស់ រួមជាមួយនឹង REST HTTP ដែលដោយសារតែភាពបត់បែនរបស់វាក៏ត្រូវបានគេប្រើរវាងស្រទាប់ IoT និងអ័ព្ទផងដែរ។

បញ្ហាចម្បងនៅទីនេះគឺអន្តរប្រតិបត្តិការនៃពិធីការ និងភាពងាយស្រួលនៃការផ្ទេរសារពីពិធីការមួយទៅពិធីការមួយទៀត។ តាមឧត្ដមគតិ នាពេលអនាគត ស្ថាបត្យកម្មនៃប្រព័ន្ធ Internet of Things ដែលមានធនធានពពក និងអ័ព្ទនឹងឯករាជ្យពីពិធីការទំនាក់ទំនងដែលបានប្រើ ហើយនឹងធានាឱ្យមានអន្តរប្រតិបត្តិការល្អរវាងពិធីការផ្សេងៗ។

ដោយសារវាមិនមែនជាករណីនាពេលបច្ចុប្បន្ននេះ វាសមហេតុផលក្នុងការបញ្ចូលគ្នានូវពិធីការដែលមិនមានភាពខុសគ្នាខ្លាំង។ ដល់ទីបញ្ចប់នេះ ដំណោះស្រាយសក្តានុពលមួយគឺផ្អែកលើការរួមបញ្ចូលគ្នានៃពិធីការពីរដែលធ្វើតាមរចនាប័ទ្មស្ថាបត្យកម្មដូចគ្នា REST HTTP និង CoAP ។ ដំណោះស្រាយដែលបានស្នើឡើងមួយទៀតគឺផ្អែកលើការរួមបញ្ចូលគ្នានៃពិធីការពីរដែលផ្តល់ការទំនាក់ទំនងផ្សព្វផ្សាយ-ជាវ MQTT និង AMQP ។ ការប្រើប្រាស់គោលគំនិតស្រដៀងគ្នា (ទាំង MQTT និង AMQP ប្រើឈ្មួញកណ្តាល CoAP និង HTTP ប្រើ REST) ​​ធ្វើឱ្យបន្សំទាំងនេះងាយស្រួលអនុវត្ត និងទាមទារការខិតខំប្រឹងប្រែងក្នុងការរួមបញ្ចូលតិច។

រូបភាព (a) បង្ហាញគំរូដែលមានមូលដ្ឋានលើការស្នើរសុំចំនួនពីរគឺ HTTP និង CoAP និងការដាក់របស់ពួកគេនៅក្នុងដំណោះស្រាយ IoT-F2C ។ ដោយសារ HTTP គឺជាពិធីការដ៏ល្បីបំផុតមួយ និងត្រូវបានអនុម័តនៅលើបណ្តាញទំនើប វាមិនទំនងថាវានឹងត្រូវបានជំនួសទាំងស្រុងដោយពិធីសារផ្ញើសារផ្សេងទៀតនោះទេ។ ក្នុងចំណោមថ្នាំងដែលតំណាងឱ្យឧបករណ៍ដ៏មានឥទ្ធិពលដែលស្ថិតនៅចន្លោះពពក និងអ័ព្ទ REST HTTP គឺជាដំណោះស្រាយដ៏ឆ្លាតវៃ។

ម្យ៉ាងវិញទៀត សម្រាប់ឧបករណ៍ដែលមានធនធានកុំព្យូទ័រមានកម្រិត ដែលទំនាក់ទំនងរវាងស្រទាប់ Fog និង IoT វាកាន់តែមានប្រសិទ្ធភាពក្នុងការប្រើ CoAP ។ អត្ថប្រយោជន៍ដ៏ធំមួយនៃ CoAP គឺពិតជាភាពឆបគ្នារបស់វាជាមួយ HTTP ចាប់តាំងពីពិធីការទាំងពីរគឺផ្អែកលើគោលការណ៍ REST ។

រូបភាព (ខ) បង្ហាញគំរូទំនាក់ទំនងដែលបានបោះពុម្ព-ជាវចំនួនពីរនៅក្នុងសេណារីយ៉ូដូចគ្នា រួមមាន MQTT និង AMQP ។ ទោះបីជាពិធីការទាំងពីរអាចប្រើជាសម្មតិកម្មសម្រាប់ការទំនាក់ទំនងរវាងថ្នាំងនៅស្រទាប់អរូបីនីមួយៗក៏ដោយ ទីតាំងរបស់ពួកគេគួរតែត្រូវបានកំណត់ដោយផ្អែកលើការអនុវត្ត។ MQTT ត្រូវបានរចនាឡើងជាពិធីការទម្ងន់ស្រាលសម្រាប់ឧបករណ៍ដែលមានធនធានកុំព្យូទ័រមានកម្រិត ដូច្នេះវាអាចប្រើសម្រាប់ទំនាក់ទំនង IoT-Fog ។ AMQP កាន់តែស័ក្តិសមសម្រាប់ឧបករណ៍ដែលមានថាមពលខ្លាំងជាងមុន ដែលនឹងកំណត់ទីតាំងវានៅចន្លោះអ័ព្ទ និងពពក។ ជំនួសឱ្យ MQTT ពិធីការ XMPP អាចត្រូវបានប្រើនៅក្នុង IoT ដូចដែលវាត្រូវបានចាត់ទុកថាស្រាល។ ប៉ុន្តែវាមិនត្រូវបានគេប្រើប្រាស់យ៉ាងទូលំទូលាយនៅក្នុងសេណារីយ៉ូបែបនេះទេ។

ការរកឃើញ

វាមិនទំនងដែលថាពិធីការមួយក្នុងចំណោមពិធីការដែលបានពិភាក្សានឹងគ្រប់គ្រាន់ដើម្បីគ្របដណ្តប់ទំនាក់ទំនងទាំងអស់នៅក្នុងប្រព័ន្ធមួយ ចាប់ពីឧបករណ៍ដែលមានធនធានកុំព្យូទ័រមានកម្រិតរហូតដល់ម៉ាស៊ីនមេពពក។ ការសិក្សាបានរកឃើញថាជម្រើសដ៏ជោគជ័យបំផុតពីរដែលអ្នកអភិវឌ្ឍន៍ប្រើប្រាស់ច្រើនបំផុតគឺ MQTT និង RESTful HTTP ។ ពិធីការទាំងពីរនេះមិនត្រឹមតែមានភាពចាស់ទុំ និងមានស្ថេរភាពបំផុតប៉ុណ្ណោះទេ ប៉ុន្តែថែមទាំងរួមបញ្ចូលការអនុវត្តន៍ដែលបានចងក្រងជាឯកសារ និងជោគជ័យជាច្រើន និងធនធានអនឡាញផងដែរ។

ដោយសារស្ថេរភាព និងការកំណត់រចនាសម្ព័ន្ធសាមញ្ញ MQTT គឺជាពិធីការដែលបានបង្ហាញឱ្យឃើញពីដំណើរការល្អជាងរបស់ខ្លួននៅពេលប្រើនៅកម្រិត IoT ជាមួយនឹងឧបករណ៍មានកំណត់។ នៅក្នុងផ្នែកនៃប្រព័ន្ធដែលទំនាក់ទំនងមានកម្រិត និងការប្រើប្រាស់ថ្មមិនមែនជាបញ្ហាទេ ដូចជាដែនអ័ព្ទមួយចំនួន និងកុំព្យូទ័រពពកភាគច្រើន RESTful HTTP គឺជាជម្រើសដ៏ងាយស្រួលមួយ។ CoAP ក៏គួរត្រូវបានយកមកពិចារណាផងដែរ ព្រោះវាក៏កំពុងវិវឌ្ឍយ៉ាងឆាប់រហ័សជាស្តង់ដារផ្ញើសារ IoT ហើយវាទំនងជាថាវានឹងឈានដល់កម្រិតស្ថិរភាព និងភាពចាស់ទុំស្រដៀងនឹង MQTT និង HTTP នាពេលអនាគតដ៏ខ្លីខាងមុខនេះ។ ប៉ុន្តែបច្ចុប្បន្នស្តង់ដារកំពុងវិវឌ្ឍ ដែលភ្ជាប់មកជាមួយបញ្ហាភាពត្រូវគ្នាក្នុងរយៈពេលខ្លី។

តើអ្នកអាចអានអ្វីទៀតនៅលើប្លក់? Cloud4Y

→ កុំព្យូទ័រនឹងធ្វើឱ្យអ្នកឆ្ងាញ់
→ AI ជួយសិក្សាសត្វនៅអាហ្វ្រិក
→ រដូវក្តៅជិតចប់ហើយ។ ស្ទើរតែគ្មានទិន្នន័យលេចធ្លាយនៅសល់
→ 4 វិធីដើម្បីរក្សាទុកនៅលើពពកបម្រុងទុក
→ នៅលើធនធានព័ត៌មានសហព័ន្ធបង្រួបបង្រួមដែលមានព័ត៌មានអំពីចំនួនប្រជាជន

ជាវប្រចាំរបស់យើង។ Telegram-channel ដូច្នេះអ្នកកុំខកខានអត្ថបទបន្ទាប់! យើងសរសេរមិនលើសពីពីរដងក្នុងមួយសប្តាហ៍ ហើយសម្រាប់តែអាជីវកម្មប៉ុណ្ណោះ។

ប្រភព: www.habr.com