Þróun tækni á sviði hugbúnaðar og vélbúnaðar, tilkoma nýrra samskiptareglur hafa leitt til stækkunar Internet of Things (IoT). Fjöldi tækja eykst dag frá degi og þau búa til mikið magn af gögnum. Þess vegna er þörf fyrir þægilegan kerfisarkitektúr sem getur unnið, geymt og sent þessi gögn.
Nú er skýjaþjónusta notuð í þessum tilgangi. Hins vegar getur sífellt vinsælli þokutölvufyrirmynd (Fog) bætt við skýjalausnir með því að stækka og hagræða IoT innviði.
Ský eru fær um að ná yfir flestar IoT beiðnir. Til dæmis, til að veita eftirlit með þjónustu, hraðvinnslu á hvers kyns gagnamagni sem myndast af tækjum, sem og sjónræningu þeirra. Þokutölvur eru skilvirkari þegar leyst er vandamál í rauntíma. Þeir veita skjót viðbrögð við beiðnum og lágmarks leynd í gagnavinnslu. Það er, Fog bætir við „skýin“ og stækkar getu sína.
Hins vegar er aðalspurningin önnur: hvernig ætti allt þetta að hafa samskipti í samhengi við IoT? Hvaða samskiptareglur munu skila mestum árangri þegar unnið er í samsettu IoT-Fog-Cloud kerfi?
Þrátt fyrir augljósa yfirburði HTTP er mikill fjöldi annarra lausna notaðar í IoT, Fog og Cloud kerfi. Þetta er vegna þess að IoT verður að sameina virkni margs konar skynjara tækja við öryggi, eindrægni og aðrar kröfur notenda.
En það er einfaldlega engin ein hugmynd um viðmiðunararkitektúr og samskiptastaðal. Þess vegna er það eitt mikilvægasta verkefnið sem upplýsingatæknisamfélagið stendur frammi fyrir að búa til nýja samskiptareglu eða breyta núverandi fyrir tiltekin IoT verkefni.
Hvaða samskiptareglur eru í notkun og hvað geta þær boðið upp á? Við skulum reikna það út. En fyrst skulum við ræða meginreglur vistkerfisins þar sem ský, þoka og internet hlutanna hafa samskipti.
IoT Fog-to-Cloud (F2C) arkitektúr
Þú hefur sennilega tekið eftir því hversu mikið átak er lagt í að kanna kosti og kosti sem fylgja snjallri og samræmdri stjórnun á IoT, skýi og þoku. Ef ekki, þá eru hér þrjú stöðlunarverkefni: , и .
Ef áður var aðeins litið á 2 stig, ský og endatæki, þá kynnir fyrirhuguð arkitektúr nýtt stig - þokutölvu. Í þessu tilviki er hægt að skipta þokustiginu í nokkur undirstig, allt eftir sérkennum auðlinda eða reglum sem ákvarða notkun mismunandi tækja í þessum undirstigum.
Hvernig gæti þessi útdráttur litið út? Hér er dæmigert IoT-Fog-Cloud vistkerfi. IoT tæki senda gögn til hraðari netþjóna og tölvutækja til að leysa vandamál sem krefjast lítillar leynd. Í sama kerfi eru ský ábyrg fyrir því að leysa vandamál sem krefjast mikið magn af tölvuauðlindum eða gagnageymsluplássi.
Snjallsímar, snjallúr og aðrar græjur geta líka verið hluti af IoT. En slík tæki nota að jafnaði sérsamskiptareglur frá stórum hönnuðum. Mynduð IoT gögn eru flutt yfir í þokulagið í gegnum REST HTTP samskiptareglur, sem veitir sveigjanleika og samvirkni þegar búið er til RESTful þjónustu. Þetta er mikilvægt í ljósi þess að tryggja þarf afturábak eindrægni við núverandi tölvuinnviði sem keyra á staðbundnum tölvum, netþjónum eða netþjónaklasa. Staðbundin tilföng, sem kallast „þokuhnútar“, sía móttekin gögn og vinna úr þeim á staðnum eða senda þau í skýið til frekari útreikninga.
Ský styðja mismunandi samskiptareglur, þær algengustu eru AMQP og REST HTTP. Þar sem HTTP er vel þekkt og sniðið fyrir internetið, gæti spurningin vaknað: „Eigum við ekki að nota það til að vinna með IoT og þoku? Hins vegar hefur þessi siðareglur frammistöðuvandamál. Meira um þetta síðar.
Almennt séð eru 2 gerðir af samskiptareglum sem henta kerfinu sem við þurfum. Þetta eru beiðni-svar og birta-áskrift. Fyrsta líkanið er þekktara, sérstaklega í arkitektúr miðlara og viðskiptavina. Viðskiptavinurinn biður um upplýsingar frá þjóninum og þjónninn tekur við beiðninni, vinnur úr henni og skilar svarskilaboðum. REST HTTP og CoAP samskiptareglur starfa á þessu líkani.
Annað líkanið spratt af þörfinni á að veita ósamstillta, dreifða, lausa tengingu milli heimildanna sem búa til gögn og viðtakenda þessara gagna.
Líkanið gerir ráð fyrir þremur þátttakendum: útgefanda (gagnagjafa), miðlara (sendi) og áskrifanda (móttakara). Hér þarf viðskiptavinurinn sem starfar sem áskrifandi ekki að biðja um upplýsingar frá þjóninum. Í stað þess að senda beiðnir gerist það áskrifandi að ákveðnum atburðum í kerfinu í gegnum miðlara sem sér um að sía öll skilaboð sem berast og beina þeim á milli útgefenda og áskrifenda. Og útgefandinn, þegar atburður á sér stað varðandi ákveðið efni, birtir það til miðlara, sem sendir gögn um umbeðið efni til áskrifanda.
Í meginatriðum er þessi arkitektúr byggður á atburðum. Og þetta samskiptalíkan er áhugavert fyrir forrit í IoT, skýi, þoku vegna getu þess til að veita sveigjanleika og einfalda samtengingu milli mismunandi tækja, styðja kraftmikil mörg-til-marga samskipti og ósamstillt samskipti. Sumar af þekktustu stöðluðu skilaboðasamskiptareglunum sem nota útgáfu-áskriftarlíkan eru MQTT, AMQP og DDS.
Augljóslega hefur útgáfu-áskriftarlíkanið marga kosti:
- Útgefendur og áskrifendur þurfa ekki að vita um tilvist hvors annars;
- Einn áskrifandi getur fengið upplýsingar frá mörgum mismunandi útgáfum og einn útgefandi getur sent gögn til margra mismunandi áskrifenda (margir-til-margir meginreglan);
- Útgefandi og áskrifandi þurfa ekki að vera virkir á sama tíma til að eiga samskipti, vegna þess að miðlarinn (sem vinnur sem biðraðir) mun geta geymt skilaboðin fyrir viðskiptavini sem eru ekki tengdir við netið.
Hins vegar hefur beiðni-svar líkanið líka sína styrkleika. Í þeim tilvikum þar sem getu netþjónsins til að meðhöndla margar beiðnir viðskiptavina er ekki vandamál, er skynsamlegt að nota sannaðar, áreiðanlegar lausnir.
Það eru líka samskiptareglur sem styðja báðar gerðirnar. Til dæmis, XMPP og HTTP 2.0, sem styðja „þjónn push“ valkostinn. IETF hefur einnig gefið út CoAP. Til að reyna að leysa skilaboðavandann hafa nokkrar aðrar lausnir verið búnar til, svo sem WebSockets samskiptareglur eða notkun HTTP samskiptareglur yfir QUIC (Quick UDP Internet Connections).
Þegar um er að ræða WebSockets, þó að það sé notað til að flytja gögn í rauntíma frá netþjóni til vefbiðlara og veitir viðvarandi tengingar með samtímis tvíátta samskiptum, er það ekki ætlað fyrir tæki með takmarkaða tölvuauðlindir. QUIC á líka skilið athygli, þar sem nýja flutningssamskiptareglan gefur fullt af nýjum tækifærum. En þar sem QUIC er ekki enn staðlað er ótímabært að spá fyrir um mögulega beitingu þess og áhrif á IoT lausnir. Þannig að við höfum WebSockets og QUIC í huga með auga til framtíðar, en við munum ekki rannsaka það nánar í bili.
Hver er sætastur í heimi: að bera saman samskiptareglur
Nú skulum við tala um styrkleika og veikleika samskiptareglur. Þegar horft er fram á veginn skulum við strax gera fyrirvara um að það sé enginn skýr leiðtogi. Hver siðareglur hefur nokkra kosti / galla.
Svar tími
Eitt mikilvægasta einkenni samskiptareglur, sérstaklega í tengslum við Internet hlutanna, er viðbragðstími. En meðal núverandi samskiptareglna er enginn skýr sigurvegari sem sýnir lágmarks leynd þegar unnið er við mismunandi aðstæður. En það er fullt af rannsóknum og samanburði á samskiptamöguleikum.
Til dæmis, samanburður á skilvirkni HTTP og MQTT þegar unnið er með IoT sýndi að svartími fyrir beiðnir um MQTT er minni en fyrir HTTP. Og hvenær Tími fram og til baka (RTT) MQTT og CoAP leiddi í ljós að meðaltal RTT CoAP er 20% minni en MQTT.
Annað með RTT fyrir MQTT og CoAP samskiptareglur var framkvæmt í tveimur atburðarásum: staðbundið net og IoT net. Í ljós kom að meðaltal RTT er 2-3 sinnum hærra í IoT neti. MQTT með QoS0 sýndi lægri niðurstöðu samanborið við CoAP og MQTT með QoS1 sýndi hærra RTT vegna ACKs á umsóknar- og flutningslögum. Fyrir mismunandi QoS stig var netleynd án þrengsla millisekúndur fyrir MQTT og hundruð míkrósekúndna fyrir CoAP. Hins vegar er þess virði að muna að þegar unnið er á minna áreiðanlegum netum mun MQTT sem keyrir ofan á TCP sýna allt aðra niðurstöðu.
viðbragðstími fyrir AMQP og MQTT samskiptareglur með því að auka burðargetuna sýndi að með léttu álagi er leynd nánast það sama. En þegar mikið magn af gögnum er flutt sýnir MQTT styttri viðbragðstíma. í einu í viðbót CoAP var borið saman við HTTP í samskiptaatburðarás vél-til-vélar með tækjum sett ofan á farartæki með gasskynjara, veðurskynjara, staðsetningarskynjara (GPS) og farsímanetsviðmót (GPRS). Tíminn sem þurfti til að senda CoAP skilaboð um farsímakerfið var næstum þrisvar sinnum styttri en tíminn sem þarf til að nota HTTP skilaboð.
Rannsóknir hafa verið gerðar þar sem ekki voru bornar saman tvær heldur þrjár samskiptareglur. Til dæmis, frammistöðu IoT samskiptareglur MQTT, DDS og CoAP í læknisfræðilegu atburðarás með því að nota nethermi. DDS stóð sig betur en MQTT hvað varðar prófuð fjarmælingartíðni við margvíslegar slæmar netaðstæður. UDP-undirstaða CoAP virkaði vel fyrir forrit sem kröfðust skjóts viðbragðstíma, en vegna þess að það var byggt á UDP var umtalsvert ófyrirsjáanlegt pakkatap.
Afköst
MQTT og CoAP með tilliti til skilvirkni bandbreiddar voru framkvæmd sem útreikningur á heildarmagni gagna sem sent var í skilaboðum. CoAP hefur sýnt lægri afköst en MQTT við sendingu lítilla skilaboða. En þegar borin var saman skilvirkni samskiptareglna hvað varðar hlutfall fjölda gagnlegra upplýsingabæta og heildarfjölda bæta sem flutt voru, reyndist CoAP skilvirkara.
á með því að nota MQTT, DDS (með TCP sem flutningssamskiptareglur) og CoAP bandbreidd, kom í ljós að CoAP sýndi almennt tiltölulega minni bandbreiddarnotkun, sem jókst ekki með auknu netpakkatapi eða aukinni netleynd, ólíkt MQTT og DDS, þar sem aukningu á bandbreiddarnýtingu í nefndum sviðsmyndum. Önnur atburðarás fól í sér mikinn fjölda tækja sem sendu gögn samtímis, sem er dæmigert í IoT umhverfi. Niðurstöðurnar sýndu að fyrir meiri nýtingu er betra að nota CoAP.
Við létt álag notaði CoAP minnstu bandbreiddina, síðan MQTT og REST HTTP. Hins vegar, þegar stærð farmsins jókst, náði REST HTTP bestum árangri.
Orkunotkun
Orkunotkun skiptir alltaf miklu máli og sérstaklega í IoT kerfi. Ef Á meðan MQTT og HTTP neyta rafmagns eyðir HTTP miklu meira. Og CoAP er meira miðað við MQTT, sem gerir orkustjórnun kleift. Hins vegar, í einföldum tilfellum, hentar MQTT betur til að skiptast á upplýsingum í Internet of Things netkerfum, sérstaklega ef það eru engar afltakmarkanir.
Tilraun sem bar saman getu AMQP og MQTT á farsíma eða óstöðugu þráðlausu neti prófunarbeð komst að því að AMQP býður upp á meiri öryggisgetu á meðan MQTT er orkunýtnari.
öryggi
Öryggi er annað mikilvægt atriði sem vakið er yfir þegar fjallað er um efni hlutanna Internet og þoku-/skýjatölvu. Öryggiskerfið er venjulega byggt á TLS í HTTP, MQTT, AMQP og XMPP, eða DTLS í CoAP, og styður bæði DDS afbrigði.
TLS og DTLS byrja á því ferli að koma á samskiptum milli viðskiptavinar og netþjóns til að skiptast á studdum dulmálssvítum og lyklum. Báðir aðilar semja um sett til að tryggja að frekari samskipti eigi sér stað á öruggri rás. Munurinn á þessu tvennu liggur í litlum breytingum sem gera UDP-undirstaða DTLS kleift að vinna yfir óáreiðanlegri tengingu.
á Nokkrar mismunandi útfærslur á TLS og DTLS komust að því að TLS gerði betur. Árásir á DTLS gengu betur vegna villuþols þess.
Hins vegar er stærsta vandamálið við þessar samskiptareglur að þær voru upphaflega ekki hannaðar til notkunar í IoT og áttu ekki að virka í þoku eða skýi. Með handabandi bæta þeir við viðbótarumferð við hverja tengingu, sem tæmir tölvuauðlindir. Að meðaltali er aukning um 6,5% fyrir TLS og 11% fyrir DTLS í kostnaði miðað við samskipti án öryggislags. Í auðlindaríku umhverfi, sem venjulega er staðsett á stigi mun þetta ekki vera vandamál, en í sambandi milli IoT og þokustigs verður þetta mikilvæg takmörkun.
Hvað á að velja? Það er ekkert skýrt svar. MQTT og HTTP virðast vera efnilegustu samskiptareglurnar þar sem þær eru taldar tiltölulega þroskaðari og stöðugri IoT lausnir samanborið við aðrar samskiptareglur.
Lausnir byggðar á samræmdri samskiptareglu
Ástundun einnar samskiptalausnar hefur marga ókosti. Til dæmis gæti samskiptaregla sem hentar takmörkuðu umhverfi ekki virka á léni sem hefur strangar öryggiskröfur. Með þetta í huga, eigum við eftir að henda næstum öllum mögulegum lausnum með stakri samskiptareglu í Fog-to-Cloud vistkerfinu í IoT, nema MQTT og REST HTTP.
REST HTTP sem lausn með einni samskiptareglu
Það er gott dæmi um hvernig REST HTTP beiðnir og svör hafa samskipti í IoT-to-Fog rýminu: . Dýrin eru útbúin skynjara sem hægt er að bera á sér (IoT viðskiptavinur, C) og stjórnað með tölvuskýi með snjöllu eldiskerfi (Fog server, S).
Hausinn á POST aðferðinni tilgreinir auðlindina sem á að breyta (/býli/dýr) sem og HTTP útgáfu og innihaldsgerð, sem í þessu tilfelli er JSON hlutur sem táknar dýrabúið sem kerfið á að stjórna (Dulcinea/kýr) . Svarið frá þjóninum gefur til kynna að beiðnin hafi tekist með því að senda HTTPS stöðukóða 201 (tilföng búin til). GET aðferðin verður aðeins að tilgreina umbeðna tilföng í URI (til dæmis /farm/animals/1), sem skilar JSON framsetningu dýrsins með því auðkenni frá þjóninum.
PUT aðferðin er notuð þegar uppfæra þarf einhverja tiltekna tilfangaskrá. Í þessu tilviki tilgreinir tilföngin URI fyrir færibreytuna sem á að breyta og núverandi gildi (til dæmis, sem gefur til kynna að kýrin sé að ganga, /bær/dýr/1? ástand=gangandi). Að lokum er DELETE aðferðin notuð jafnt og GET aðferðin, en einfaldlega eyðir auðlindinni sem afleiðing af aðgerðinni.
MQTT sem lausn með einni samskiptareglu
Tökum sama snjalla bæ, en í stað REST HTTP notum við MQTT samskiptareglur. Staðbundinn netþjónn með Mosquitto bókasafnið uppsett virkar sem miðlari. Í þessu dæmi, einföld tölva (vísað til sem bændaþjónninn) Raspberry Pi þjónar sem MQTT viðskiptavinur, útfærður með uppsetningu á Paho MQTT bókasafninu, sem er fullkomlega samhæft við Mosquitto miðlarann.
Þessi viðskiptavinur samsvarar IoT abstraktlagi sem táknar tæki með skynjunar- og tölvugetu. Miðlarinn samsvarar aftur á móti hærra abstraktstigi, sem táknar þokutölvuhnút sem einkennist af meiri vinnslu og geymslugetu.
Í fyrirhugaðri atburðarás fyrir snjallbýli tengist Raspberry Pi við hröðunarmæli, GPS og hitaskynjara og birtir gögn frá þessum skynjurum í þokuhnút. Eins og þú veist líklega, lítur MQTT á efni sem stigveldi. Einn MQTT útgefandi getur birt skilaboð til ákveðins hóps efnis. Í okkar tilviki eru þeir þrír. Fyrir skynjara sem mælir hitastig í dýrafjósi velur viðskiptavinurinn þema (dýrabú/skúr/hitastig). Fyrir skynjara sem mæla GPS staðsetningu og hreyfingu dýra í gegnum hröðunarmælirinn mun viðskiptavinurinn birta uppfærslur á (dýrabú/dýr/GPS) og (dýrabú/dýr/hreyfing).
Þessar upplýsingar verða sendar til miðlara sem getur geymt þær tímabundið í staðbundnum gagnagrunni ef annar áhugasamur áskrifandi kemur síðar.
Til viðbótar við staðbundinn netþjón, sem virkar sem MQTT miðlari í þokunni og sem Raspberry Pis, sem starfar sem MQTT viðskiptavinir, senda skynjaragögn, gæti verið annar MQTT miðlari á skýjastigi. Í þessu tilviki er hægt að geyma upplýsingarnar sem sendar eru til staðbundins miðlara tímabundið í staðbundnum gagnagrunni og/eða senda í skýið. Þoku MQTT miðlari í þessum aðstæðum er notaður til að tengja öll gögn við ský MQTT miðlara. Með þessum arkitektúr getur notandi farsímaforrits verið áskrifandi að báðum miðlarunum.
Ef tengingin við einn miðlara (til dæmis ský) mistekst mun notandi fá upplýsingar frá hinum (þoka). Þetta er einkennandi eiginleiki samsettra þokukerfa og skýjatölvukerfa. Sjálfgefið er að hægt sé að stilla farsímaforritið þannig að það tengist MQTT miðlaranum í þoku fyrst, og ef það mistekst, til að tengjast skýja MQTT miðlaranum. Þessi lausn er aðeins ein af mörgum í IoT-F2C kerfum.
Fjölsamskiptalausnir
Einfaldar samskiptareglur eru vinsælar vegna auðveldari útfærslu þeirra. En það er ljóst að í IoT-F2C kerfum er skynsamlegt að sameina mismunandi samskiptareglur. Hugmyndin er sú að mismunandi samskiptareglur geti starfað á mismunandi stigum. Tökum sem dæmi þrjár útdrættir: lögin af IoT, þoku og skýjatölvu. Tæki á IoT stigi eru almennt talin takmörkuð. Fyrir þetta yfirlit skulum við líta á IoT-þrep sem mest þvinguð, ský sem minnst þvinguð og þokutölvur sem "einhvers staðar í miðjunni." Það kemur þá í ljós að á milli IoT og þokuútdráttar eru núverandi samskiptalausnir MQTT, CoAP og XMPP. Milli þoku og skýs er AMQP aftur á móti ein helsta samskiptareglan sem notuð er ásamt REST HTTP, sem vegna sveigjanleika þess er einnig notað á milli IoT og þokulaga.
Helsta vandamálið hér er samvirkni samskiptareglur og auðveld flutningur skilaboða frá einni samskiptareglu til annarrar. Helst, í framtíðinni, verður arkitektúr hlutanna internets kerfis með skýja- og þokuauðlindum óháð samskiptareglunum sem notuð er og mun tryggja góða samvirkni milli mismunandi samskiptareglna.
Þar sem þetta er ekki raunin eins og er er skynsamlegt að sameina samskiptareglur sem hafa ekki verulegan mun. Í þessu skyni er ein hugsanleg lausn byggð á blöndu af tveimur samskiptareglum sem fylgja sama byggingarstíl, REST HTTP og CoAP. Önnur fyrirhuguð lausn byggir á blöndu af tveimur samskiptareglum sem bjóða upp á samskipti sem birtast áskrifandi, MQTT og AMQP. Að nota svipuð hugtök (bæði MQTT og AMQP nota miðlari, CoAP og HTTP nota REST) gerir þessar samsetningar auðveldari í framkvæmd og krefst minni samþættingar.
Mynd (a) sýnir tvö líkön sem byggjast á beiðni-svörun, HTTP og CoAP, og mögulega staðsetningu þeirra í IoT-F2C lausn. Þar sem HTTP er ein af þekktustu og samþykktustu samskiptareglunum á nútíma netkerfum, er ólíklegt að henni verði algjörlega skipt út fyrir aðrar samskiptareglur fyrir skilaboð. Meðal hnúta sem tákna öflug tæki sem sitja á milli skýsins og þokunnar, er REST HTTP snjöll lausn.
Aftur á móti, fyrir tæki með takmarkaða tölvuauðlindir sem hafa samskipti á milli þoku- og IoT-laganna, er skilvirkara að nota CoAP. Einn af stóru kostunum við CoAP er í raun samhæfni þess við HTTP, þar sem báðar samskiptareglur eru byggðar á REST meginreglum.
Mynd (b) sýnir tvö samskiptalíkön sem birt eru í áskrift í sömu atburðarás, þar á meðal MQTT og AMQP. Þrátt fyrir að hægt væri að nota báðar samskiptareglurnar fyrir samskipti milli hnúta á hverju útdráttarlagi, ætti staðsetning þeirra að vera ákvörðuð út frá frammistöðu. MQTT var hannað sem léttur samskiptareglur fyrir tæki með takmarkaða tölvuauðlindir, svo það er hægt að nota það fyrir IoT-Fog samskipti. AMQP hentar betur fyrir öflugri tæki, sem myndi helst staðsetja það á milli þoku- og skýjahnúta. Í stað MQTT er hægt að nota XMPP samskiptareglur í IoT þar sem hún er talin létt. En það er ekki svo mikið notað í slíkum aðstæðum.
Niðurstöður
Ólíklegt er að ein af samskiptareglunum sem fjallað er um dugi til að ná yfir öll samskipti í kerfi, allt frá tækjum með takmarkaða tölvuauðlindir til skýjaþjóna. Rannsóknin leiddi í ljós að tveir efnilegustu valkostirnir sem verktaki nota mest eru MQTT og RESTful HTTP. Þessar tvær samskiptareglur eru ekki aðeins þær þroskuðustu og stöðugustu, heldur innihalda þær einnig margar vel skjalfestar og árangursríkar útfærslur og úrræði á netinu.
Vegna stöðugleika og einfaldrar uppsetningar er MQTT samskiptaregla sem hefur sannað yfirburði sína með tímanum þegar hún er notuð á IoT stigi með takmörkuðum tækjum. Í hlutum kerfisins þar sem takmörkuð samskipti og rafhlöðunotkun eru ekki vandamál, eins og sumum þokulennum og flestum tölvuskýjum, er RESTful HTTP auðvelt val. Einnig ætti að taka tillit til CoAP þar sem það er einnig í örri þróun sem IoT skilaboðastaðall og líklegt er að það nái stöðugleika og þroska svipað og MQTT og HTTP í náinni framtíð. En staðallinn er nú í þróun, sem fylgir skammtímasamhæfisvandamálum.
Hvað annað er hægt að lesa á blogginu?
→
→
→
→
→
Gerast áskrifandi að okkar -rás svo þú missir ekki af næstu grein! Við skrifum ekki oftar en tvisvar í viku og aðeins í viðskiptum.
Heimild: www.habr.com