Die ontwikkeling van tegnologie op die gebied van sagteware en hardeware, die opkoms van nuwe kommunikasieprotokolle het gelei tot die uitbreiding van die Internet van dinge (IoT). Die aantal toestelle groei dag vir dag, en hulle genereer 'n groot hoeveelheid data. Daarom is daar 'n behoefte aan 'n gerieflike stelselargitektuur wat hierdie data kan verwerk, stoor en oordra.
Deesdae word wolkdienste vir hierdie doeleindes gebruik. Die toenemend gewilde misrekenaarparadigma (Fog) is egter in staat om wolkoplossings aan te vul deur die IoT-infrastruktuur te skaal en te optimaliseer.
Wolke is in staat om die meeste IoT-versoeke te sluit. Byvoorbeeld, om monitering van dienste te verskaf, vinnige verwerking van enige hoeveelheid data wat deur toestelle gegenereer word, sowel as hul visualisering. Misberekening is meer doeltreffend om intydse probleme op te los. Hulle gee vinnige reaksie op versoeke en minimale vertraging in dataverwerking. Dit wil sê, Fog komplementeer die "wolke", brei sy vermoëns uit.
Die hoofvraag is egter anders: hoe moet dit alles in die konteks van IoT optree? Watter kommunikasieprotokolle sal die doeltreffendste wees wanneer jy in 'n verenigde IoT-Fog-Cloud-stelsel werk?
Ten spyte van die skynbare oorheersing van HTTP, word 'n groot aantal ander oplossings in IoT-, Mis- en Wolkstelsels gebruik. Dit is omdat IoT die funksionaliteit van 'n verskeidenheid toestelsensors moet kombineer met sekuriteit, interoperabiliteit en ander gebruikersvereistes.
Maar daar is eenvoudig geen enkele idee van die verwysingsargitektuur en kommunikasiestandaard nie. Daarom is die skep van 'n nuwe protokol of die wysiging van 'n bestaande een vir spesifieke IoT-take een van die belangrikste take wat die IT-gemeenskap in die gesig staar.
Watter protokolle word tans gebruik en wat kan dit bied? Kom ons vind dit uit. Maar eers, kom ons bespreek die beginsels van 'n ekosisteem waarin wolke, mis en die internet van dinge in wisselwerking is.
IoT Mis-tot-wolk (F2C) argitektuur
Jy het waarskynlik opgemerk hoeveel moeite gedoen word om die voordele en voordele verbonde aan die rasionele en gekoördineerde bestuur van IoT, wolke en mis te ondersoek. Indien nie, hier is drie standaardiseringsinisiatiewe: , и .
As vroeër slegs 2 vlakke oorweeg is, wolke en eindtoestelle, dan stel die voorgestelde argitektuur 'n nuwe vlak bekend - misrekenaarkunde. Terselfdertyd kan die misvlak in verskeie subvlakke verdeel word, afhangende van die besonderhede van hulpbronne of 'n stel beleide wat die gebruik van verskillende toestelle in hierdie subvlakke bepaal.
Hoe kan hierdie abstraksie lyk? Hier is 'n tipiese IoT-Fog-Cloud-ekosisteem. IoT-toestelle stuur data na vinniger bedieners en rekenaartoestelle om take op te los wat lae latensie vereis. In dieselfde stelsel is wolke verantwoordelik vir die oplossing van probleme wat 'n groot hoeveelheid rekenaarhulpbronne of stoorspasie vereis.
Slimfone, slimhorlosies en ander gadgets kan ook deel van die IoT wees. Maar sulke toestelle is geneig om eie kommunikasieprotokolle van groot ontwikkelaars te gebruik. Die gegenereerde IoT-data word deur die REST HTTP-protokol na die mislaag oorgedra, wat buigsaamheid en interoperabiliteit bied wanneer RESTful-dienste gebou word. Dit is belangrik in die lig van die behoefte om terugwaartse versoenbaarheid te verseker met bestaande rekenaarinfrastruktuur wat op plaaslike rekenaars, bedieners of 'n bedienerkluster loop. Plaaslike hulpbronne, wat "misnodes" genoem word, filtreer die ontvangde data en verwerk dit plaaslik of stuur dit na die wolk vir verdere berekeninge.
Wolke ondersteun verskillende kommunikasieprotokolle, waaronder AMQP en REST HTTP die algemeenste is. Aangesien HTTP bekend en verskerp is vir die internet, kan die vraag ontstaan: "moet dit nie gebruik word om met IoT en mis te werk nie?". Hierdie protokol het egter prestasieprobleme. Meer daaroor later.
Oor die algemeen is daar 2 modelle van kommunikasieprotokolle wat geskik is vir die stelsel wat ons benodig. Dit is versoek-reaksie en publiseer-teken in. Die eerste model is meer algemeen bekend, veral in die bediener-kliënt-argitektuur. Die kliënt versoek inligting vanaf die bediener, en laasgenoemde ontvang die versoek, verwerk dit en stuur 'n antwoordboodskap terug. REST HTTP- en CoAP-protokolle werk volgens hierdie model.
Die tweede model het ontstaan uit die behoefte om 'n asynchrone, verspreide, los koppeling te verskaf tussen die bronne wat data genereer en die ontvangers van hierdie data.
Die model veronderstel drie deelnemers: 'n uitgewer (databron), 'n makelaar (versender) en 'n intekenaar (ontvanger). Hier hoef die kliënt wat as die intekenaar optree nie inligting van die bediener af aan te vra nie. In plaas daarvan om versoeke te stuur, teken dit in op sekere gebeurtenisse in die stelsel deur 'n makelaar wat verantwoordelik is vir die filter van alle inkomende boodskappe en om dit tussen uitgewers en intekenare te stuur. En die uitgewer, wanneer 'n gebeurtenis plaasvind wat verband hou met 'n sekere onderwerp, publiseer dit aan die makelaar, wat data aan die intekenaar stuur oor die gevraagde onderwerp.
In wese is hierdie argitektuur gebaseer op gebeure. En hierdie interaksiemodel is interessant vir toepassings in IoT, wolk, mis as gevolg van sy vermoë om skaalbaarheid te verskaf en die interkonneksie tussen verskillende toestelle te vereenvoudig, baie-tot-baie dinamiese kommunikasie en asinchrone kommunikasie te ondersteun. Sommige van die bekendste gestandaardiseerde publiseer-inteken boodskap protokolle sluit in MQTT, AMQP en DDS.
Uiteraard het die publiseer-inteken-model baie voordele:
- Uitgewers en intekenare hoef nie van mekaar se bestaan te weet nie;
- Een intekenaar kan inligting van baie verskillende publikasies ontvang, en een uitgewer kan data aan baie verskillende intekenare stuur (baie-tot-baie-beginsel);
- Die uitgewer en intekenaar hoef nie terselfdertyd aktief te wees om data uit te ruil nie, want die makelaar (wat as 'n toustelsel optree) sal die boodskap kan stoor vir kliënte wat nie tans aan die netwerk gekoppel is nie.
Die versoek-reaksie-model het egter ook sy sterk punte. In gevalle waar die vermoë van die bedienerkant om versoeke van verskeie kliënte te verwerk nie 'n probleem is nie, maak dit sin om reeds bewese betroubare oplossings te gebruik.
Daar is ook protokolle wat beide modelle ondersteun. Byvoorbeeld, XMPP en HTTP 2.0 wat die "bedienerstoot"-opsie ondersteun. Die IETF het ook die CoAP vrygestel. Verskeie ander oplossings is geskep in 'n poging om die boodskapprobleem op te los, soos die WebSockets-protokol of die gebruik van die HTTP-protokol oor QUIC (Quick UDP Internet Connections).
In die geval van WebSockets, hoewel dit gebruik word om data in reële tyd van die bediener na die webkliënt oor te dra en volgehoue verbindings met gelyktydige tweerigtingkommunikasie bied, is dit nie bedoel vir toestelle met beperkte rekenaarhulpbronne nie. QUIC verdien ook aandag, aangesien die nuwe vervoerprotokol baie nuwe funksies bied. Maar aangesien QUIC nog nie gestandaardiseer is nie, is dit voortydig om die moontlike toepassing en impak daarvan op IoT-oplossings te voorspel. Dus laat ons WebSockets en QUIC in die geheue met die oog op die toekoms, maar ons sal nog nie in meer besonderhede bestudeer nie.
Wie is die oulikste in die wêreld: vergelyk protokolle
Kom ons praat nou oor die sterk- en swakpunte van protokolle. As ons vorentoe kyk, sal ons dadelik 'n voorbehoud maak dat daar nie een duidelike leier is nie. Elke protokol het 'n paar voordele/nadele.
Reaksie tyd
Een van die belangrikste kenmerke van kommunikasieprotokolle, veral met betrekking tot die internet van dinge, is die reaksietyd. Maar onder die bestaande protokolle is daar geen duidelike wenner wat die minimum vlak van vertraging demonstreer wanneer daar in verskillende toestande gewerk word nie. Maar daar is 'n hele klomp studies en vergelykings van protokolvermoëns.
Byvoorbeeld, vergelykings van die doeltreffendheid van HTTP en MQTT wanneer daar met IoT gewerk word, het getoon dat die reaksietyd vir versoeke vir MQTT minder is as vir HTTP. En wanneer retoertyd (RTT) van MQTT en CoAP, het dit geblyk dat die gemiddelde RTT van CoAP 20% minder is as dié van MQTT.
Ander met RTT vir die MQTT- en CoAP-protokolle is in twee scenario's uitgevoer: 'n plaaslike netwerk en 'n IoT-netwerk. Dit het geblyk dat die gemiddelde RTT 2-3 keer hoër is in die IoT-netwerk. MQTT met QoS0 het 'n laer resultaat getoon in vergelyking met CoAP, en MQTT met QoS1 het 'n hoër RTT getoon danksy ACK's by die toedienings- en vervoerlae. Vir verskillende QoS-vlakke was netwerkvertragings sonder opeenhoping millisekondes vir MQTT, en honderde mikrosekondes vir CoAP. Dit is egter die moeite werd om te onthou dat wanneer u in minder betroubare netwerke werk, MQTT wat oor TCP loop, 'n heeltemal ander resultaat sal toon.
die reaksietyd van die AMQP- en MQTT-protokolle deur die loonvrag te verhoog, het getoon dat met 'n klein vrag, die vertragingsvlak amper dieselfde is. Maar wanneer groot hoeveelhede data oorgedra word, toon MQTT 'n laer reaksietyd. in nog een CoAP is met HTTP vergelyk in 'n masjien-tot-masjien-scenario met toestelle wat bo-op voertuie ontplooi is wat toegerus is met gassensors, weersensors, ligging (GPS) en mobiele netwerkkoppelvlak (GPRS). Die tyd wat dit geneem het om 'n CoAP-boodskap oor die mobiele netwerk te stuur, was byna drie keer korter as die tyd wat dit geneem het om HTTP-boodskappe te gebruik.
Studies is uitgevoer wat nie twee nie, maar drie protokolle vergelyk het. Byvoorbeeld, prestasie van IoT-protokolle MQTT, DDS en CoAP in 'n mediese toepassingscenario met behulp van 'n netwerkemulator. DDS het beter as MQTT gevaar in terme van telemetrie-latency wat onder verskeie swak netwerktoestande getoets is. UDP-gebaseerde CoAP het goed gewerk vir toepassings wat vinnige reaksie nodig gehad het, maar omdat dit UDP-gebaseer was, was daar aansienlike onvoorspelbare pakkieverlies.
deurset
MQTT en CoAP in terme van bandwydte doeltreffendheid is uitgevoer as 'n berekening van die totale hoeveelheid data wat per boodskap versend is. CoAP het minder deurset as MQTT vir klein boodskappe getoon. Maar wanneer die doeltreffendheid van protokolle vergelyk word in terme van die verhouding van die aantal nuttige inligtinggrepe tot die totale aantal versendte grepe, het CoAP meer effektief geblyk te wees.
op deurset met behulp van MQTT, DDS (met TCP as die vervoerprotokol), en CoAP het bevind dat CoAP geneig was om relatief laer bandwydteverbruik te toon, wat nie toegeneem het met verhoogde netwerkpakketverlies of verhoogde netwerkvertraging nie, anders as MQTT en DDS, waar in die genoemde scenario's was daar 'n toename in bandwydtegebruik. 'n Ander scenario het behels dat 'n groot aantal toestelle data op dieselfde tyd versend, wat 'n tipiese geval in IoT-omgewings is. Die resultate het getoon dat dit beter is om CoAP te gebruik vir hoër laai.
Onder ligte las het CoAP die minste bandwydte gebruik, gevolg deur MQTT en REST HTTP. Soos die grootte van die loonvragte egter toegeneem het, het REST HTTP die beste resultate gehad.
Kragverbruik
Die kwessie van energieverbruik is altyd van groot belang, en veral in die IoT-stelsel. As kragverbruik van MQTT en HTTP, HTTP "eet" baie meer. En CoAP is meer in vergelyking met MQTT, wat kragbestuur moontlik maak. Terselfdertyd, in eenvoudige scenario's, is MQTT meer geskik vir inligtinguitruiling in Internet of Things-netwerke, veral as daar geen kragbeperkings is nie.
'n Eksperiment wat AMQP- en MQTT-vermoëns op 'n mobiele of onstabiele draadlose netwerk-toetsbank vergelyk het, het getoon dat AMQP meer sekuriteitskenmerke bied, terwyl MQTT meer energiedoeltreffend is.
sekuriteit
Sekuriteit is nog 'n groot kwessie wat geopper word in die studie van die Internet van Dinge en mis-/wolkrekenaars. Die sekuriteitsmeganisme is tipies gebaseer op TLS in HTTP, MQTT, AMQP en XMPP, of DTLS in CoAP, en ondersteun beide DDS-opsies.
TLS en DTLS begin met die proses om 'n verbinding tussen die kliënt- en bedienerkant te vestig om ondersteunde syferreekse en sleutels uit te ruil. Beide partye onderhandel stelle om te verseker dat verdere kommunikasie in 'n veilige kanaal plaasvind. Die verskil tussen die twee is 'n effense wysiging wat UDP-gebaseerde DTLS toelaat om oor 'n onbetroubare verbinding te werk.
op op verskeie verskillende implementerings van TLS en DTLS, het dit geblyk dat TLS 'n beter werk gedoen het. Aanvalle op DTLS was meer suksesvol as gevolg van sy foutverdraagsaamheid.
Die grootste probleem met hierdie protokolle is egter dat hulle nie oorspronklik ontwerp is vir gebruik in IoT nie en nie veronderstel was om in mis of wolk te werk nie. Deur handskud voeg hulle bykomende verkeer by met elke verbindingsvestiging, wat rekenaarhulpbronne dreineer. Daar is gemiddeld 'n toename van 6,5% vir TLS en 11% vir DTLS in bokoste in vergelyking met kommunikasie sonder 'n sekuriteitslaag. In hulpbronryke omgewings wat tipies op geleë is vlak, sal dit nie 'n probleem wees nie, maar as gevolg van die verhouding tussen IoT en misvlak, word dit 'n belangrike beperking.
Wat om te kies? Daar is geen enkele antwoord nie. MQTT en HTTP blyk die mees belowende protokolle te wees, aangesien hulle as relatief meer volwasse en meer stabiele IoT-oplossings as ander protokolle beskou word.
Oplossings gebaseer op 'n enkele kommunikasieprotokol
Die praktyk van 'n enkele protokol oplossing het baie nadele. Byvoorbeeld, 'n protokol wat by 'n beperkte omgewing pas, werk dalk nie in 'n domein wat streng sekuriteitsvereistes het nie. Met dit in gedagte, word ons oorgelaat om byna alle moontlike enkelprotokol-oplossings in die Fog-to-Cloud-ekosisteem in IoT weg te gooi, behalwe vir MQTT en REST HTTP.
RUS HTTP as 'n enkelprotokoloplossing
Daar is 'n goeie voorbeeld van REST HTTP-versoek/reaksie-interaksie in die IoT-tot-Fog-ryk: . Diere word toegerus met draagbare sensors (IoT-kliënt, C) en word via wolkrekenaars bestuur deur 'n slim boerderystelsel (Fog-bediener, S).
Die POST-metode-opskrif spesifiseer die hulpbron om te wysig (/plaas/diere), sowel as die HTTP-weergawe en inhoudtipe, wat in hierdie geval 'n JSON-objek is wat die diereplaas verteenwoordig wat die stelsel moet bestuur (Dulcinea/Koei). Die antwoord van die bediener dui aan dat die versoek suksesvol was met 'n HTTPS 201 (hulpbron geskep) statuskode. Die AOO-metode moet slegs die aangevraagde hulpbron in die URI spesifiseer (byvoorbeeld /plaas/diere/1), wat 'n JSON-voorstelling van die dier met daardie ID vanaf die bediener terugstuur.
Die PUT-metode word gebruik wanneer een of ander spesifieke hulpbronrekord bygewerk moet word. In hierdie geval spesifiseer die hulpbron die URI vir die parameter wat verander moet word en die huidige waarde (wat byvoorbeeld aandui dat die koei tans loop, /plaas/diere/1? toestand=loop). Laastens word die DELETE-metode op dieselfde manier as die GET-metode gebruik, maar vee bloot die hulpbron uit as gevolg van die operasie.
MQTT as 'n enkele protokol oplossing
Kom ons neem dieselfde slim plaas, maar in plaas van REST HTTP gebruik ons die MQTT-protokol. Die plaaslike bediener met die Mosquitto-biblioteek geïnstalleer dien as 'n makelaar. In hierdie voorbeeld dien 'n eenvoudige rekenaar (na verwys as die plaasbediener) Raspberry Pi as 'n MQTT-kliënt, geïmplementeer deur die installering van die Paho MQTT-biblioteek, wat ten volle versoenbaar is met die Mosquitto-makelaar.
Hierdie kliënt voldoen aan die IoT-abstraksielaag wat 'n toestel met ontdekkings- en rekenaarvermoëns verteenwoordig. Die bemiddelaar, aan die ander kant, stem ooreen met 'n hoër vlak van abstraksie, wat 'n mistrekenaarnodus verteenwoordig, gekenmerk deur groot verwerkings- en bergingskapasiteite.
In die voorgestelde slimplaas-scenario koppel 'n Raspberry Pi aan 'n versnellingsmeter, GPS en temperatuursensors en publiseer die data van daardie sensors na 'n misnodus. Soos u waarskynlik weet, behandel MQTT onderwerpe as 'n hiërargie. Een MQTT-uitgewer kan boodskappe na 'n spesifieke stel onderwerpe publiseer. In ons geval is daar drie. Vir die sensor wat die temperatuur in die veehok meet, kies die kliënt 'n tema (diereplaas/skuur/temperatuur). Vir sensors wat GPS-ligging en dierebeweging deur die versnellingsmeter meet, sal die kliënt opdaterings publiseer na (dierplaas/dier/GPS) en (dierplaas/dier/beweging).
Hierdie inligting sal met die makelaar gedeel word, wat dit tydelik in 'n plaaslike databasis kan stoor ingeval 'n ander belangstellende intekenaar later opdaag.
Benewens die plaaslike bediener wat as 'n MQTT-makelaar in die mis optree en waarheen die Raspberry Pi, wat as MQTT-kliënte optree, data vanaf sensors stuur, kan daar nog 'n MQTT-makelaar op wolkvlak wees. In hierdie geval kan die inligting wat aan die plaaslike makelaar oorgedra word, tydelik in 'n plaaslike databasis gestoor word en/of na die wolk gestuur word. Die wolk MQTT makelaar in hierdie situasie word gebruik om alle data aan die wolk MQTT makelaar te koppel. Met hierdie argitektuur kan 'n mobiele toepassinggebruiker by beide makelaars ingeteken word.
In die geval van 'n verbindingsfout met een van die makelaars (byvoorbeeld wolk), sal die eindgebruiker inligting van 'n ander ontvang (mistig). Dit is 'n kenmerkende kenmerk van gekombineerde mis- en wolkrekenaarstelsels. By verstek kan die mobiele toepassing gekonfigureer word om eers aan die mistige MQTT-makelaar te koppel, en by gebrek daaraan, om aan die wolk MQTT-makelaar te koppel. Hierdie oplossing is net een van vele in IoT-F2C-stelsels.
Multiprotokol oplossings
Enkelprotokoloplossings is gewild vanweë hul makliker implementering. Maar dit is duidelik dat dit in IoT-F2C-stelsels sin maak om verskillende protokolle te kombineer. Die punt is dat verskillende protokolle op verskillende vlakke kan werk. Neem byvoorbeeld drie abstraksies: IoT, mis en wolkrekenaarlae. Toestelle op die IoT-vlak word oor die algemeen as beperk beskou. Vir hierdie oorsig, kom ons kyk na IoT-lae as die mees beperkende, wolkgebaseerde minste beperkende, en mistrekenaars as "iewers tussenin". Dan blyk dit dat huidige protokoloplossings tussen IoT en mis-abstraksies MQTT, CoAP en XMPP insluit. Tussen mis en wolk, aan die ander kant, is AMQP een van die hoofprotokolle wat saam met REST HTTP gebruik word, wat as gevolg van sy buigsaamheid ook tussen IoT en mislae gebruik word.
Die hoofprobleem hier is die interoperabiliteit van protokolle en die gemak om boodskappe van een protokol na 'n ander oor te dra. Ideaal gesproke, in die toekoms, sal die argitektuur van die IoT-stelsel met wolk- en misbronne onafhanklik wees van die kommunikasieprotokol wat gebruik word en sal goeie interoperabiliteit van verskillende protokolle verseker.
Aangesien dit nie op die oomblik die geval is nie, maak dit sin om protokolle saam te voeg wat nie beduidende verskille het nie. Vir hierdie doel is een potensiële oplossing gebaseer op 'n kombinasie van twee protokolle wat dieselfde argitektoniese styl volg, REST HTTP en CoAP. Nog 'n voorgestelde oplossing is gebaseer op 'n kombinasie van twee protokolle wat publiseer-inteken interaksie bied, MQTT en AMQP. Die gebruik van soortgelyke konsepte (beide MQTT en AMQP gebruik makelaars, CoAP en HTTP gebruik REST) maak hierdie kombinasies makliker om te implementeer en verg minder integrasiepoging.
Figuur (a) toon twee versoek-reaksie-modelle, HTTP en CoAP, en hul moontlike plasing in 'n IoT-F2C-oplossing. Aangesien HTTP een van die mees bekende en aanvaarde protokolle in vandag se netwerke is, is dit onwaarskynlik dat dit heeltemal deur ander boodskapprotokolle vervang sal word. Onder die nodusse wat kragtige toestelle verteenwoordig wat tussen wolk en mis is, is REST HTTP 'n redelike oplossing.
Aan die ander kant, vir rekenaarbeperkte toestelle wat tussen mis en IoT-lae kommunikeer, is dit meer doeltreffend om CoAP te gebruik. Een van die groot voordele van CoAP is eintlik die versoenbaarheid daarvan met HTTP, aangesien beide protokolle op REST-beginsels gebaseer is.
Figuur (b) toon twee publiseer-inteken-interaksiemodelle in dieselfde scenario, insluitend MQTT en AMQP. Alhoewel hipoteties beide protokolle gebruik kan word om tussen nodusse op elke vlak van abstraksie te kommunikeer, moet hul posisie op grond van prestasie bepaal word. MQTT is ontwerp as 'n liggewigprotokol vir toestelle met beperkte rekenaarhulpbronne, sodat dit gebruik kan word om tussen IoT en mis te kommunikeer. AMQP is meer geskik vir kragtiger toestelle wat dit ideaal tussen mis en wolknodes sal plaas. In plaas van MQTT in IoT, kan jy die XMPP-protokol gebruik, aangesien dit as liggewig beskou word. Maar dit word nie algemeen in sulke scenario's gebruik nie.
Bevindinge
Dit is onwaarskynlik dat een van die oorweegde protokolle voldoende sal wees om alle kommunikasie in die stelsel te dek, van toestelle met beperkte rekenaarhulpbronne tot wolkbedieners. Die studie het getoon dat die twee mees belowende opsies wat ontwikkelaars meer gereeld gebruik, MQTT en RESTful HTTP is. Hierdie twee protokolle is nie net die mees volwasse en stabiele nie, maar sluit ook baie goed gedokumenteerde en suksesvolle implementerings en aanlynhulpbronne in.
As gevolg van sy stabiliteit en eenvoudige konfigurasie, is MQTT 'n protokol wat sy voortreflike werkverrigting oor tyd bewys het wanneer dit by die IoT-laag gebruik word met beperkte toestelle. In dele van die stelsel waar beperkte konnektiwiteit en batteryverbruik nie 'n probleem is nie, soos sommige gebiede van mis en die meeste wolkrekenaars, is RESTful HTTP 'n maklike keuse. CoAP moet ook in ag geneem word aangesien dit ook vinnig ontwikkel as 'n IoT-boodskapstandaard en dit is waarskynlik dat dit 'n vlak van stabiliteit en volwassenheid soortgelyk aan MQTT en HTTP in die nabye toekoms sal bereik. Maar die standaard is nou besig om te ontwikkel, wat gepaard gaan met korttermyn-versoenbaarheidskwessies.
Wat kan jy nog op die blog lees?
→
→
→
→
→
Teken in op ons -kanaal, om nie die volgende artikel te mis nie! Ons skryf nie meer as twee keer per week nie en slegs vir besigheid.
Bron: will.com