IoT, മൂടൽമഞ്ഞ്, മേഘങ്ങൾ: നമുക്ക് സാങ്കേതികവിദ്യയെക്കുറിച്ച് സംസാരിക്കാം?

സോഫ്റ്റ്‌വെയർ, ഹാർഡ്‌വെയർ മേഖലയിലെ സാങ്കേതികവിദ്യകളുടെ വികസനം, പുതിയ ആശയവിനിമയ പ്രോട്ടോക്കോളുകളുടെ ആവിർഭാവം എന്നിവ ഇന്റർനെറ്റ് ഓഫ് തിംഗ്‌സിന്റെ (ഐഒടി) വിപുലീകരണത്തിലേക്ക് നയിച്ചു. ഉപകരണങ്ങളുടെ എണ്ണം അനുദിനം വളരുകയും അവ വലിയ അളവിൽ ഡാറ്റ സൃഷ്ടിക്കുകയും ചെയ്യുന്നു. അതിനാൽ, ഈ ഡാറ്റ പ്രോസസ്സ് ചെയ്യാനും സംഭരിക്കാനും കൈമാറാനും കഴിയുന്ന സൗകര്യപ്രദമായ ഒരു സിസ്റ്റം ആർക്കിടെക്ചറിന്റെ ആവശ്യകതയുണ്ട്.

ഇപ്പോൾ ക്ലൗഡ് സേവനങ്ങൾ ഈ ആവശ്യങ്ങൾക്കായി ഉപയോഗിക്കുന്നു. എന്നിരുന്നാലും, വർദ്ധിച്ചുവരുന്ന ജനപ്രിയമായ ഫോഗ് കമ്പ്യൂട്ടിംഗ് മാതൃകയ്ക്ക് (ഫോഗ്) ഐഒടി ഇൻഫ്രാസ്ട്രക്ചർ സ്കെയിൽ ചെയ്തും ഒപ്റ്റിമൈസ് ചെയ്തും ക്ലൗഡ് സൊല്യൂഷനുകൾ പൂർത്തീകരിക്കാൻ കഴിയും.

മിക്ക IoT അഭ്യർത്ഥനകളും കവർ ചെയ്യാൻ ക്ലൗഡുകൾക്ക് കഴിയും. ഉദാഹരണത്തിന്, സേവനങ്ങളുടെ നിരീക്ഷണം നൽകുന്നതിന്, ഉപകരണങ്ങൾ സൃഷ്ടിക്കുന്ന ഏത് അളവിലുള്ള ഡാറ്റയുടെയും വേഗത്തിലുള്ള പ്രോസസ്സിംഗ്, അതുപോലെ തന്നെ അവയുടെ ദൃശ്യവൽക്കരണം. തത്സമയ പ്രശ്നങ്ങൾ പരിഹരിക്കുമ്പോൾ ഫോഗ് കമ്പ്യൂട്ടിംഗ് കൂടുതൽ ഫലപ്രദമാണ്. അവ അഭ്യർത്ഥനകളോട് വേഗത്തിലുള്ള പ്രതികരണവും ഡാറ്റ പ്രോസസ്സിംഗിൽ കുറഞ്ഞ കാലതാമസവും നൽകുന്നു. അതായത്, മൂടൽമഞ്ഞ് "മേഘങ്ങൾ" പൂർത്തീകരിക്കുകയും അതിന്റെ കഴിവുകൾ വികസിപ്പിക്കുകയും ചെയ്യുന്നു.

എന്നിരുന്നാലും, പ്രധാന ചോദ്യം വ്യത്യസ്തമാണ്: IoT യുടെ പശ്ചാത്തലത്തിൽ ഇതെല്ലാം എങ്ങനെ ഇടപെടണം? സംയോജിത IoT-Fog-Cloud സിസ്റ്റത്തിൽ പ്രവർത്തിക്കുമ്പോൾ ഏത് ആശയവിനിമയ പ്രോട്ടോക്കോളുകളാണ് ഏറ്റവും ഫലപ്രദമാകുക?

എച്ച്ടിടിപിയുടെ പ്രകടമായ ആധിപത്യം ഉണ്ടായിരുന്നിട്ടും, ഐഒടി, ഫോഗ്, ക്ലൗഡ് സിസ്റ്റങ്ങളിൽ മറ്റ് നിരവധി പരിഹാരങ്ങൾ ഉപയോഗിക്കുന്നു. കാരണം, IoT വിവിധ ഉപകരണ സെൻസറുകളുടെ പ്രവർത്തനക്ഷമത, സുരക്ഷ, അനുയോജ്യത, ഉപയോക്താക്കളുടെ മറ്റ് ആവശ്യങ്ങൾ എന്നിവയുമായി സംയോജിപ്പിക്കണം.

എന്നാൽ റഫറൻസ് ആർക്കിടെക്ചറിനെയും ആശയവിനിമയ നിലവാരത്തെയും കുറിച്ച് ഒരൊറ്റ ആശയവുമില്ല. അതിനാൽ, ഒരു പുതിയ പ്രോട്ടോക്കോൾ സൃഷ്ടിക്കുക അല്ലെങ്കിൽ നിർദ്ദിഷ്ട IoT ടാസ്‌ക്കുകൾക്കായി നിലവിലുള്ള ഒന്ന് പരിഷ്‌ക്കരിക്കുക എന്നത് ഐടി കമ്മ്യൂണിറ്റി നേരിടുന്ന ഏറ്റവും പ്രധാനപ്പെട്ട ജോലികളിൽ ഒന്നാണ്.

നിലവിൽ ഏതൊക്കെ പ്രോട്ടോക്കോളുകളാണ് ഉപയോഗത്തിലുള്ളത്, അവയ്ക്ക് എന്ത് നൽകാനാകും? നമുക്ക് അത് കണ്ടുപിടിക്കാം. എന്നാൽ ആദ്യം, മേഘങ്ങൾ, മൂടൽമഞ്ഞ്, വസ്തുക്കളുടെ ഇന്റർനെറ്റ് എന്നിവ സംവദിക്കുന്ന ആവാസവ്യവസ്ഥയുടെ തത്വങ്ങൾ ചർച്ച ചെയ്യാം.

IoT ഫോഗ്-ടു-ക്ലൗഡ് (F2C) ആർക്കിടെക്ചർ

IoT, ക്ലൗഡ്, ഫോഗ് എന്നിവയുടെ സമർത്ഥവും ഏകോപിതവുമായ മാനേജ്‌മെന്റുമായി ബന്ധപ്പെട്ട നേട്ടങ്ങളും നേട്ടങ്ങളും പര്യവേക്ഷണം ചെയ്യാൻ എത്രമാത്രം പരിശ്രമിക്കുന്നുവെന്ന് നിങ്ങൾ ശ്രദ്ധിച്ചിരിക്കാം. ഇല്ലെങ്കിൽ, മൂന്ന് സ്റ്റാൻഡേർഡൈസേഷൻ സംരംഭങ്ങൾ ഇതാ: ഓപ്പൺഫോഗ് കൺസോർഷ്യം, എഡ്ജ് കമ്പ്യൂട്ടിംഗ് കൺസോർഷ്യം и mF2C H2020 EU പദ്ധതി.

