De ûntwikkeling fan technologyen op it mêd fan software en hardware, it ûntstean fan nije kommunikaasjeprotokollen hawwe laat ta de útwreiding fan it Internet of Things (IoT). It oantal apparaten groeit dei foar dei en se generearje in enoarme hoemannichte gegevens. Dêrom is d'r ferlet fan in handige systeemarsjitektuer dy't dizze gegevens kin ferwurkje, opslaan en oerdrage.
No wurde wolktsjinsten foar dizze doelen brûkt. It hieltyd populêrere mistkomputerparadigma (Fog) kin lykwols wolkoplossingen oanfolje troch IoT-ynfrastruktuer te skaaljen en te optimalisearjen.
Wolken binne by steat om de measte IoT-oanfragen te dekken. Bygelyks, om tafersjoch op tsjinsten te leverjen, rappe ferwurking fan elke hoemannichte gegevens generearre troch apparaten, lykas har fisualisaasje. Mistberekkening is effektiver by it oplossen fan real-time problemen. Se jouwe rappe antwurd op oanfragen en minimale latency yn gegevensferwurking. Dat is, Fog komplementearret de "wolken" en wreidet syn mooglikheden út.
De wichtichste fraach is lykwols oars: hoe moat dit alles ynteraksje yn 'e kontekst fan IoT? Hokker kommunikaasjeprotokollen sille it meast effektyf wêze as jo wurkje yn in kombineare IoT-Fog-Cloud-systeem?
Nettsjinsteande de skynbere dominânsje fan HTTP, binne d'r in grut oantal oare oplossingen brûkt yn IoT-, Mist- en Cloud-systemen. Dit is om't IoT de funksjonaliteit fan in ferskaat oan apparaatsensors kombinearje moat mei de feiligens, kompatibiliteit en oare easken fan brûkers.
Mar d'r is gewoan gjin inkeld idee oer de referinsjearsjitektuer en kommunikaasjestandert. Dêrom is it meitsjen fan in nij protokol of it wizigjen fan in besteande ien foar spesifike IoT-taken ien fan 'e wichtichste taken foar de IT-mienskip.
Hokker protokollen binne op it stuit yn gebrûk en wat kinne se biede? Litte wy it útfine. Mar earst litte wy de prinsipes besprekke fan it ekosysteem wêryn wolken, mist en it ynternet fan dingen ynteraksje.
IoT Fog-to-Cloud (F2C) Architecture
Jo hawwe wierskynlik opfallen hoefolle muoite wurdt dien om de foardielen en foardielen te ferkennen ferbûn mei tûk en koördinearre behear fan IoT, wolk en mist. Sa net, dan binne hjir trije standerdisearringsinisjativen: , и .
As earder allinich 2 nivo's waarden beskôge, wolken en einapparaten, dan yntroduseart de foarstelde arsjitektuer in nij nivo - mistkomputerjen. Yn dit gefal kin it mistnivo wurde ferdield yn ferskate subnivo's, ôfhinklik fan 'e spesifikaasjes fan boarnen as in set fan belied dy't it gebrûk fan ferskate apparaten yn dizze subnivo's bepale.
Hoe kin dizze abstraksje der útsjen? Hjir is in typysk IoT-Fog-Cloud-ekosysteem. IoT-apparaten stjoere gegevens nei rappere servers en komputerapparaten om problemen op te lossen dy't lege latency nedich binne. Yn itselde systeem binne wolken ferantwurdlik foar it oplossen fan problemen dy't in grutte hoemannichte komputerboarnen as gegevensopslachromte nedich binne.
Snoadfoans, tûke horloazjes en oare gadgets kinne ek diel útmeitsje fan it IoT. Mar sokke apparaten brûke yn 'e regel proprietêre kommunikaasjeprotokollen fan grutte ûntwikkelders. De generearre IoT-gegevens wurde oerbrocht nei de mistlaach fia it REST HTTP-protokol, dat fleksibiliteit en ynteroperabiliteit leveret by it meitsjen fan RESTful tsjinsten. Dit is wichtich yn it ljocht fan 'e needsaak om efterútkompatibiliteit te garandearjen mei besteande komputerynfrastruktuer dy't rint op lokale kompjûters, servers of in serverkluster. Lokale boarnen, neamd "misknooppunten", filterje de ûntfongen gegevens en ferwurkje se lokaal of stjoer it nei de wolk foar fierdere berekkeningen.
Wolken stypje ferskate kommunikaasjeprotokollen, de meast foarkommende binne AMQP en REST HTTP. Sûnt HTTP is bekend en oanpast foar it ynternet, kin de fraach opkomme: "moatte wy it net brûke om te wurkjen mei IoT en mist?" Dit protokol hat lykwols prestaasjesproblemen. Mear hjiroer letter.
Yn 't algemien binne d'r 2-modellen fan kommunikaasjeprotokollen geskikt foar it systeem dat wy nedich binne. Dit binne fersyk-antwurd en publisearje-abonnearje. It earste model is mear bekend, benammen yn server-client-arsjitektuer. De kliïnt freget ynformaasje fan 'e tsjinner, en de tsjinner ûntfangt it fersyk, ferwurket it en jout in antwurdberjocht werom. De REST HTTP- en CoAP-protokollen wurkje op dit model.
It twadde model ûntstie út 'e needsaak om asynchrone, ferdielde, losse keppeling te leverjen tusken de boarnen dy't gegevens generearje en de ûntfangers fan dizze gegevens.
It model giet út fan trije dielnimmers: in útjouwer (gegevensboarne), in makelder (stjoerder) en in abonnee (ûntfanger). Hjir hoecht de kliïnt dy't as abonnee optreedt gjin ynformaasje fan 'e tsjinner op te freegjen. Ynstee fan it ferstjoeren fan fersiken, abonnearret it op bepaalde eveneminten yn it systeem fia in broker, dy't ferantwurdlik is foar it filterjen fan alle ynkommende berjochten en it routing tusken útjouwers en abonnees. En de útjouwer, as in evenemint foarkomt oangeande in bepaald ûnderwerp, publisearret it oan 'e brokker, dy't gegevens oer it frege ûnderwerp nei de abonnee stjoert.
Yn essinsje is dizze arsjitektuer basearre op eveneminten. En dit ynteraksjemodel is ynteressant foar applikaasjes yn IoT, wolk, mist fanwegen syn fermogen om skaalberens te leverjen en de ûnderlinge ferbining tusken ferskate apparaten te ferienfâldigjen, dynamyske kommunikaasje fan in protte-to-in protte en asynchrone kommunikaasje te stypjen. Guon fan 'e meast bekende standerdisearre berjochtenprotokollen dy't in publisearje-abonnemintmodel brûke omfetsje MQTT, AMQP en DDS.
Fansels hat it publisearje-abonnemintmodel in protte foardielen:
- Utjouwers en abonnees hoege net fan inoars bestean te witten;
- Ien abonnee kin ûntfange ynformaasje fan in protte ferskillende publikaasjes, en ien útjouwer kin stjoere gegevens nei in protte ferskillende abonnees (in protte-to-in protte prinsipe);
- De útjouwer en de abonnee hoege net tagelyk aktyf te wêzen om te kommunisearjen, om't de broker (wurket as in wachtrige systeem) it berjocht opslaan kin foar kliïnten dy't op it stuit net ferbûn binne mei it netwurk.
It fersyk-antwurd-model hat lykwols ek syn sterke punten. Yn gefallen dêr't it fermogen fan 'e serverside om meardere kliïntoanfragen te behanneljen gjin probleem is, makket it sin om bewiisde, betroubere oplossingen te brûken.
D'r binne ek protokollen dy't beide modellen stypje. Bygelyks XMPP en HTTP 2.0, dy't de opsje "tsjinner push" stypje. De IETF hat ek in CoAP frijlitten. Yn in besykjen om it messagingprobleem op te lossen, binne ferskate oare oplossings makke, lykas it WebSockets-protokol of it brûken fan it HTTP-protokol oer QUIC (Quick UDP Internet Connections).
Yn it gefal fan WebSockets, hoewol it wurdt brûkt foar it oerdragen fan gegevens yn echte tiid fan in tsjinner nei in webkliïnt en soarget foar oanhâldende ferbiningen mei simultane bidirectionele kommunikaasje, it is net bedoeld foar apparaten mei beheinde komputerboarnen. QUIC fertsjinnet ek omtinken, om't it nije transportprotokol in soad nije kânsen jout. Mar om't QUIC noch net standerdisearre is, is it te betiid om har mooglike tapassing en ynfloed op IoT-oplossingen te foarsizzen. Dat wy hâlde WebSockets en QUIC yn gedachten mei it each op 'e takomst, mar wy sille it no net mear yn detail bestudearje.
Wa is de leukste yn 'e wrâld: protokollen fergelykje
Litte wy no prate oer de sterke en swakke punten fan protokollen. Foarútsjen litte wy daliks in reservearje meitsje dat der gjin ien dúdlike lieder is. Elk protokol hat wat foardielen / neidielen.
Antwurd tiid
Ien fan 'e wichtichste skaaimerken fan kommunikaasjeprotokollen, benammen yn relaasje ta it Internet of Things, is antwurdtiid. Mar ûnder de besteande protokollen is d'r gjin dúdlike winner dy't it minimale nivo fan latency toant by it wurkjen ûnder ferskate omstannichheden. Mar d'r is in hiele bosk ûndersyk en fergelikingen fan protokolmooglikheden.
Bygelyks, fergeliking fan 'e effektiviteit fan HTTP en MQTT by it wurkjen mei IoT die bliken dat de antwurdtiid foar oanfragen foar MQTT minder is as foar HTTP. En wannear De rûnreistiid (RTT) fan MQTT en CoAP die bliken dat de gemiddelde RTT fan CoAP 20% minder is as dy fan MQTT.
Oar mei RTT foar de MQTT- en CoAP-protokollen waard útfierd yn twa senario's: lokaal netwurk en IoT-netwurk. It die bliken dat de gemiddelde RTT 2-3 kear heger is yn in IoT-netwurk. MQTT mei QoS0 liet in leger resultaat sjen yn ferliking mei CoAP, en MQTT mei QoS1 liet in hegere RTT sjen troch ACK's by de applikaasje- en transportlagen. Foar ferskate QoS-nivo's wie netwurklatens sûnder oerlêst millisekonden foar MQTT, en hûnderten mikrosekonden foar CoAP. It is lykwols de muoite wurdich om te ûnthâlden dat by it wurkjen oan minder betroubere netwurken, MQTT dy't boppe op TCP rint, sil in folslein oar resultaat sjen litte.
reaksjetiid foar de AMQP- en MQTT-protokollen troch it fergrutsjen fan de loadload die bliken dat mei in lichte lading it latencynivo hast itselde is. Mar by it oerdragen fan grutte hoemannichten gegevens, toant MQTT koartere antwurdtiden. yn ien mear CoAP waard fergelike mei HTTP yn in masine-oan-masine kommunikaasje-senario mei apparaten ynset boppe op auto's útrist mei gassensors, waarsensors, lokaasjesensors (GPS) en in mobile netwurkynterface (GPRS). De tiid nedich om in CoAP-berjocht oer it mobile netwurk te ferstjoeren wie hast trije kear koarter as de tiid dy't nedich is om HTTP-berjochten te brûken.
Stúdzjes binne útfierd dy't net twa, mar trije protokollen fergelike. Bygelyks, prestaasjes fan IoT-protokollen MQTT, DDS en CoAP yn in senario foar medyske applikaasjes mei in netwurkemulator. DDS prestearre better as MQTT yn termen fan teste telemetry-latinsje ûnder in ferskaat oan minne netwurkbetingsten. UDP-basearre CoAP wurke goed foar applikaasjes dy't rappe reaksjetiden easke, lykwols, om't it UDP-basearre wie, wie d'r signifikant ûnfoarspelber pakketferlies.
Trochput
MQTT en CoAP yn termen fan bânbreedte effisjinsje waard útfierd as in berekkening fan de totale hoemannichte gegevens oerdroegen per berjocht. CoAP hat in legere trochslach toand as MQTT by it ferstjoeren fan lytse berjochten. Mar by it fergelykjen fan de effisjinsje fan protokollen yn termen fan 'e ferhâlding fan it oantal nuttige ynformaasjebytes nei it totale oantal oerdroegen bytes, die CoAP effektiver.
at mei help fan MQTT, DDS (mei TCP as it ferfier protokol) en CoAP bânbreedte, waard fûn dat CoAP algemien toande relatyf legere bânbreedte konsumpsje, dat net tanommen mei ferhege netwurk pakket ferlies of ferhege netwurk latency, yn tsjinstelling ta MQTT en DDS, dêr't der wie in tanimming fan bânbreedte benutten yn de neamde senario. In oar senario belutsen in grut oantal apparaten dy't gegevens tagelyk ferstjoere, wat typysk is yn IoT-omjouwings. De resultaten lieten sjen dat foar hegere benutting it better is om CoAP te brûken.
Under lichte lading brûkte CoAP de minste bânbreedte, folge troch MQTT en REST HTTP. Doe't de grutte fan 'e ladingen lykwols ferhege, hie REST HTTP de bêste resultaten.
Stromverbrauch
De kwestje fan enerzjyferbrûk is altyd fan grut belang, en benammen yn in IoT-systeem. As Wylst MQTT en HTTP elektrisiteit konsumearje, konsumearret HTTP folle mear. En CoAP is mear ferlike mei MQTT, wêrtroch macht behear. Yn ienfâldige senario's is MQTT lykwols mear geskikt foar it útwikseljen fan ynformaasje yn Internet of Things-netwurken, foaral as d'r gjin krêftbeperkingen binne.
In eksperimint dat de mooglikheden fan AMQP en MQTT fergelike op in mobyl as ynstabyl draadloze netwurk testbed fûn dat AMQP mear feiligensmooglikheden biedt, wylst MQTT enerzjysuniger is.
Feiligens
Feiligens is in oar kritysk probleem dat oanbrocht wurdt by it bestudearjen fan it ûnderwerp fan it Internet of Things en mist / wolkekompjûter. It feiligensmeganisme is typysk basearre op TLS yn HTTP, MQTT, AMQP en XMPP, of DTLS yn CoAP, en stipet beide DDS-farianten.
TLS en DTLS begjinne mei it proses fan it oprjochtsjen fan kommunikaasje tusken de client- en serverkanten om stipe siffersuites en kaaien út te wikseljen. Beide partijen ûnderhannelje oer sets om te soargjen dat fierdere kommunikaasje op in feilich kanaal bart. It ferskil tusken de twa leit yn lytse oanpassings wêrtroch UDP-basearre DTLS kin wurkje oer in ûnbetroubere ferbining.
at Ferskate ferskillende ymplemintaasjes fan TLS en DTLS fûnen dat TLS in bettere baan die. Oanfallen op DTLS wiene súksesfol troch syn flatertolerânsje.
It grutste probleem mei dizze protokollen is lykwols dat se net oarspronklik binne ûntworpen foar gebrûk yn IoT en wiene net bedoeld om te wurkjen yn 'e mist of wolk. Troch handshaking foegje se ekstra ferkear ta mei elke ferbiningsynstelling, dy't komputerboarnen drainet. Gemiddeld is d'r in ferheging fan 6,5% foar TLS en 11% foar DTLS yn overhead yn ferliking mei kommunikaasje sûnder in befeiligingslaach. Yn boarne-rike omjouwings, dy't typysk leit op nivo, dit sil gjin probleem, mar yn 'e ferbining tusken IoT en mist nivo, dit wurdt in wichtige beheining.
Wat te kiezen? Der is gjin dúdlik antwurd. MQTT en HTTP lykje de meast kânsrike protokollen te wêzen, om't se wurde beskôge as relatyf mear folwoeksen en stabiler IoT-oplossingen yn ferliking mei oare protokollen.
Oplossings basearre op in unifoarme kommunikaasjeprotokol
De praktyk fan in oplossing mei ien protokol hat in protte neidielen. Bygelyks, in protokol dat past by in beheinde omjouwing kin miskien net wurkje yn in domein dat strikte feiligenseasken hat. Mei dit yn gedachten binne wy oerlitten om hast alle mooglike oplossingen foar ien protokol yn it Fog-to-Cloud-ekosysteem yn IoT te ferwiderjen, útsein MQTT en REST HTTP.
REST HTTP as ien-protokol-oplossing
D'r is in goed foarbyld fan hoe't REST HTTP-oanfragen en antwurden ynteraksje yn 'e IoT-to-Fog-romte: . De bisten binne foarsjoen fan wearable sensoren (IoT client, C) en regele fia cloud computing troch in tûk lânbou systeem (Fog server, S).
De koptekst fan 'e POST-metoade spesifiseart de boarne om te wizigjen (/farm/dieren) lykas de HTTP-ferzje en ynhâldstype, dy't yn dit gefal in JSON-objekt is dat de bisteboerderij fertsjintwurdiget dy't it systeem beheart (Dulcinea / ko) . It antwurd fan de tsjinner jout oan dat it fersyk suksesfol wie troch it ferstjoeren fan HTTPS-statuskoade 201 (boarne oanmakke). De GET-metoade moat allinich de frege boarne spesifisearje yn 'e URI (bygelyks /farm/dieren/1), dy't in JSON-fertsjintwurdiging fan it bist mei dy ID fan 'e tsjinner werombringt.
De PUT-metoade wurdt brûkt as guon spesifike boarne-record bywurke wurde moat. Yn dit gefal spesifisearret de boarne de URI foar de te feroarjen parameter en de aktuele wearde (bygelyks oanjout dat de ko op it stuit rint, /farm/dieren/1? state=walking). Uteinlik wurdt de DELETE-metoade likegoed brûkt as de GET-metoade, mar wisket gewoan de boarne as gefolch fan 'e operaasje.
MQTT as ien-protokol oplossing
Litte wy deselde tûke pleats nimme, mar ynstee fan REST HTTP brûke wy it MQTT-protokol. In lokale server mei de Mosquitto-biblioteek ynstalleare fungearret as broker. Yn dit foarbyld tsjinnet in ienfâldige kompjûter (oantsjutten as de pleatsserver) Raspberry Pi as in MQTT-kliïnt, útfierd troch in ynstallaasje fan 'e Paho MQTT-bibleteek, dy't folslein kompatibel is mei de Mosquitto-broker.
Dizze klant komt oerien mei in IoT-abstraksjelaach dy't in apparaat fertsjintwurdiget mei sensing- en komputermooglikheden. De mediator, oan 'e oare kant, komt oerien mei in heger nivo fan abstraksje, dy't in mist computing-knooppunt fertsjintwurdiget, karakterisearre troch gruttere ferwurkings- en opslachkapasiteit.
Yn it foarstelde smart farm-senario ferbynt de Raspberry Pi mei de accelerometer, GPS, en temperatuersensors en publisearret gegevens fan dizze sensoren nei in mistknooppunt. Lykas jo wierskynlik witte, behannelet MQTT ûnderwerpen as in hiërargy. In inkele MQTT-útjouwer kin berjochten publisearje nei in spesifike set fan ûnderwerpen. Yn ús gefal binne der trije fan harren. Foar in sensor dy't de temperatuer yn in bisteskuorre mjit, kiest de klant in tema (dierbuorkerij/skuorre/temperatuer). Foar sensoren dy't GPS-lokaasje en dierbeweging mjitte troch de accelerometer, sil de kliïnt updates publisearje nei (dierfarm/dier/GPS) en (dierfarm/dier/beweging).
Dizze ynformaasje wurdt trochjûn oan de makelder, dy't it tydlik opslaan kin yn in lokale databank foar it gefal dat in oare ynteressearre abonnee letter komt.
Neist de lokale server, dy't as MQTT-broker yn 'e mist fungearret en dêr't Raspberry Pis, as MQTT-kliïnten, sensorgegevens stjoert, kin der in oare MQTT-broker wêze op it wolknivo. Yn dit gefal kin de ynformaasje oerbrocht nei de lokale broker tydlik opslein wurde yn in lokale databank en / of stjoerd nei de wolk. De mist MQTT-broker yn dizze situaasje wurdt brûkt om alle gegevens te assosjearjen mei de wolk MQTT-broker. Mei dizze arsjitektuer kin in brûker fan mobile applikaasje wurde ynskreaun by beide makelders.
As de ferbining mei ien fan 'e brokers (bygelyks wolk) mislearret, sil de ein brûker ynformaasje krije fan 'e oare (mist). Dit is in karakteristyk skaaimerk fan kombinearre mist en wolk computing systemen. Standert kin de mobile app ynsteld wurde om earst te ferbinen mei de mist MQTT-broker, en as dat net slagget, te ferbinen mei de wolk MQTT-broker. Dizze oplossing is mar ien fan in protte yn IoT-F2C-systemen.
Multi-protokol oplossings
Oplossingen foar ien protokol binne populêr fanwege har makliker ymplemintaasje. Mar it is dúdlik dat yn IoT-F2C-systemen it sin makket om ferskate protokollen te kombinearjen. It idee is dat ferskate protokollen op ferskate nivo's kinne operearje. Nim bygelyks trije abstraksjes: de lagen fan IoT, mist en cloud computing. Apparaten op it IoT-nivo wurde algemien as beheind beskôge. Litte wy foar dit oersjoch IoT-tiers beskôgje as de meast beheinde, wolk de minste beheinde, en mistberekkening as "ergens yn 'e midden." It docht bliken dat tusken IoT en mistabstraksjes hjoeddeistige protokoloplossingen MQTT, CoAP en XMPP omfetsje. Tusken mist en wolk, oan 'e oare kant, is AMQP ien fan' e wichtichste protokollen dy't brûkt wurde, tegearre mei REST HTTP, dy't troch syn fleksibiliteit ek brûkt wurdt tusken IoT en mistlagen.
It wichtichste probleem hjir is de ynteroperabiliteit fan protokollen en it gemak fan it oerdragen fan berjochten fan it iene protokol nei it oare. Ideaal, yn 'e takomst sil de arsjitektuer fan in Internet of Things-systeem mei wolk- en mistboarnen ûnôfhinklik wêze fan it brûkte kommunikaasjeprotokol en soarget foar goede ynteroperabiliteit tusken ferskate protokollen.
Om't dit op it stuit net it gefal is, makket it sin om protokollen te kombinearjen dy't gjin signifikante ferskillen hawwe. Dêrta is ien potinsjele oplossing basearre op in kombinaasje fan twa protokollen dy't deselde arsjitektoanyske styl folgje, REST HTTP en CoAP. In oare foarstelde oplossing is basearre op in kombinaasje fan twa protokollen dy't publisearje-abonnearje kommunikaasje biede, MQTT en AMQP. It brûken fan ferlykbere konsepten (sawol MQTT as AMQP brûke brokers, CoAP en HTTP brûke REST) makket dizze kombinaasjes makliker te ymplementearjen en fereasket minder yntegraasje-ynspanning.
Figuer (a) toant twa modellen basearre op fersyk-antwurd, HTTP en CoAP, en har mooglike pleatsing yn in IoT-F2C-oplossing. Sûnt HTTP is ien fan 'e meast bekende en oannommen protokollen op moderne netwurken, it is net wierskynlik dat it sil wurde folslein ferfongen troch oare messaging protokollen. Under de knopen dy't machtige apparaten fertsjintwurdigje dy't tusken de wolk en de mist sitte, is REST HTTP in tûke oplossing.
Oan 'e oare kant, foar apparaten mei beheinde komputerboarnen dy't kommunisearje tusken de mist- en IoT-lagen, is it effisjinter om CoAP te brûken. Ien fan 'e grutte foardielen fan CoAP is eins syn kompatibiliteit mei HTTP, om't beide protokollen basearre binne op REST-prinsipes.
Figure (b) lit twa publisearje-abonnearje kommunikaasje modellen yn itselde senario, ynklusyf MQTT en AMQP. Hoewol beide protokollen hypotetysk kinne wurde brûkt foar kommunikaasje tusken knopen by elke abstraksjelaach, moat har posysje bepaald wurde op basis fan prestaasjes. MQTT is ûntworpen as in lichtgewicht protokol foar apparaten mei beheinde komputerboarnen, sadat it kin wurde brûkt foar IoT-Fog-kommunikaasje. AMQP is mear geskikt foar machtiger apparaten, dy't it ideaal soene pleatse tusken mist- en wolkknooppunten. Ynstee fan MQTT kin it XMPP-protokol brûkt wurde yn IoT, om't it as lichtgewicht wurdt beskôge. Mar it wurdt net sa breed brûkt yn sokke senario's.
befinings
It is net wierskynlik dat ien fan 'e besprutsen protokollen genôch sil wêze om alle kommunikaasje yn in systeem te dekken, fan apparaten mei beheinde komputerboarnen oant wolkservers. De stúdzje fûn dat de twa meast tasizzende opsjes dy't ûntwikkelders it meast brûke binne MQTT en RESTful HTTP. Dizze twa protokollen binne net allinich de meast folwoeksen en stabile, mar omfetsje ek in protte goed dokuminteare en suksesfolle ymplemintaasjes en online boarnen.
Troch syn stabiliteit en ienfâldige konfiguraasje is MQTT in protokol dat syn superieure prestaasjes yn 'e rin fan' e tiid bewiisd hat as brûkt op it IoT-nivo mei beheinde apparaten. Yn dielen fan it systeem wêr't beheinde kommunikaasje en batterijferbrûk gjin probleem binne, lykas guon mistdomeinen en de measte cloud computing, is RESTful HTTP in maklike kar. CoAP moat ek rekken holden wurde, om't it ek rap ûntwikkelet as in IoT-berjochtenstandert en it is wierskynlik dat it yn 'e heine takomst in nivo fan stabiliteit en folwoeksenens sil berikke lykas MQTT en HTTP. Mar de standert is op it stuit yn ûntwikkeling, dy't komt mei kompatibiliteitsproblemen op koarte termyn.
Wat kinne jo mear lêze op it blog?
→
→
→
→
→
Ynskriuwe op ús -kanaal, om it folgjende artikel net te missen! Wy skriuwe net mear as twa kear yn 'e wike en allinnich op saaklik.
Boarne: www.habr.com