Utvecklingen av teknik inom mjukvara och hÄrdvara, samt framvÀxten av nya kommunikationsprotokoll, har lett till en utvidgning av Internet of Things (IoT). Antalet enheter ökar dag för dag och de genererar en enorm mÀngd data. DÀrför uppstÄr behovet av en flexibel systemarkitektur som kan bearbeta, lagra och överföra dessa data.
För dessa syften anvÀnds idag molntjÀnster. Men den allt mer populÀra modellen för fogberÀkning (Fog) kan komplettera molnlösningarna genom att skala och optimera IoT-infrastrukturen.
Moln kan tillfredsstÀlla de flesta behoven inom IoT. Till exempel kan de möjliggöra övervakning av tjÀnster, snabb bearbetning av stora datamÀngder som genereras av enheter samt deras visualisering. à andra sidan Àr fogberÀkningar effektivare vid lösningen av realtidsuppgifter. De erbjuder snabb respons pÄ förfrÄgningar och minimal fördröjning vid databehandling. Det vill sÀga, Fog kompletterar verkligen molnen och utökar deras kapabiliteter.
Men den centrala frÄgan Àr en annan: hur ska allt detta interagera i kontexten av IoT? Vilka kommunikationsprotokoll kommer att vara mest effektiva i en sammanslagen IoT-Fog-Cloud-system?
Trots den till synes dominerande anvÀndningen av HTTP anvÀnds mÄnga andra lösningar i IoT-, Fog- och Cloud-system. Detta beror pÄ att IoT mÄste kombinera de funktionella möjligheterna hos olika enhetsensorer med sÀkerhet, kompatibilitet och andra krav som anvÀndarna stÀller.
Det finns dock ingen enhetlig uppfattning om en referensarkitektur eller kommunikationsstandard. DÀrför Àr skapandet av en ny protokoll eller anpassningen av en befintlig sÄdan för specifika IoT-uppgifter en av de viktigaste utmaningarna för IT-samhÀllet.
Vilka protokoll anvÀnds idag och vad kan de erbjuda? LÄt oss undersöka det. Men först diskuterar vi principerna för det ekosystem dÀr moln, dimma och Internet of Things interagerar.
IoT Fog-to-Cloud-arkitektur (F2C)
Du har förmodligen mÀrkt hur betydande anstrÀngningar som görs för att studera fördelarna och vinsterna med effektiv och koordinerad hantering av IoT, moln och dimma. Om inte, sÄ hÀr Àr tre initiativ för standardisering: , och .
Om man tidigare endast har övervÀgt tvÄ nivÄer, moln och enheter, sÄ introducerar den föreslagna arkitekturen en ny nivÄ - dimberÀkning. Dimbeslutning kan delas upp i flera undernivÄer beroende pÄ resursernas specifika natur eller uppsÀttningen av policys som definierar anvÀndningen av olika enheter i dessa undernivÄer.
Hur kan denna abstraktion se ut? HÀr Àr ett typiskt IoT-Dim-Moln ekosystem. IoT-enheter skickar data till mer kraftfulla servrar och berÀkningsenheter för att lösa uppgifter som krÀver lÄg latens. I detta system ansvarar molnen för att lösa uppgifter som krÀver stor mÀngd berÀkningsresurser eller lagringsutrymme.
Smartphones, smarta klockor och andra enheter kan ocksÄ vara en del av IoT. Men sÄdana enheter anvÀnder vanligtvis proprietÀra kommunikationsprotokoll frÄn stora utvecklare. De genererade IoT-data överförs till dimnivÄn via REST HTTP-protokollet, vilket erbjuder flexibilitet och funktionell kompatibilitet vid skapandet av RESTful-tjÀnster. Detta Àr viktigt med hÀnsyn till behovet av att sÀkerstÀlla bakÄtkompatibilitet med den befintliga berÀkningsinfrastrukturen som körs pÄ lokala datorer, servrar eller serverkluster. Lokala resurser, som kallas "dimknutpunkter", filtrerar den mottagna datan och bearbetar den lokalt eller vidarebefordrar den till molnet för ytterligare bearbetning.
Moln stöder olika kommunikationsprotokoll, dÀr AMQP och REST HTTP ofta förekommer. Eftersom HTTP Àr allmÀnt kÀnt och inriktat pÄ internet kan frÄgan uppstÄ: "Skulle vi inte kunna anvÀnda det för IoT och dimberÀkning?". Men detta protokoll har prestandaproblem. Mer om detta senare.
Generellt finns det tvÄ modeller av kommunikationsprotokoll som Àr lÀmpliga för vÄrt system. Dessa Àr förfrÄgan-svar och publicera-prenumerera. Den första modellen Àr mer kÀnd, sÀrskilt i server-klientarkitektur. Klienten begÀr information frÄn servern, som tar emot förfrÄgan, bearbetar den och ÄterlÀmnar ett svar. Protokollen REST HTTP och CoAP fungerar enligt denna modell.
Den andra modellen uppstod ur behovet att sÀkerstÀlla asynkron, distribuerad, svag kommunikation mellan kÀllor som genererar data och mottagarna av dessa data.
Modellen involverar tre parter: utgivare (datakÀlla), mÀklare (dispatcher) och prenumerant (mottagare). HÀr behöver kunden, som agerar som prenumerant, inte begÀra information frÄn servern. IstÀllet för att skicka förfrÄgningar prenumererar han pÄ specifika hÀndelser i systemet via mÀklaren, som Àr ansvarig för att filtrera all inkommande information och att dirigera den mellan utgivarna och prenumeranterna. NÀr en hÀndelse intrÀffar som rör ett visst Àmne publicerar utgivaren det till mÀklaren, som skickar informationen till prenumeranten angÄende det begÀrda Àmnet.
I grunden Àr denna arkitektur baserad pÄ hÀndelser. En sÄdan interaktionsmodell Àr intressant för applikationer inom IoT, moln, och fog pÄ grund av dess förmÄga att sÀkerstÀlla skalbarhet och förenkla interaktionen mellan olika enheter, stödja dynamisk "mÄnga-till-mÄnga" kommunikation och asynkron kommunikation. Bland de mest kÀnda standardiserade meddelandeprotokollen som anvÀnder "publicering-prenumeration"-modellen kan vi nÀmna MQTT, AMQP och DDS.
Det Àr uppenbart att "publicering-prenumeration"-modellen har mÄnga fördelar:
- Utgivare och prenumeranter behöver inte kÀnna till varandras existens;
- En prenumerant kan fÄ information frÄn mÄnga olika utgÄvor, och en utgivare kan skicka data till mÄnga olika prenumeranter (principen "mÄnga-till-mÄnga");
- Utgivaren och prenumeranten behöver inte vara aktiva samtidigt för att utbyta data, eftersom mÀklaren (som fungerar som ett kö-system) kan lagra meddelandet för kunder som för nÀrvarande inte Àr anslutna till nÀtverket.
Men "begÀr-svar"-modellen har ocksÄ sina styrkor. I de fall dÀr serverns kapacitet att hantera förfrÄgningar frÄn flera kunder inte Àr ett problem, Àr det meningsfullt att anvÀnda redan beprövade pÄlitliga lösningar.
Det finns ocksÄ protokoll som stöder bÄda modellerna. Till exempel, XMPP och HTTP 2.0, som stöder alternativet "server push". IETF har ocksÄ slÀppt CoAP. För att försöka lösa meddelandeutbytesproblemet har flera andra lösningar skapats, sÄsom WebSockets-protokollet eller anvÀndning av HTTP över QUIC (Quick UDP Internet Connections).
NÀr det gÀller WebSockets, Àven om det anvÀnds för att överföra data i realtid frÄn servern till webbkunden och erbjuder permanenta anslutningar med samtidig tvÄvÀgskommunikation, Àr det inte avsett för enheter med begrÀnsade berÀkningsresurser. QUIC förtjÀnar ocksÄ uppmÀrksamhet eftersom den nya transportprotokollen ger massor av nya möjligheter. Men eftersom QUIC Ànnu inte har standardiserats Àr det för tidigt att förutsÀga dess möjliga tillÀmpningar och pÄverkan pÄ IoT-lösningar. SÄ vi lÀmnar WebSockets och QUIC i minnet med sikte pÄ framtiden, men kommer inte att studera dem nÀrmare för tillfÀllet.
Vem Àr vackrast i vÀrlden: vi jÀmför protokollen
Nu ska vi prata om styrkor och svagheter hos protokollen. För att avslöja det direkt, finns det ingen uppenbar ledare. Varje protokoll har sina egna fördelar och nackdelar.
Svarstid
En av de viktigaste egenskaperna hos kommunikationsprotokoll, sÀrskilt i förhÄllande till Internet of Things, Àr svarstiden. Men bland de befintliga protokollen finns det ingen tydlig vinnare som visar den minimi fördröjningen under olika förhÄllanden. Det finns dock en hel del forskning och jÀmförelser av protokollens möjligheter.
Till exempel, JÀmförelser av effektiviteten mellan HTTP och MQTT vid arbete med IoT har visat att svarstiden för förfrÄgningar Àr kortare för MQTT Àn för HTTP. Och vid av överföringstid (RTT) visade det sig att det genomsnittliga RTT för CoAP Àr 20% kortare Àn för MQTT.
Annat RTT för protokollen MQTT och CoAP undersöktes i tvÄ scenarier: lokalt nÀtverk och IoT-nÀtverk. Det visade sig att den genomsnittliga RTT var 2-3 gÄnger högre i IoT-nÀtverket. MQTT med QoS0 visade ett lÀgre resultat jÀmfört med CoAP, medan MQTT med QoS1 demonstrerade en högre RTT pÄ grund av ACK pÄ applikations- och transportnivÄerna. För olika QoS-nivÄer var fördröjningarna i nÀtverket utan överbelastning för MQTT millisekunder, och för CoAP hundratals mikrosekunder. Det Àr dock viktigt att komma ihÄg att MQTT, som arbetar över TCP, kommer att visa ett helt annat resultat i mindre pÄlitliga nÀtverk.
responsen för protokollen AMQP och MQTT genom att öka nyttolasten visade att vid lÄg belastning var fördröjningsnivÄn nÀstan identisk. Men vid överföring av stora mÀngder data visar MQTT en kortare svarstid. I en annan CoAP jÀmfördes med HTTP i ett maskin-till-maskin-scenario med enheter distribuerade pÄ fordon, utrustade med gas-sensorer, vÀdersensorer, plats (GPS) och mobilnÀtverksgrÀnssnitt (GPRS). Tiden som krÀvdes för att överföra ett CoAP-meddelande via mobilnÀtet var nÀstan tre gÄnger kortare Àn tiden som krÀvdes för att anvÀnda HTTP-meddelanden.
Studier genomfördes dÀr inte tvÄ, utan tre protokoll jÀmfördes. Till exempel, prestandan för IoT-protokollen MQTT, DDS och CoAP i ett medicinskt tillÀmpningsscenario med anvÀndning av ett nÀtverksimulator. DDS övertrÀffade MQTT nÀr det gÀller den upplevda fördröjningen av telemetri under olika dÄliga nÀtverksförhÄllanden. CoAP, baserat pÄ UDP, fungerade bra för applikationer som krÀvde snabb respons, men pÄ grund av att det Àr baserat pÄ UDP förekom betydande oförutsÀgbar paketförlust.
Bandbredd
MQTT och CoAP nÀr det gÀller effektivitet för bandbredden genomfördes som en berÀkning av den totala mÀngden data som överfördes per meddelande. CoAP visade en lÀgre bandbredd Àn MQTT vid överföring av smÄ meddelanden. Men vid jÀmförelse av protokollens effektivitet med avseende pÄ förhÄllandet mellan mÀngden nyttiga informationsbitar och den totala mÀngden överförda bitar visade sig CoAP vara mer effektivt.
Vid Genom att anvÀnda MQTT, DDS (med TCP som transportprotokoll) och CoAP visade det sig att CoAP i allmÀnhet hade en jÀmförelsevis lÀgre bandbreddsanvÀndning, vilket inte ökade vid högre nÀtverksförlust eller ökad nÀtverksfördröjning, till skillnad frÄn MQTT och DDS, dÀr en ökning av bandbreddsanvÀndningen observerades under dessa scenarier. I ett annat scenario involverades ett stort antal enheter som sÀnde data samtidigt, vilket Àr ett typiskt fall i IoT-miljöer. Resultaten visade att CoAP Àr bÀttre för högre belastning.
Vid lÄg belastning anvÀnde CoAP den lÀgsta bandbredden, följt av MQTT och REST HTTP. Men nÀr storleken pÄ nyttolaster ökade, hade REST HTTP de bÀsta resultaten.
Energiförbrukning
FrÄgan om energiförbrukning Àr alltid av stor betydelse, och i IoT-system Àr den sÀrskilt viktig. Om energikonsumtionen hos MQTT och HTTP, visar det sig att HTTP "slukar" betydligt mer. CoAP Àr mer jÀmfört med MQTT, vilket möjliggör energihantering. I enkla scenarier passar MQTT bÀttre för informationsutbyte i IoT-nÀtverk, sÀrskilt nÀr det inte finns nÄgra effektbegrÀnsningar.
Ett experiment som jÀmförde kapabiliteterna hos AMQP och MQTT under en testbÀnk för mobil eller instabil trÄdlös nÀtverk visade att AMQP erbjuder mer sÀkerhetsmöjligheter, medan MQTT Àr mer energieffektivt.
SĂ€kerhet
SÀkerhet Àr en annan viktig frÄga som tas upp vid studier av IoT och moln-/fogberÀkningar. SÀkerhetsmekanismen baseras vanligtvis pÄ TLS i HTTP, MQTT, AMQP och XMPP, eller DTLS i CoAP, samt stödjer bÄda i DDS.
TLS och DTLS börjar med en kommunikationsetableringsprocess mellan klient- och serverpartier för att utbyta stödda krypteringspaket och nycklar. BÄda parter kommer överens om paketen för att sÀkerstÀlla att fortsatt kommunikation sker i en sÀker kanal. Skillnaden mellan dem ligger i smÄ modifieringar som gör det möjligt för DTLS att fungera över opÄlitliga anslutningar baserade pÄ UDP.
Vid Vid flera olika implementeringar av TLS och DTLS har det visat sig att TLS Ă€r bĂ€ttre pĂ„ att hantera uppgiften. Attacker pĂ„ DTLS har varit mer framgĂ„ngsrika pĂ„ grund av dess feltoleÂrans.
Men det största problemet med dessa protokoll Ă€r att de ursprungligen inte var avsedda för anvĂ€ndning inom IoT och inte förutsatte arbete i moln eller edge. Genom en överenskommen utbyte (handshaking) lĂ€gger de till extra trafik med varje anslutning, vilket tömmer berĂ€kningsresursÂer. I genomsnitt observeras en ökning pĂ„ 6,5 % för TLS och 11 % för DTLS i overhead jĂ€mfört med kommunikation utan sĂ€kerhetslager. I resursstarka miljöer, som vanligtvis Ă€r belĂ€gna pĂ„ , detta kommer inte att vara ett problem, men i kommunikationen mellan IoT och edge-nivĂ„ blir detta en viktig begrĂ€nsning.
Vad ska man vÀlja? Det finns inget entydigt svar. MQTT och HTTP verkar vara de mest lovande protokollen, eftersom de anses vara relativt mogna och stabila lösningar för IoT jÀmfört med andra protokoll.
Lösningar baserade pÄ ett enda kommunikationsprotokoll
Praxis för enprotokollslösning har mÄnga nackdelar. Till exempel kan ett protokoll som tillfredsstÀller en begrÀnsad miljö inte fungera i en domÀn som har strikta sÀkerhetskrav. Med detta i Ätanke ÄterstÄr det att avfÀrda nÀstan alla möjliga enprotokollslösningar i Fog-to-Cloud ekosystemet i IoT, förutom MQTT och REST HTTP.
REST HTTP som enprotokollslösning
Det finns ett bra exempel pÄ interaktionen mellan förfrÄgningar och svar via REST HTTP inom IoT-to-Fog: . Djuren utrustas med bÀrbara sensorer (IoT-klient, C) och hanteras genom molnbaserade berÀkningar av ett smart jordbrukssystem (Fog-server, S).
I POST-metodens rubrik anges resursen som ska Ă€ndras (\/farm\/animals), sĂ„vĂ€l som versionen av HTTP och typen av innehĂ„ll, vilket i detta fall Ă€r ett JSON-objekt som representerar den djurhĂ„llning som systemet ska hantera (Dulcinea\/ko). Svaret frĂ„n servern indikerar att förfrĂ„gan var framgĂ„ngsrik genom att skicka tillbaka HTTPS-statuskod 201 (resurÂs skapad). GET-metoden ska endast ange den begĂ€rda resursen i URI (till exempel \/farm\/animals\/1), som returnerar JSON-representationen av djuret med detta ID frĂ„n servern.
PUT-metoden anvÀnds nÀr det Àr nödvÀndigt att uppdatera en specifik post av en resurs. I det hÀr fallet anges URI för parametern som ska Àndras och det aktuella vÀrdet (till exempel som anger att en ko för nÀrvarande gÄr, /farm/animals/1?state=walking). Slutligen anvÀnds DELETE-metoden pÄ samma sÀtt som GET-metoden, men den tar endast bort resursen som ett resultat av operationen.
MQTT som en enhetlig protokollösning
LÄt oss ta den smarta gÄrden igen, men istÀllet för REST HTTP anvÀnder vi protokollet MQTT. En lokal server med den installerade Mosquitto-biblioteket fungerar som en mÀklare. I detta exempel fungerar en vanlig dator (benÀmnd farmserver) Raspberry Pi som en MQTT-klient, implementerat genom att installera MQTT Paho-biblioteket, helt kompatibelt med Mosquitto-mÀklaren.
Denna klient motsvarar en IoT-abstraktionsnivÄ som representerar en enhet med upptÀckts- och berÀkningsförmÄgor. MÀklaren, Ä sin sida, motsvarar en högre abstraheringsnivÄ, vilken representerar en berÀkningsnod i molnet, karakteriserad av större kapaciteter avseende databehandling och lagring.
I det föreslagna scenariot för den "smarta gÄrden" ansluter Raspberry Pi till accelerometrar, GPS och temperatursensorer och publicerar data frÄn dessa sensorer i molnnoden. Som du sÀkert vet, betraktar MQTT Àmnen som en hierarki. En MQTT-utgivare kan publicera meddelanden i en specifik uppsÀttning Àmnen. I vÄrt fall finns det tre. För sensorn som mÀter temperaturen i djurens lada vÀljer klienten Àmnet (animalfarm/shed/temperature). För sensorer som mÀter GPS-positionen och djurens rörelse via accelerometern publicerar klienten uppdateringar (animalfarm/animal/GPS) och (animalfarm/animal/movement).
Denna information kommer att överföras till mÀklaren, som kan lagra den tillfÀlligt i en lokal databas ifall det senare kommer en annan intresserad prenumerant.
Utöver den lokala servern som agerar MQTT-broker i dimman, till vilken Raspberry Pi-förekomster fungerar som MQTT-klienter som skickar data frÄn sensorer, kan det finnas en annan MQTT-broker pÄ molnnivÄ. I detta fall kan information som skickas till den lokala brokern temporÀrt lagras i en lokal databas och/eller skickas till molnet. Den dimmiga MQTT-brokern anvÀnds i detta scenario för att koppla samman all data med molnets MQTT-broker. Med en sÄdan arkitektur kan anvÀndaren av mobilappen prenumerera pÄ bÄda brokern.
Vid ett fel i anslutningen till en av brokern (till exempel molntjÀnsten) fÄr slutanvÀndaren information frÄn den andra (dimman). Detta Àr en karakteristisk funktion hos kombinerade system av dimma och molnberÀkning. Som standard kan mobilappen konfigureras för första anslutning till den dimmiga MQTT-brokern, och vid misslyckande tillkopplas MQTT-brokern i molnet. Denna lösning Àr bara en av mÄnga i IoT-F2C-system.
Protokollöverskridande lösningar
Lösningar med ett enda protokoll Àr populÀra pÄ grund av deras enklare implementering. Men det Àr uppenbart att det i IoT-F2C-system Àr meningsfullt att kombinera olika protokoll. Idén Àr att olika protokoll kan fungera pÄ olika nivÄer. LÄt oss till exempel betrakta tre abstraktioner: nivÄerna av IoT, dimma och molnberÀkning. Enheter pÄ IoT-nivÄ anses vanligtvis vara begrÀnsade. För denna översikt anser vi att IoT-nivÄer Àr de mest begrÀnsade, molnnivÄerna Àr minst begrÀnsade, och dimmiga berÀkningar ligger
Det grundlÀggande problemet hÀr Àr den funktionella kompatibiliteten hos protokoll och enkelheten att översÀtta meddelanden frÄn ett protokoll till ett annat. I idealfallet kommer framtida arkitekturer för Internet of Things med moln- och dimresurser att vara oberoende av det anvÀnda kommunikationsprotokollet och sÀkerstÀlla en god interaktion mellan olika protokoll.
Eftersom det för nÀrvarande inte Àr fallet, Àr det meningsfullt att kombinera protokoll som inte har nÄgra betydande skillnader. För detta syfte baseras en potentiell lösning pÄ kombinationen av tvÄ protokoll som följer samma arkitektur, REST HTTP och CoAP. En annan föreslagen lösning bygger pÄ sammanslagningen av tvÄ protokoll som erbjuder interaktion enligt modellen "publicering-prenumeration", MQTT och AMQP. AnvÀndningen av liknande koncept (bÄde MQTT och AMQP anvÀnder mÀklare, CoAP och HTTP anvÀnder REST) förenklar implementeringen av dessa kombinationer och krÀver mindre integrationsinsats.
I figur (a) visas tvÄ modeller baserade pÄ begÀrningar-svar, HTTP och CoAP, och deras möjliga placeringar i IoT-F2C-lösningen. Eftersom HTTP Àr ett av de mest kÀnda och anpassade protokollen i moderna nÀtverk, Àr det osannolikt att det kommer att helt ersÀttas av andra meddelandeprotokoll. Bland noderna som representerar kraftfulla enheter som ligger mellan molnet och dimman, Àr REST HTTP en rimlig lösning.
à andra sidan, för enheter med begrÀnsade datorkapaciteter som kopplas mellan dimnivÄerna och IoT, Àr det mer effektivt att anvÀnda CoAP. En av de stora fördelarna med CoAP Àr faktiskt dess kompatibilitet med HTTP, eftersom bÄda protokollen bygger pÄ principerna för REST.
I figur (b) visas tvĂ„ modeller för interaktion "publicering-prenumeration" i ett scenario, inklusive MQTT och AMQP. Ăven om bĂ„da protokollen hypotetiskt kan anvĂ€ndas för kommunikation mellan noder pĂ„ varje abstraktionsnivĂ„, bör deras position bestĂ€mmas baserat pĂ„ prestanda. MQTT utvecklades som ett förenklat protokoll för enheter med begrĂ€nsade datorkapaciteter, sĂ„ det kan anvĂ€ndas för kommunikation mellan IoT och dimman. AMQP Ă€r mer lĂ€mpligt för kraftfullare enheter, som skulle passa perfekt mellan dimnoder och molnet. IstĂ€llet för MQTT kan protokollet XMPP anvĂ€ndas i IoT, eftersom det anses vara lĂ€ttviktigt. Men det anvĂ€nds inte sĂ„ ofta i sĂ„dana scenarier.
Slutsatser
Det Àr osannolikt att nÄgon av de protokoll som diskuteras ensamt kan tÀcka all kommunikation i systemet, frÄn enheter med begrÀnsade berÀkningsresurser till molnservrar. Forskningen visade att de tvÄ mest lovande alternativen som utvecklare oftast anvÀnder Àr MQTT och RESTful HTTP. Dessa tvÄ protokoll Àr inte bara de mest mogna och stabila, utan de inkluderar ocksÄ mÄnga vÀl dokumenterade och framgÄngsrika implementationer och online-resurser.
Tack vare sin stabilitet och enkla konfiguration Àr MQTT ett protokoll som över tid har bevisat sin överlÀgsna prestanda vid anvÀndning pÄ IoT-nivÄ med begrÀnsade enheter. I systemdelar dÀr begrÀnsad kommunikation och batteriförbrukning inte Àr problem, som i vissa omrÄden av fog computing och de flesta molntjÀnster, Àr RESTful HTTP ett enkelt val. CoAP bör ocksÄ beaktas, eftersom det snabbt utvecklas som en IoT-meddelandestandard, och det Àr mycket troligt att det inom en snar framtid kommer att nÄ en stabilitets- och mognadsnivÄ jÀmförbar med MQTT och HTTP. Men standarden utvecklas fortfarande, vilket medför kortsiktiga kompatibilitetsproblem.
Vad mer intressant kan man lÀsa i bloggen
â
â
â
â
â
Prenumerera pÄ vÄr -kanal för att inte missa nÀsta artikel! Vi skriver högst tvÄ gÄnger i veckan och endast om viktiga Àmnen.
KĂ€lla: habr.com