മുമ്പ് 2 ലെവലുകൾ മാത്രമാണ് പരിഗണിച്ചിരുന്നതെങ്കിൽ, മേഘങ്ങളും അവസാന ഉപകരണങ്ങളും, നിർദ്ദിഷ്ട ആർക്കിടെക്ചർ ഒരു പുതിയ ലെവൽ അവതരിപ്പിക്കുന്നു - ഫോഗ് കമ്പ്യൂട്ടിംഗ്. ഈ സാഹചര്യത്തിൽ, ഈ ഉപതലങ്ങളിലെ വ്യത്യസ്ത ഉപകരണങ്ങളുടെ ഉപയോഗം നിർണ്ണയിക്കുന്ന വിഭവങ്ങളുടെ പ്രത്യേകതകൾ അല്ലെങ്കിൽ ഒരു കൂട്ടം നയങ്ങൾ എന്നിവയെ ആശ്രയിച്ച് മൂടൽമഞ്ഞ് നിലയെ നിരവധി ഉപതലങ്ങളായി വിഭജിക്കാം.

ഈ അമൂർത്തീകരണം എങ്ങനെയായിരിക്കാം? ഒരു സാധാരണ IoT-Fog-Cloud ഇക്കോസിസ്റ്റം ഇതാ. IoT ഉപകരണങ്ങൾ വേഗതയേറിയ സെർവറുകളിലേക്കും കംപ്യൂട്ടിംഗ് ഉപകരണങ്ങളിലേക്കും ഡാറ്റ അയയ്‌ക്കുന്നത് കുറഞ്ഞ കാലതാമസം ആവശ്യമുള്ള പ്രശ്‌നങ്ങൾ പരിഹരിക്കുന്നതിന് വേണ്ടിയാണ്. അതേ സിസ്റ്റത്തിൽ, വലിയ അളവിലുള്ള കമ്പ്യൂട്ടിംഗ് ഉറവിടങ്ങളോ ഡാറ്റ സംഭരണ ​​​​ഇടമോ ആവശ്യമായ പ്രശ്നങ്ങൾ പരിഹരിക്കുന്നതിന് ക്ലൗഡുകൾ ഉത്തരവാദികളാണ്.

സ്മാർട്ട്‌ഫോണുകൾ, സ്മാർട്ട് വാച്ചുകൾ, മറ്റ് ഗാഡ്‌ജെറ്റുകൾ എന്നിവയും ഐഒടിയുടെ ഭാഗമാകാം. എന്നാൽ അത്തരം ഉപകരണങ്ങൾ, ചട്ടം പോലെ, വലിയ ഡവലപ്പർമാരിൽ നിന്നുള്ള കുത്തക ആശയവിനിമയ പ്രോട്ടോക്കോളുകൾ ഉപയോഗിക്കുന്നു. ജനറേറ്റുചെയ്‌ത IoT ഡാറ്റ REST HTTP പ്രോട്ടോക്കോൾ വഴി ഫോഗ് ലെയറിലേക്ക് മാറ്റുന്നു, ഇത് RESTful സേവനങ്ങൾ സൃഷ്ടിക്കുമ്പോൾ വഴക്കവും പരസ്പര പ്രവർത്തനവും നൽകുന്നു. പ്രാദേശിക കമ്പ്യൂട്ടറുകളിലോ സെർവറുകളിലോ സെർവർ ക്ലസ്റ്ററുകളിലോ പ്രവർത്തിക്കുന്ന നിലവിലുള്ള കമ്പ്യൂട്ടിംഗ് ഇൻഫ്രാസ്ട്രക്ചറുമായി പിന്നാക്ക അനുയോജ്യത ഉറപ്പാക്കേണ്ടതിന്റെ ആവശ്യകതയുടെ വെളിച്ചത്തിൽ ഇത് പ്രധാനമാണ്. "ഫോഗ് നോഡുകൾ" എന്ന് വിളിക്കപ്പെടുന്ന പ്രാദേശിക ഉറവിടങ്ങൾ, സ്വീകരിച്ച ഡാറ്റ ഫിൽട്ടർ ചെയ്ത് പ്രാദേശികമായി പ്രോസസ്സ് ചെയ്യുക അല്ലെങ്കിൽ കൂടുതൽ കണക്കുകൂട്ടലുകൾക്കായി ക്ലൗഡിലേക്ക് അയയ്ക്കുക.

മേഘങ്ങൾ വ്യത്യസ്ത ആശയവിനിമയ പ്രോട്ടോക്കോളുകളെ പിന്തുണയ്ക്കുന്നു, ഏറ്റവും സാധാരണമായത് AMQP, REST HTTP എന്നിവയാണ്. HTTP അറിയപ്പെടുന്നതും ഇന്റർനെറ്റിന് അനുയോജ്യമായതുമായതിനാൽ, ചോദ്യം ഉയർന്നേക്കാം: "IoT, മൂടൽമഞ്ഞ് എന്നിവയുമായി പ്രവർത്തിക്കാൻ ഞങ്ങൾ ഇത് ഉപയോഗിക്കേണ്ടതല്ലേ?" എന്നിരുന്നാലും, ഈ പ്രോട്ടോക്കോളിന് പ്രകടന പ്രശ്നങ്ങളുണ്ട്. ഇതിനെക്കുറിച്ച് കൂടുതൽ പിന്നീട്.

പൊതുവേ, നമുക്ക് ആവശ്യമുള്ള സിസ്റ്റത്തിന് അനുയോജ്യമായ ആശയവിനിമയ പ്രോട്ടോക്കോളുകളുടെ 2 മോഡലുകൾ ഉണ്ട്. അഭ്യർത്ഥന-പ്രതികരണം, പ്രസിദ്ധീകരിക്കുക-സബ്‌സ്‌ക്രൈബ് എന്നിവയാണ് ഇവ. ആദ്യ മോഡൽ കൂടുതൽ വ്യാപകമായി അറിയപ്പെടുന്നു, പ്രത്യേകിച്ച് സെർവർ-ക്ലയന്റ് ആർക്കിടെക്ചറിൽ. ക്ലയന്റ് സെർവറിൽ നിന്ന് വിവരങ്ങൾ അഭ്യർത്ഥിക്കുന്നു, സെർവർ അഭ്യർത്ഥന സ്വീകരിക്കുകയും പ്രോസസ്സ് ചെയ്യുകയും ഒരു പ്രതികരണ സന്ദേശം നൽകുകയും ചെയ്യുന്നു. REST HTTP, CoAP പ്രോട്ടോക്കോളുകൾ ഈ മോഡലിൽ പ്രവർത്തിക്കുന്നു.

ഡാറ്റ സൃഷ്ടിക്കുന്ന ഉറവിടങ്ങൾക്കും ഈ ഡാറ്റയുടെ സ്വീകർത്താക്കൾക്കും ഇടയിൽ അസമന്വിതവും വിതരണം ചെയ്തതും അയഞ്ഞതുമായ കപ്ലിംഗ് നൽകേണ്ടതിന്റെ ആവശ്യകതയിൽ നിന്നാണ് രണ്ടാമത്തെ മോഡൽ ഉടലെടുത്തത്.

മോഡൽ മൂന്ന് പങ്കാളികളെ അനുമാനിക്കുന്നു: ഒരു പ്രസാധകൻ (ഡാറ്റ ഉറവിടം), ഒരു ബ്രോക്കർ (ഡിസ്പാച്ചർ), ഒരു സബ്സ്ക്രൈബർ (സ്വീകർത്താവ്). ഇവിടെ, ഒരു വരിക്കാരനായി പ്രവർത്തിക്കുന്ന ക്ലയന്റ് സെർവറിൽ നിന്ന് വിവരങ്ങൾ അഭ്യർത്ഥിക്കേണ്ടതില്ല. അഭ്യർത്ഥനകൾ അയയ്‌ക്കുന്നതിനുപകരം, ഒരു ബ്രോക്കർ മുഖേന സിസ്റ്റത്തിലെ ചില ഇവന്റുകളിലേക്ക് ഇത് സബ്‌സ്‌ക്രൈബുചെയ്യുന്നു, അത് എല്ലാ ഇൻകമിംഗ് സന്ദേശങ്ങളും ഫിൽട്ടർ ചെയ്യുന്നതിനും പ്രസാധകർക്കും സബ്‌സ്‌ക്രൈബർമാർക്കുമിടയിൽ റൂട്ട് ചെയ്യുന്നതിനും ഉത്തരവാദിയാണ്. പ്രസാധകൻ, ഒരു പ്രത്യേക വിഷയവുമായി ബന്ധപ്പെട്ട് ഒരു ഇവന്റ് സംഭവിക്കുമ്പോൾ, അത് ബ്രോക്കർക്ക് പ്രസിദ്ധീകരിക്കുന്നു, അത് അഭ്യർത്ഥിച്ച വിഷയത്തെക്കുറിച്ചുള്ള ഡാറ്റ വരിക്കാരന് അയയ്ക്കുന്നു.

അടിസ്ഥാനപരമായി, ഈ വാസ്തുവിദ്യ ഇവന്റ് അടിസ്ഥാനമാക്കിയുള്ളതാണ്. ഈ ഇന്ററാക്ഷൻ മോഡൽ IoT, ക്ലൗഡ്, ഫോഗ് എന്നിവയിലെ ആപ്ലിക്കേഷനുകൾക്ക് രസകരമാണ്, കാരണം സ്കേലബിളിറ്റി നൽകാനും വ്യത്യസ്ത ഉപകരണങ്ങൾ തമ്മിലുള്ള പരസ്പരബന്ധം ലളിതമാക്കാനുമുള്ള കഴിവ്, ഡൈനാമിക് പല-ടു-മനി ആശയവിനിമയവും അസമന്വിത ആശയവിനിമയവും പിന്തുണയ്ക്കുന്നു. MQTT, AMQP, DDS എന്നിവ പ്രസിദ്ധീകരണ-സബ്‌സ്‌ക്രൈബ് മോഡൽ ഉപയോഗിക്കുന്ന ഏറ്റവും അറിയപ്പെടുന്ന ചില സ്റ്റാൻഡേർഡ് മെസേജിംഗ് പ്രോട്ടോക്കോളുകളിൽ ഉൾപ്പെടുന്നു.

വ്യക്തമായും, പ്രസിദ്ധീകരിക്കൽ-സബ്‌സ്‌ക്രൈബ് മോഡലിന് ധാരാളം ഗുണങ്ങളുണ്ട്:

• പ്രസാധകരും വരിക്കാരും പരസ്പരം അസ്തിത്വത്തെക്കുറിച്ച് അറിയേണ്ടതില്ല;
• ഒരു വരിക്കാരന് വിവിധ പ്രസിദ്ധീകരണങ്ങളിൽ നിന്ന് വിവരങ്ങൾ സ്വീകരിക്കാൻ കഴിയും, കൂടാതെ ഒരു പ്രസാധകന് വിവിധ സബ്‌സ്‌ക്രൈബർമാർക്ക് ഡാറ്റ അയയ്‌ക്കാൻ കഴിയും (നിരവധി മുതൽ നിരവധി തത്വങ്ങൾ);
• പ്രസാധകനും വരിക്കാരനും ആശയവിനിമയം നടത്താൻ ഒരേ സമയം സജീവമായിരിക്കണമെന്നില്ല, കാരണം ബ്രോക്കറിന് (ക്യൂയിംഗ് സിസ്റ്റമായി പ്രവർത്തിക്കുന്നു) നിലവിൽ നെറ്റ്‌വർക്കിലേക്ക് കണക്റ്റുചെയ്‌തിട്ടില്ലാത്ത ക്ലയന്റുകൾക്കായി സന്ദേശം സംഭരിക്കാൻ കഴിയും.

എന്നിരുന്നാലും, അഭ്യർത്ഥന-പ്രതികരണ മോഡലിന് അതിന്റെ ശക്തിയുണ്ട്. ഒന്നിലധികം ക്ലയന്റ് അഭ്യർത്ഥനകൾ കൈകാര്യം ചെയ്യാനുള്ള സെർവർ വശത്തിന്റെ കഴിവ് ഒരു പ്രശ്നമല്ലെങ്കിൽ, തെളിയിക്കപ്പെട്ടതും വിശ്വസനീയവുമായ പരിഹാരങ്ങൾ ഉപയോഗിക്കുന്നത് അർത്ഥമാക്കുന്നു.

രണ്ട് മോഡലുകളെയും പിന്തുണയ്ക്കുന്ന പ്രോട്ടോക്കോളുകളും ഉണ്ട്. ഉദാഹരണത്തിന്, "സെർവർ പുഷ്" ഓപ്ഷനെ പിന്തുണയ്ക്കുന്ന XMPP, HTTP 2.0. ഐഇടിഎഫ് ഒരു കോഎപിയും പുറത്തിറക്കിയിട്ടുണ്ട്. സന്ദേശമയയ്‌ക്കൽ പ്രശ്‌നം പരിഹരിക്കാനുള്ള ശ്രമത്തിൽ, വെബ്‌സോക്കറ്റ് പ്രോട്ടോക്കോൾ അല്ലെങ്കിൽ ക്യുഐസി (ക്വിക്ക് യുഡിപി ഇൻറർനെറ്റ് കണക്ഷനുകൾ) വഴിയുള്ള എച്ച്ടിടിപി പ്രോട്ടോക്കോളിന്റെ ഉപയോഗം പോലുള്ള മറ്റ് നിരവധി പരിഹാരങ്ങൾ സൃഷ്ടിച്ചിട്ടുണ്ട്.

വെബ്‌സോക്കറ്റുകളുടെ കാര്യത്തിൽ, ഒരു സെർവറിൽ നിന്ന് ഒരു വെബ് ക്ലയന്റിലേക്ക് തത്സമയം ഡാറ്റ കൈമാറുന്നതിനും ഒരേസമയം ദ്വിദിശ ആശയവിനിമയത്തിലൂടെ സ്ഥിരമായ കണക്ഷനുകൾ നൽകുന്നതിനും ഇത് ഉപയോഗിക്കുന്നുവെങ്കിലും, ഇത് പരിമിതമായ കമ്പ്യൂട്ടിംഗ് ഉറവിടങ്ങളുള്ള ഉപകരണങ്ങൾക്കായി ഉദ്ദേശിച്ചുള്ളതല്ല. പുതിയ ഗതാഗത പ്രോട്ടോക്കോൾ ധാരാളം പുതിയ അവസരങ്ങൾ നൽകുന്നതിനാൽ 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-ന് നൂറുകണക്കിന് മൈക്രോസെക്കൻഡും ആയിരുന്നു. എന്നിരുന്നാലും, വിശ്വസനീയമല്ലാത്ത നെറ്റ്‌വർക്കുകളിൽ പ്രവർത്തിക്കുമ്പോൾ, ടിസിപിയുടെ മുകളിൽ പ്രവർത്തിക്കുന്ന MQTT തികച്ചും വ്യത്യസ്തമായ ഫലം കാണിക്കുമെന്നത് ഓർമിക്കേണ്ടതാണ്.

താരതമ്യം പേലോഡ് വർദ്ധിപ്പിച്ച് AMQP, MQTT പ്രോട്ടോക്കോളുകൾക്കുള്ള പ്രതികരണ സമയം, ഒരു ലൈറ്റ് ലോഡിൽ ലേറ്റൻസി ലെവൽ ഏതാണ്ട് തുല്യമാണെന്ന് കാണിക്കുന്നു. എന്നാൽ വലിയ അളവിലുള്ള ഡാറ്റ കൈമാറ്റം ചെയ്യുമ്പോൾ, MQTT കുറഞ്ഞ പ്രതികരണ സമയം കാണിക്കുന്നു. ഒന്നിൽ കൂടി ഗവേഷണം ഗ്യാസ് സെൻസറുകൾ, കാലാവസ്ഥാ സെൻസറുകൾ, ലൊക്കേഷൻ സെൻസറുകൾ (ജിപിഎസ്), മൊബൈൽ നെറ്റ്‌വർക്ക് ഇന്റർഫേസ് (ജിപിആർഎസ്) എന്നിവയുള്ള വാഹനങ്ങളുടെ മുകളിൽ വിന്യസിച്ചിരിക്കുന്ന ഉപകരണങ്ങളുള്ള ഒരു മെഷീൻ-ടു-മെഷീൻ കമ്മ്യൂണിക്കേഷൻ സാഹചര്യത്തിൽ CoAP-യെ HTTP-യുമായി താരതമ്യം ചെയ്തു. മൊബൈൽ നെറ്റ്‌വർക്കിലൂടെ ഒരു CoAP സന്ദേശം കൈമാറാൻ ആവശ്യമായ സമയം HTTP സന്ദേശങ്ങൾ ഉപയോഗിക്കുന്നതിന് ആവശ്യമായ സമയത്തേക്കാൾ ഏകദേശം മൂന്നിരട്ടി കുറവായിരുന്നു.

രണ്ടല്ല, മൂന്ന് പ്രോട്ടോക്കോളുകളെ താരതമ്യപ്പെടുത്തി പഠനങ്ങൾ നടത്തിയിട്ടുണ്ട്. ഉദാഹരണത്തിന്, താരതമ്യം ഒരു നെറ്റ്‌വർക്ക് എമുലേറ്റർ ഉപയോഗിക്കുന്ന മെഡിക്കൽ ആപ്ലിക്കേഷൻ സാഹചര്യത്തിൽ MQTT, DDS, CoAP എന്നിവയുടെ IoT പ്രോട്ടോക്കോളുകളുടെ പ്രകടനം. വിവിധതരം മോശം നെറ്റ്‌വർക്ക് അവസ്ഥകളിൽ പരീക്ഷിച്ച ടെലിമെട്രി ലേറ്റൻസിയുടെ കാര്യത്തിൽ 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 എന്നിവയുടെ കഴിവുകൾ താരതമ്യം ചെയ്ത ഒരു പരീക്ഷണം, MQTT കൂടുതൽ ഊർജ്ജക്ഷമതയുള്ളതായിരിക്കുമ്പോൾ AMQP കൂടുതൽ സുരക്ഷാ കഴിവുകൾ വാഗ്ദാനം ചെയ്യുന്നതായി കണ്ടെത്തി.

സുരക്ഷ

ഇന്റർനെറ്റ് ഓഫ് തിംഗ്‌സ്, ഫോഗ്/ക്ലൗഡ് കമ്പ്യൂട്ടിംഗ് എന്നിവയെക്കുറിച്ച് പഠിക്കുമ്പോൾ ഉന്നയിക്കുന്ന മറ്റൊരു നിർണായക പ്രശ്‌നമാണ് സുരക്ഷ. സുരക്ഷാ സംവിധാനം സാധാരണയായി HTTP, MQTT, AMQP, XMPP എന്നിവയിലെ TLS അല്ലെങ്കിൽ CoAP-ലെ DTLS എന്നിവയെ അടിസ്ഥാനമാക്കിയുള്ളതാണ്, കൂടാതെ രണ്ട് DDS വേരിയന്റുകളേയും പിന്തുണയ്ക്കുന്നു.

പിന്തുണയ്‌ക്കുന്ന സൈഫർ സ്യൂട്ടുകളും കീകളും കൈമാറ്റം ചെയ്യുന്നതിനായി ക്ലയന്റും സെർവറും തമ്മിൽ ആശയവിനിമയം സ്ഥാപിക്കുന്ന പ്രക്രിയയോടെയാണ് TLS ഉം DTLS ഉം ആരംഭിക്കുന്നത്. സുരക്ഷിതമായ ഒരു ചാനലിൽ കൂടുതൽ ആശയവിനിമയം നടക്കുന്നുണ്ടെന്ന് ഉറപ്പാക്കാൻ രണ്ട് കക്ഷികളും സെറ്റുകൾ ചർച്ച ചെയ്യുന്നു. രണ്ടും തമ്മിലുള്ള വ്യത്യാസം UDP അടിസ്ഥാനമാക്കിയുള്ള DTLS-നെ വിശ്വസനീയമല്ലാത്ത കണക്ഷനിൽ പ്രവർത്തിക്കാൻ അനുവദിക്കുന്ന ചെറിയ പരിഷ്കാരങ്ങളിലാണ്.

ചെയ്തത് പരീക്ഷണ ആക്രമണങ്ങൾ TLS-ന്റെയും DTLS-ന്റെയും പല വ്യത്യസ്‌ത നിർവ്വഹണങ്ങൾ TLS ഒരു മികച്ച ജോലി ചെയ്‌തതായി കണ്ടെത്തി. പിശക് സഹിഷ്ണുത കാരണം DTLS-ലെ ആക്രമണങ്ങൾ കൂടുതൽ വിജയിച്ചു.

എന്നിരുന്നാലും, ഈ പ്രോട്ടോക്കോളുകളുടെ ഏറ്റവും വലിയ പ്രശ്നം, അവ യഥാർത്ഥത്തിൽ IoT-യിൽ ഉപയോഗിക്കുന്നതിന് വേണ്ടി രൂപകൽപ്പന ചെയ്തതല്ല, മൂടൽമഞ്ഞിലോ ക്ലൗഡിലോ പ്രവർത്തിക്കാൻ ഉദ്ദേശിച്ചുള്ളതല്ല എന്നതാണ്. ഹാൻഡ്‌ഷേക്കിംഗിലൂടെ, ഓരോ കണക്ഷൻ സ്ഥാപനത്തിലും അവർ അധിക ട്രാഫിക് ചേർക്കുന്നു, ഇത് കമ്പ്യൂട്ടിംഗ് ഉറവിടങ്ങൾ ചോർത്തുന്നു. സെക്യൂരിറ്റി ലെയർ ഇല്ലാത്ത ആശയവിനിമയങ്ങളുമായി താരതമ്യം ചെയ്യുമ്പോൾ ശരാശരി 6,5% TLS-നും 11% DTLS-നും ഓവർഹെഡിൽ വർധനവുണ്ട്. വിഭവ സമൃദ്ധമായ പരിതസ്ഥിതികളിൽ, അവ സാധാരണയായി സ്ഥിതിചെയ്യുന്നു മേഘാവൃതമായ ലെവൽ, ഇത് ഒരു പ്രശ്‌നമാകില്ല, പക്ഷേ ഐഒടിയും ഫോഗ് ലെവലും തമ്മിലുള്ള ബന്ധത്തിൽ ഇത് ഒരു പ്രധാന പരിമിതിയായി മാറുന്നു.

എന്താണ് തിരഞ്ഞെടുക്കേണ്ടത്? വ്യക്തമായ ഉത്തരമില്ല. മറ്റ് പ്രോട്ടോക്കോളുകളെ അപേക്ഷിച്ച് താരതമ്യേന കൂടുതൽ പക്വതയുള്ളതും കൂടുതൽ സ്ഥിരതയുള്ളതുമായ IoT സൊല്യൂഷനുകളായി കണക്കാക്കുന്നതിനാൽ MQTT, HTTP എന്നിവ ഏറ്റവും പ്രതീക്ഷ നൽകുന്ന പ്രോട്ടോക്കോളുകളായി തോന്നുന്നു.

ഒരു ഏകീകൃത ആശയവിനിമയ പ്രോട്ടോക്കോൾ അടിസ്ഥാനമാക്കിയുള്ള പരിഹാരങ്ങൾ

സിംഗിൾ-പ്രോട്ടോക്കോൾ സൊല്യൂഷന്റെ പരിശീലനത്തിന് നിരവധി ദോഷങ്ങളുമുണ്ട്. ഉദാഹരണത്തിന്, ഒരു നിയന്ത്രിത പരിതസ്ഥിതിക്ക് അനുയോജ്യമായ ഒരു പ്രോട്ടോക്കോൾ കർശനമായ സുരക്ഷാ ആവശ്യകതകളുള്ള ഒരു ഡൊമെയ്നിൽ പ്രവർത്തിച്ചേക്കില്ല. ഇത് മനസ്സിൽ വെച്ചുകൊണ്ട്, MQTT, REST HTTP എന്നിവ ഒഴികെ IoT-ലെ ഫോഗ്-ടു-ക്ലൗഡ് ഇക്കോസിസ്റ്റത്തിൽ സാധ്യമായ മിക്കവാറും എല്ലാ സിംഗിൾ-പ്രോട്ടോക്കോൾ സൊല്യൂഷനുകളും നിരസിക്കാൻ ഞങ്ങൾ ശേഷിക്കുന്നു.

ഒരൊറ്റ പ്രോട്ടോക്കോൾ പരിഹാരമായി REST HTTP

IoT-to-Fog സ്‌പെയ്‌സിൽ REST HTTP അഭ്യർത്ഥനകളും പ്രതികരണങ്ങളും എങ്ങനെ ഇടപെടുന്നു എന്നതിന് ഒരു നല്ല ഉദാഹരണമുണ്ട്: സ്മാർട്ട് ഫാം. മൃഗങ്ങളിൽ ധരിക്കാവുന്ന സെൻസറുകൾ (ഐഒടി ക്ലയന്റ്, സി) സജ്ജീകരിച്ചിരിക്കുന്നു കൂടാതെ ഒരു സ്മാർട്ട് ഫാമിംഗ് സിസ്റ്റം (ഫോഗ് സെർവർ, എസ്) വഴി ക്ലൗഡ് കമ്പ്യൂട്ടിംഗ് വഴി നിയന്ത്രിക്കുന്നു.

POST രീതിയുടെ തലക്കെട്ട് പരിഷ്‌ക്കരിക്കുന്നതിനുള്ള ഉറവിടവും (/ഫാം/മൃഗങ്ങൾ) കൂടാതെ HTTP പതിപ്പും ഉള്ളടക്ക തരവും വ്യക്തമാക്കുന്നു, ഈ സാഹചര്യത്തിൽ സിസ്റ്റം കൈകാര്യം ചെയ്യേണ്ട മൃഗ ഫാമിനെ പ്രതിനിധീകരിക്കുന്ന ഒരു JSON ഒബ്‌ജക്റ്റാണ് (ഡൾസീനിയ/പശു) . HTTPS സ്റ്റാറ്റസ് കോഡ് 201 അയച്ചുകൊണ്ട് അഭ്യർത്ഥന വിജയിച്ചതായി സെർവറിൽ നിന്നുള്ള പ്രതികരണം സൂചിപ്പിക്കുന്നു (വിഭവം സൃഷ്ടിച്ചത്). GET രീതി URI-യിൽ ആവശ്യപ്പെട്ട ഉറവിടം മാത്രം വ്യക്തമാക്കണം (ഉദാഹരണത്തിന്, /farm/animals/1), അത് സെർവറിൽ നിന്ന് ആ ഐഡിയുള്ള മൃഗത്തിന്റെ JSON പ്രാതിനിധ്യം നൽകുന്നു.

ചില പ്രത്യേക റിസോഴ്സ് റെക്കോർഡ് അപ്ഡേറ്റ് ചെയ്യേണ്ടി വരുമ്പോൾ PUT രീതി ഉപയോഗിക്കുന്നു. ഈ സാഹചര്യത്തിൽ, മാറ്റേണ്ട പാരാമീറ്ററിനും നിലവിലെ മൂല്യത്തിനും വേണ്ടിയുള്ള URI റിസോഴ്‌സ് വ്യക്തമാക്കുന്നു (ഉദാഹരണത്തിന്, പശു നിലവിൽ നടക്കുന്നുണ്ടെന്ന് സൂചിപ്പിക്കുന്നത്, /farm/animals/1? state=walking). അവസാനമായി, DELETE രീതി GET രീതിക്ക് തുല്യമായി ഉപയോഗിക്കുന്നു, എന്നാൽ പ്രവർത്തനത്തിന്റെ ഫലമായി റിസോഴ്സ് ഇല്ലാതാക്കുന്നു.

ഒരു ഏക-പ്രോട്ടോക്കോൾ പരിഹാരമായി MQTT

നമുക്ക് അതേ സ്മാർട്ട് ഫാം എടുക്കാം, എന്നാൽ REST HTTP ന് പകരം നമ്മൾ MQTT പ്രോട്ടോക്കോൾ ഉപയോഗിക്കുന്നു. മോസ്‌കിറ്റോ ലൈബ്രറി ഇൻസ്റ്റാൾ ചെയ്തിട്ടുള്ള ഒരു പ്രാദേശിക സെർവർ ഒരു ബ്രോക്കറായി പ്രവർത്തിക്കുന്നു. ഈ ഉദാഹരണത്തിൽ, ഒരു ലളിതമായ കമ്പ്യൂട്ടർ (ഫാം സെർവർ എന്നറിയപ്പെടുന്നു) റാസ്‌ബെറി പൈ ഒരു MQTT ക്ലയന്റ് ആയി പ്രവർത്തിക്കുന്നു, ഇത് മൊസ്‌കിറ്റോ ബ്രോക്കറുമായി പൂർണ്ണമായും പൊരുത്തപ്പെടുന്ന Paho MQTT ലൈബ്രറിയുടെ ഇൻസ്റ്റാളേഷനിലൂടെ നടപ്പിലാക്കുന്നു.

സെൻസിംഗ്, കമ്പ്യൂട്ടിംഗ് കഴിവുകളുള്ള ഒരു ഉപകരണത്തെ പ്രതിനിധീകരിക്കുന്ന ഒരു IoT അബ്‌സ്‌ട്രാക്ഷൻ ലെയറുമായി ഈ ക്ലയന്റ് യോജിക്കുന്നു. മറുവശത്ത്, മധ്യസ്ഥൻ ഉയർന്ന തോതിലുള്ള അമൂർത്തീകരണവുമായി പൊരുത്തപ്പെടുന്നു, ഇത് കൂടുതൽ പ്രോസസ്സിംഗും സംഭരണ ​​ശേഷിയും ഉള്ള ഒരു ഫോഗ് കമ്പ്യൂട്ടിംഗ് നോഡിനെ പ്രതിനിധീകരിക്കുന്നു.

നിർദ്ദിഷ്ട സ്മാർട്ട് ഫാം സാഹചര്യത്തിൽ, റാസ്‌ബെറി പൈ ആക്സിലറോമീറ്റർ, ജിപിഎസ്, താപനില സെൻസറുകൾ എന്നിവയുമായി ബന്ധിപ്പിക്കുകയും ഈ സെൻസറുകളിൽ നിന്നുള്ള ഡാറ്റ ഒരു ഫോഗ് നോഡിലേക്ക് പ്രസിദ്ധീകരിക്കുകയും ചെയ്യുന്നു. നിങ്ങൾക്കറിയാവുന്നതുപോലെ, MQTT വിഷയങ്ങളെ ഒരു ശ്രേണിയായി കണക്കാക്കുന്നു. ഒരൊറ്റ MQTT പ്രസാധകന് ഒരു നിർദ്ദിഷ്ട വിഷയങ്ങളിലേക്ക് സന്ദേശങ്ങൾ പ്രസിദ്ധീകരിക്കാൻ കഴിയും. ഞങ്ങളുടെ കാര്യത്തിൽ, അവയിൽ മൂന്നെണ്ണം ഉണ്ട്. ഒരു മൃഗശാലയിലെ താപനില അളക്കുന്ന ഒരു സെൻസറിനായി, ക്ലയന്റ് ഒരു തീം തിരഞ്ഞെടുക്കുന്നു (ആനിമൽഫാം/ഷെഡ്/താപനില). ആക്‌സിലറോമീറ്ററിലൂടെ ജിപിഎസ് ലൊക്കേഷനും മൃഗങ്ങളുടെ ചലനവും അളക്കുന്ന സെൻസറുകൾക്കായി, ക്ലയന്റ് (അനിമൽഫാം/ആനിമൽ/ജിപിഎസ്) കൂടാതെ (അനിമൽഫാം/ആനിമൽ/മൂവ്‌മെന്റ്) അപ്‌ഡേറ്റുകൾ പ്രസിദ്ധീകരിക്കും.

ഈ വിവരം ബ്രോക്കർക്ക് കൈമാറും, താൽപ്പര്യമുള്ള മറ്റൊരു സബ്‌സ്‌ക്രൈബർ പിന്നീട് വന്നാൽ അവർക്ക് ഇത് ഒരു പ്രാദേശിക ഡാറ്റാബേസിൽ താൽക്കാലികമായി സംഭരിക്കാൻ കഴിയും.

മൂടൽമഞ്ഞിൽ MQTT ബ്രോക്കറായി പ്രവർത്തിക്കുന്ന ലോക്കൽ സെർവറിന് പുറമേ, MQTT ക്ലയന്റുകളായി പ്രവർത്തിക്കുന്ന Raspberry Pis സെൻസർ ഡാറ്റ അയയ്ക്കുന്നു, ക്ലൗഡ് തലത്തിൽ മറ്റൊരു MQTT ബ്രോക്കർ ഉണ്ടായിരിക്കാം. ഈ സാഹചര്യത്തിൽ, പ്രാദേശിക ബ്രോക്കറിലേക്ക് കൈമാറുന്ന വിവരങ്ങൾ ഒരു പ്രാദേശിക ഡാറ്റാബേസിൽ താൽക്കാലികമായി സംഭരിക്കാനും കൂടാതെ/അല്ലെങ്കിൽ ക്ലൗഡിലേക്ക് അയയ്ക്കാനും കഴിയും. ഈ സാഹചര്യത്തിൽ ഫോഗ് MQTT ബ്രോക്കർ എല്ലാ ഡാറ്റയും ക്ലൗഡ് MQTT ബ്രോക്കറുമായി ബന്ധപ്പെടുത്താൻ ഉപയോഗിക്കുന്നു. ഈ ആർക്കിടെക്ചർ ഉപയോഗിച്ച്, ഒരു മൊബൈൽ ആപ്ലിക്കേഷൻ ഉപയോക്താവിന് രണ്ട് ബ്രോക്കർമാർക്കും സബ്‌സ്‌ക്രൈബുചെയ്യാനാകും.

ബ്രോക്കർമാരിൽ ഒരാളുമായുള്ള (ഉദാഹരണത്തിന്, ക്ലൗഡ്) കണക്ഷൻ പരാജയപ്പെടുകയാണെങ്കിൽ, അന്തിമ ഉപയോക്താവിന് മറ്റേയാളിൽ നിന്ന് (മൂടൽമഞ്ഞ്) വിവരങ്ങൾ ലഭിക്കും. സംയോജിത മൂടൽമഞ്ഞ്, ക്ലൗഡ് കമ്പ്യൂട്ടിംഗ് സിസ്റ്റങ്ങളുടെ ഒരു സവിശേഷതയാണിത്. ഡിഫോൾട്ടായി, ആദ്യം ഫോഗ് MQTT ബ്രോക്കറിലേക്ക് കണക്‌റ്റ് ചെയ്യാനും അത് പരാജയപ്പെടുകയാണെങ്കിൽ, ക്ലൗഡ് MQTT ബ്രോക്കറിലേക്ക് കണക്‌റ്റ് ചെയ്യാനും മൊബൈൽ ആപ്പ് കോൺഫിഗർ ചെയ്യാനാകും. ഈ പരിഹാരം IoT-F2C സിസ്റ്റങ്ങളിലെ പലതിലും ഒന്ന് മാത്രമാണ്.

മൾട്ടി-പ്രോട്ടോക്കോൾ പരിഹാരങ്ങൾ

എളുപ്പത്തിൽ നടപ്പിലാക്കുന്നതിനാൽ ഒറ്റ പ്രോട്ടോക്കോൾ പരിഹാരങ്ങൾ ജനപ്രിയമാണ്. എന്നാൽ IoT-F2C സിസ്റ്റങ്ങളിൽ വ്യത്യസ്ത പ്രോട്ടോക്കോളുകൾ സംയോജിപ്പിക്കുന്നതിൽ അർത്ഥമുണ്ടെന്ന് വ്യക്തമാണ്. വ്യത്യസ്ത പ്രോട്ടോക്കോളുകൾക്ക് വ്യത്യസ്ത തലങ്ങളിൽ പ്രവർത്തിക്കാൻ കഴിയും എന്നതാണ് ആശയം. ഉദാഹരണത്തിന്, മൂന്ന് അമൂർത്തങ്ങൾ എടുക്കുക: IoT, മൂടൽമഞ്ഞ്, ക്ലൗഡ് കമ്പ്യൂട്ടിംഗ് എന്നിവയുടെ പാളികൾ. IoT തലത്തിലുള്ള ഉപകരണങ്ങൾ സാധാരണയായി പരിമിതമായി കണക്കാക്കപ്പെടുന്നു. ഈ അവലോകനത്തിനായി, IoT നിരകൾ ഏറ്റവും പരിമിതമായതും ക്ലൗഡ് ഏറ്റവും കുറഞ്ഞ നിയന്ത്രണമുള്ളതും ഫോഗ് കമ്പ്യൂട്ടിംഗിനെ "മധ്യത്തിൽ എവിടെയോ" ആയി കണക്കാക്കാം. IoT, ഫോഗ് അമൂർത്തങ്ങൾ എന്നിവയ്ക്കിടയിൽ, നിലവിലെ പ്രോട്ടോക്കോൾ പരിഹാരങ്ങളിൽ MQTT, CoAP, XMPP എന്നിവ ഉൾപ്പെടുന്നു. മറുവശത്ത്, മൂടൽമഞ്ഞിനും മേഘത്തിനും ഇടയിൽ, REST HTTP-യ്‌ക്കൊപ്പം ഉപയോഗിക്കുന്ന പ്രധാന പ്രോട്ടോക്കോളുകളിൽ ഒന്നാണ് AMQP, അതിന്റെ വഴക്കം കാരണം IoT, മൂടൽമഞ്ഞ് പാളികൾക്കിടയിലും ഇത് ഉപയോഗിക്കുന്നു.

ഇവിടെ പ്രധാന പ്രശ്നം പ്രോട്ടോക്കോളുകളുടെ പരസ്പര പ്രവർത്തനക്ഷമതയും ഒരു പ്രോട്ടോക്കോളിൽ നിന്ന് മറ്റൊന്നിലേക്ക് സന്ദേശങ്ങൾ കൈമാറുന്നതിനുള്ള എളുപ്പവുമാണ്. ഭാവിയിൽ, ക്ലൗഡ്, ഫോഗ് റിസോഴ്‌സുകളുള്ള ഒരു ഇന്റർനെറ്റ് ഓഫ് തിംഗ്സ് സിസ്റ്റത്തിന്റെ ആർക്കിടെക്ചർ ഉപയോഗിക്കുന്ന ആശയവിനിമയ പ്രോട്ടോക്കോളിൽ നിന്ന് സ്വതന്ത്രമായിരിക്കും കൂടാതെ വ്യത്യസ്ത പ്രോട്ടോക്കോളുകൾക്കിടയിൽ നല്ല പരസ്പര പ്രവർത്തനക്ഷമത ഉറപ്പാക്കുകയും ചെയ്യും.

ഇത് നിലവിൽ അല്ലാത്തതിനാൽ, കാര്യമായ വ്യത്യാസങ്ങളില്ലാത്ത പ്രോട്ടോക്കോളുകൾ സംയോജിപ്പിക്കുന്നത് യുക്തിസഹമാണ്. ഇതിനായി, ഒരേ വാസ്തുവിദ്യാ ശൈലി പിന്തുടരുന്ന രണ്ട് പ്രോട്ടോക്കോളുകളുടെ സംയോജനത്തെ അടിസ്ഥാനമാക്കിയുള്ളതാണ് ഒരു സാധ്യതയുള്ള പരിഹാരം, REST HTTP, CoAP. പ്രസിദ്ധീകരണ-സബ്‌സ്‌ക്രൈബ് ആശയവിനിമയം വാഗ്ദാനം ചെയ്യുന്ന രണ്ട് പ്രോട്ടോക്കോളുകളുടെ സംയോജനത്തെ അടിസ്ഥാനമാക്കിയുള്ളതാണ് മറ്റൊരു നിർദ്ദിഷ്ട പരിഹാരം, MQTT, AMQP. സമാന ആശയങ്ങൾ ഉപയോഗിക്കുന്നത് (MQTT, AMQP എന്നിവ ബ്രോക്കർമാരെ ഉപയോഗിക്കുന്നു, CoAP, HTTP എന്നിവ REST ഉപയോഗിക്കുന്നു) ഈ കോമ്പിനേഷനുകൾ നടപ്പിലാക്കുന്നത് എളുപ്പമാക്കുന്നു, കൂടാതെ കുറഞ്ഞ ഏകീകരണ പരിശ്രമം ആവശ്യമാണ്.

ചിത്രം (a) HTTP, CoAP എന്നീ രണ്ട് അഭ്യർത്ഥന-പ്രതികരണത്തെ അടിസ്ഥാനമാക്കിയുള്ള മോഡലുകളും ഒരു IoT-F2C സൊല്യൂഷനിൽ അവയുടെ സാധ്യമായ പ്ലേസ്‌മെന്റും കാണിക്കുന്നു. ആധുനിക നെറ്റ്‌വർക്കുകളിലെ ഏറ്റവും അറിയപ്പെടുന്നതും സ്വീകരിച്ചതുമായ പ്രോട്ടോക്കോളുകളിൽ ഒന്നാണ് HTTP എന്നതിനാൽ, മറ്റ് സന്ദേശമയയ്‌ക്കൽ പ്രോട്ടോക്കോളുകൾ ഉപയോഗിച്ച് ഇത് പൂർണ്ണമായും മാറ്റിസ്ഥാപിക്കാൻ സാധ്യതയില്ല. മേഘത്തിനും മൂടൽമഞ്ഞിനും ഇടയിൽ ഇരിക്കുന്ന ശക്തമായ ഉപകരണങ്ങളെ പ്രതിനിധീകരിക്കുന്ന നോഡുകളിൽ, REST HTTP ഒരു മികച്ച പരിഹാരമാണ്.

മറുവശത്ത്, ഫോഗ്, ഐഒടി പാളികൾക്കിടയിൽ ആശയവിനിമയം നടത്തുന്ന പരിമിതമായ കമ്പ്യൂട്ടിംഗ് ഉറവിടങ്ങളുള്ള ഉപകരണങ്ങൾക്കായി, CoAP ഉപയോഗിക്കുന്നത് കൂടുതൽ കാര്യക്ഷമമാണ്. രണ്ട് പ്രോട്ടോക്കോളുകളും REST തത്ത്വങ്ങളെ അടിസ്ഥാനമാക്കിയുള്ളതിനാൽ, CoAP-യുടെ വലിയ നേട്ടങ്ങളിലൊന്ന് യഥാർത്ഥത്തിൽ HTTP-യുമായുള്ള അനുയോജ്യതയാണ്.

MQTT, AMQP എന്നിവയുൾപ്പെടെ ഒരേ സാഹചര്യത്തിൽ രണ്ട് പ്രസിദ്ധീകരണ-സബ്‌സ്‌ക്രൈബ് ആശയവിനിമയ മോഡലുകൾ ചിത്രം (ബി) കാണിക്കുന്നു. ഓരോ അബ്‌സ്‌ട്രാക്ഷൻ ലെയറിലും നോഡുകൾ തമ്മിലുള്ള ആശയവിനിമയത്തിന് രണ്ട് പ്രോട്ടോക്കോളുകളും സാങ്കൽപ്പികമായി ഉപയോഗിക്കാമെങ്കിലും, പ്രകടനത്തെ അടിസ്ഥാനമാക്കി അവയുടെ സ്ഥാനം നിർണ്ണയിക്കണം. പരിമിതമായ കമ്പ്യൂട്ടിംഗ് റിസോഴ്‌സുകളുള്ള ഉപകരണങ്ങൾക്കായുള്ള ഭാരം കുറഞ്ഞ പ്രോട്ടോക്കോളായാണ് MQTT രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത്, അതിനാൽ ഇത് IoT-Fog ആശയവിനിമയത്തിനായി ഉപയോഗിക്കാം. കൂടുതൽ ശക്തമായ ഉപകരണങ്ങൾക്ക് AMQP കൂടുതൽ അനുയോജ്യമാണ്, അത് മൂടൽമഞ്ഞിനും ക്ലൗഡ് നോഡുകൾക്കും ഇടയിൽ സ്ഥാപിക്കും. എംക്യുടിടിക്ക് പകരം, ഭാരം കുറഞ്ഞതായി കണക്കാക്കുന്നതിനാൽ ഐഒടിയിൽ എക്സ്എംപിപി പ്രോട്ടോക്കോൾ ഉപയോഗിക്കാം. എന്നാൽ അത്തരം സാഹചര്യങ്ങളിൽ ഇത് വ്യാപകമായി ഉപയോഗിക്കപ്പെടുന്നില്ല.

കണ്ടെത്തലുകൾ

പരിമിതമായ കമ്പ്യൂട്ടിംഗ് ഉറവിടങ്ങളുള്ള ഉപകരണങ്ങൾ മുതൽ ക്ലൗഡ് സെർവറുകൾ വരെയുള്ള ഒരു സിസ്റ്റത്തിലെ എല്ലാ ആശയവിനിമയങ്ങളും ഉൾക്കൊള്ളാൻ ചർച്ച ചെയ്ത പ്രോട്ടോക്കോളുകളിൽ ഒന്ന് പര്യാപ്തമാകാൻ സാധ്യതയില്ല. ഡെവലപ്പർമാർ ഏറ്റവും കൂടുതൽ ഉപയോഗിക്കുന്ന രണ്ട് വാഗ്ദാനമായ ഓപ്ഷനുകൾ MQTT, RESTful HTTP എന്നിവയാണെന്ന് പഠനം കണ്ടെത്തി. ഈ രണ്ട് പ്രോട്ടോക്കോളുകളും ഏറ്റവും പക്വതയുള്ളതും സ്ഥിരതയുള്ളതും മാത്രമല്ല, നന്നായി രേഖപ്പെടുത്തപ്പെട്ടതും വിജയകരവുമായ നിരവധി നടപ്പാക്കലുകളും ഓൺലൈൻ ഉറവിടങ്ങളും ഉൾപ്പെടുന്നു.

സ്ഥിരതയും ലളിതമായ കോൺഫിഗറേഷനും കാരണം, പരിമിതമായ ഉപകരണങ്ങളിൽ IoT തലത്തിൽ ഉപയോഗിക്കുമ്പോൾ കാലക്രമേണ അതിന്റെ മികച്ച പ്രകടനം തെളിയിച്ച ഒരു പ്രോട്ടോക്കോൾ ആണ് MQTT. ചില ഫോഗ് ഡൊമെയ്‌നുകളും മിക്ക ക്ലൗഡ് കമ്പ്യൂട്ടിംഗും പോലുള്ള പരിമിതമായ ആശയവിനിമയവും ബാറ്ററി ഉപഭോഗവും ഒരു പ്രശ്‌നമല്ലാത്ത സിസ്റ്റത്തിന്റെ ഭാഗങ്ങളിൽ, RESTful HTTP എന്നത് എളുപ്പമുള്ള തിരഞ്ഞെടുപ്പാണ്. CoAP ഒരു IoT സന്ദേശമയയ്‌ക്കൽ സ്റ്റാൻഡേർഡായി അതിവേഗം വികസിച്ചുകൊണ്ടിരിക്കുന്നതിനാൽ ഇത് കണക്കിലെടുക്കേണ്ടതാണ്, മാത്രമല്ല ഇത് സമീപഭാവിയിൽ MQTT, HTTP എന്നിവയ്ക്ക് സമാനമായ സ്ഥിരതയിലും പക്വതയിലും എത്താൻ സാധ്യതയുണ്ട്. എന്നാൽ നിലവാരം നിലവിൽ വികസിച്ചുകൊണ്ടിരിക്കുന്നു, ഇത് ഹ്രസ്വകാല അനുയോജ്യത പ്രശ്നങ്ങളുമായി വരുന്നു.

ബ്ലോഗിൽ നിങ്ങൾക്ക് മറ്റെന്താണ് വായിക്കാൻ കഴിയുക? Cloud4Y

→ കമ്പ്യൂട്ടർ നിങ്ങളെ രുചികരമാക്കും
→ ആഫ്രിക്കയിലെ മൃഗങ്ങളെ പഠിക്കാൻ AI സഹായിക്കുന്നു
→ വേനൽക്കാലം ഏതാണ്ട് അവസാനിച്ചു. ചോരാത്ത ഡാറ്റകളൊന്നും അവശേഷിക്കുന്നില്ല
→ ക്ലൗഡ് ബാക്കപ്പുകളിൽ സംരക്ഷിക്കാനുള്ള 4 വഴികൾ
→ ജനസംഖ്യയെക്കുറിച്ചുള്ള വിവരങ്ങൾ ഉൾക്കൊള്ളുന്ന ഒരു ഏകീകൃത ഫെഡറൽ വിവര ഉറവിടത്തിൽ

ഞങ്ങളുടെ സബ്സ്ക്രൈബ് ചെയ്യുക കന്വിസന്ദേശം-ചാനൽ, അതിനാൽ നിങ്ങൾക്ക് അടുത്ത ലേഖനം നഷ്‌ടമാകില്ല! ഞങ്ങൾ ആഴ്ചയിൽ രണ്ടുതവണയിൽ കൂടുതൽ എഴുതുന്നില്ല, ബിസിനസ്സിൽ മാത്രം.

അവലംബം: www.habr.com