sporoˇcila dostavljena v skladu z doloˇcenim kakovostnim razredom. Ponavadi je posre-dnik nameˇsˇcen na zanesljivem raˇcunalniku, ki obratuje neprestano. Obiˇcajno imamo v sistemu enega posrednika, pri kompleksnejˇsih aplikacijah pa lahko pride tudi do si-tuacije, kjer jih imamo veˇc. V tem primeru je moˇzno posrednika nastaviti, da obratuje kot most (ang. bridge). Tako se torej eden izmed posrednikov do drugega obnaˇsa kot klient. Posrednika je mogoˇce nastaviti tudi tako, da sporoˇcila poˇsilja preko protokola WebSocket. To je ˇse posebej uporabno, kadar ˇzelimo sporoˇcila poˇsiljati direktno v sple-tni brskalnik, ki sam po sebi ne podpira MQTT protokola. V tem primeru se splesple-tni brskalnik poveˇze s posrednikom preko WebSocket protokola in se obnaˇsa kot samosto-jen klient. Za namestitev posrednika je na voljo veˇc ponudnikov. V naˇsem primeru smo izbrali odprtokodnega posrednika Eclipse Mosquitto [11], ki je redno vzdrˇzevan in podprt s strani ˇstevilnih organizacij. Za testne namene in razhroˇsˇcevanje pa je na voljo tudi javno dostopen posrednik v oblaku [12].
Klient
Vsaka naprava ali aplikacija, ki se poveˇze s posrednikom in preko njega objavlja sporoˇcila (opravlja funkcijo zaloˇznika) ali se na njih le naroˇci (opravlja funkcijo naroˇcnika).
Klient je lahko tudi naroˇcnik in zaloˇznik hkrati. Klienti so tako lahko samostojni raˇcunalniki, mobilne naprave, mikrokrmilniki ali spletne aplikacije. Tudi tu je na voljo vrsta knjiˇzic za razvoj klienta v razliˇcnih programskih jezikih. Ker bomo v naˇsem pri-meru uporabljali programski jezik Python in zaradi specifiˇcne narave naˇse aplikacije (velik tok podatkov), smo izbrali knjiˇzico asyncio-mqtt [13], ki za osnovo uporablja priznano knjiˇzico Eclipse Paho [14].
8
Teoretiˇcne osnove in pregled literature Potek prijave in objave v temo
Vsak klient najprej izvede povezavo s posrednikom. Zaradi varnosti, se na podlagi posredovanega uporabniˇskega imena in gesla, ki smo ga predhodno izbrali med kon-figuracijo posrednika, opravi overitev klienta. Po uspeˇsno vzpostavljeni povezavi po-srednik drˇzi odprto povezavo s klientom, dokler je ta ne izgubi ali poˇslje kontrolni paket za zaprtje le-te. Klient se nato prijavi (ang. subscribe) na izbrano temo (ang.
topic). Teme imajo hierarhiˇcno strukturo, kjer so (/) uporabljene kot loˇcila stopenj teme. Primer bi torej bil: meritve/raspberry01/vhod01, kjer je meritve najviˇsja stopnja teme, vhod01 pa najniˇzja. Pri prijavah sta nam na voljo tudi dva nadome-stna znaka (ang. wildcards), ki poenostavita proces v primeru, da se ˇzelimo naroˇciti na veˇc tem hkrati. Plus znak (+) je enostopenjski nadomestni simbol, ki nadomesti katerokoli ime na specifiˇcni stopnji. Naroˇcilo na meritve/+/vhod01 bo tako rezul-tiralo kot naroˇcilo na vse raˇcunalnike RPI npr. meritve/raspberry01/vhod01 in meritve/raspberry02/vhod01. Drugi nadomestni znak je simbol kljuˇcnika (#), ki je veˇcstopenjski in se ga lahko uporablja le na koncu filtra teme. V tem primeru bomo naroˇceni na vse teme, katerih najviˇsja stopnja je enaka. Naroˇcilo na meritve/# torej pomeni naroˇcilo na vse teme, ki se zaˇcnejo zmeritve/. Pozorni moramo biti tudi na velike in male ˇcrke.
Kakovostni razredi
Protokol MQTT nam omogoˇca definicijo kakovosti storitve (ang. Quality of Service).
Na tem mestu je vredno omeniti, da definicija kakovostnega razreda vkljuˇcuje tako po-srednika kot klienta. Torej lahko objavljamo z neko stopnjo kakovosti in se prijavljamo (z drugim klientom) z drugaˇcno stopnjo kakovosti. V tem primeru bo posrednik prilago-dil kakovost storitve na niˇzjo zahtevano. Z izbrano stopnjo kakovosti meritve vplivamo, na kakˇsen naˇcin se preverja, ˇce je bilo sporoˇcilo uspeˇsno dostavljeno. Obstajajo sledeˇci kakovostni razredi:
– 0, dostavljeno najveˇc enkrat: Ta kakovostni razred ponuja enako garancijo kot osnovni TCP protokol na osnovi katerega je MQTT zgrajen. Sporoˇcilo ni potrjeno s strani prejemnika ali destinacije. Poˇsiljatelj le poˇslje sporoˇcilo. Sporoˇcila, ki ne prispejo na cilj so izgubljena. Glavna prednost te stopnje je, da porablja najmanj raˇcunalniˇskih virov in internetne pasovne ˇsirine.
– 1, dostavljeno vsaj enkrat: Ta kakovostni razredu doda potrditvene zahteve na strani prejemnika. Poˇsiljatelj shranjuje sporoˇcilo, dokler ne dobi potrdila, da je bilo sporoˇcilo prejeto s strani prejemnika. Zagotovi, da je bilo sporoˇcilo dostavljeno. ˇCe potrdila v specifiˇcnem ˇcasu ne prejme, le-tega poˇslje ponovno. Zavedati se moramo, da v doloˇcenih primerih lahko pride do podvojenih sporoˇcil, ki jih moramo v pro-gramu odstranjevati sami. Ta kakovostni razred tudi porabi precej veˇc raˇcunalniˇskih virov in internetne pasovne ˇsirine.
– 2, dostavljeno toˇcno enkrat: Zadnji in najstroˇzji kakovostni razred storitve zago-tavlja, da je sporoˇcilo vedno dostavljeno le enkrat. Zahteva dodaten tok informacij, ki ˇse dodatno potrdi, da je bilo sporoˇcilo prejeto s strani prejemnika natanko enkrat.
Je najbolj zahteven, kar se tiˇce virov in pasovne ˇsirine. Ponavadi se ga uporablja le v primerih, kjer nimamo stabilne internetne povezave in ˇzelimo zagotoviti, da bo sporoˇcilo kljub temu dostavljeno, ˇceprav z nekolikˇsnim zamikom.
Teoretiˇcne osnove in pregled literature 2.2.1.2 WebSocket protokol
WebSocket protokol je uradno definiran in podrobneje opisan v internetnem standardu RFC 6455 [15], ki je bil sprejet leta 2011, ko je veˇcina internetnih brskalnikov ˇze uradno podpirala protokol. V pomoˇc pri razumevanju in programiranju nam je bila knjiga av-torja A. Lombardi [16], uradna mozillina dokumentacija za razvijalce 17 in dokumen-tacija Python knjiˇzice websocket [18]. Tehnologija Websocket omogoˇca dvosmerno komunikacijo oziroma polni dupleks (ang. full-duplex), komunikacijski kanal, preko enojne TCP povezave. Tehnologija daje moˇznost izdelave aplikacije, katere stanja se posodabljajo zelo blizu realnega ˇcasa, brez ponovnega nalaganja spletne strani. ˇCeprav WebSocket uporablja HTTP kot zaˇcetni transportni mehanizem, se komunikacija med odjemalcem in streˇznikom ne konˇca, temveˇc ostane odprta. Protokol se tako mnoˇziˇcno uporablja za implementacijo klepetalnic, iger za veˇc igralcev, IoT platform, finanˇcnih aplikacij, beleˇzenj aktivnosti uporabnikov, GPS aplikacij, izobraˇzevalnih platform ...
Skratka tam, kjer v spletni aplikaciji potrebujemo osveˇzevanje v realnem ˇcasu. Na slikah 2.4 in 2.5 sta prikazana diagrama, ki prikazujeta princip delovanja klasiˇcnega HTTP v primerjavi z WebSocket protokolom.
Zahtevek
Klient Strežnik
Odgovor
Povezava zaprta
Slika 2.4: ˇZivljenjski cikel HTTP protokola [19].
Standardni HTTP protokol poteka v ˇstirih korakih. Najprej se odpre TCP povezava med odjemalcem in streˇznikom. Nato odjemalec poˇslje zahtevek (ang. request) in prejme odgovor streˇznika (ang. response) oziroma zahtevane podatke. V konˇcnem koraku se povezava zapre ali ponovno uporabi za nadaljnje zahteve.
Za razliko od HTTP, WebSocket protokol ne operira v ciklu zahtevek-odgovor. Tu se najprej preko HTTP protokola zgodi spoznavanje (ang. handshake) med streˇznikom in odjemalcem. Takrat tudi streˇznik prejme sporoˇcilo, da bo za komunikacijo uporabljen WebSocket in ne HTTP protokol. Tunel (ang. network tunnel) za dvosmerno komuni-kacijo nato ostane odprt in podatki med streˇznikom in odjemalcem tako lahko prosto prehajajo v realnem ˇcasu, dokler eden izmed njih ne zapre povezave.
10
Teoretiˇcne osnove in pregled literature
Klient Strežnik
Spoznavanje (HTTP)
Dvosmerna komunikacija (WebSocket)
Ena izmed strani zapre povezavo
Povezava se odpre
Dolgotrajna povezava
Povezava zaprta
Slika 2.5: ˇZivljenjski cikel WebSocket protokola [17].
2.2.2 Orodja s podroˇ cja razvoja spletnih aplikacij
Pri razvoju spletne aplikacije je pomembno, da se ˇze v zaˇcetnih fazah vpraˇsamo, katere dodatne funkcionalnosti poleg primarnih in najbolj kljuˇcnih so za nas pomembne. To so recimo upravljanje in avtentifikacija uporabnikov, prijazna uporabniˇska izkuˇsnja, enostavno upravljanje itd. Kot razvijalci se seveda ne ˇzelimo vedno znova ukvarjati z razvojem pogostih znaˇcilnosti, zato so na voljo ˇstevilni paketi, ki nam pohitrijo razvoj in omogoˇcijo, da se osredotoˇcimo le na naˇs specifiˇcen cilj. V naˇsem primeru je to implementacija izbranih tehnologij oz. protokolov za oddaljeno spremljanje dinamike struktur.
Eden izmed zelo popularnih in razˇsirjenih paketov za razvoj spletnih aplikacij jeDjango [20], ki ga predstavljamo v nadaljevanju. Gledano s strani objave konˇcne aplikacije, pa je pomemben tudi pristop razvoja. Tu se vse veˇc uporablja kontejnerizacija aplikacij, kjer je najveˇckrat uporabljeno orodje Docker [21] in bo prav tako predstavljeno v nadaljevanju.
2.2.2.1 Django - paket za izdelavo spletnih strani
Django [20] je eden izmed najbolj popularnih paketov za izdelavo spletnih strani in apli-kacij, ki sta ga zaˇcela razvijati S. Willison in A. Holovaty leta 2003. Ker je v celoti na-pisan v programskem jeziku Python, je hitro pridobil na popularnosti in ustvarila se je zelo moˇcna odprtokodna skupnost. Redne posodobitve, dodajanje novih funkcij in do-bra dokumentacija [22] je vodila do velike razˇsirjenosti. Kot podlaga za razvoj spletnih aplikacij ga uporabljajo nekatera veˇcja podjetja kot so Instagram, Mozilla, Bitbucket ... Omogoˇca hiter in uˇcinkovit razvoj spletnih aplikacij, je varen, skalabilen in primeren
Teoretiˇcne osnove in pregled literature
za vrsto razliˇcnih aplikacij; od enostavnih spletnih strani, socialnih omreˇzji, znanstve-nih raˇcunskih aplikacij itd. Zaradi svoje razˇsirjenosti in hitro rastoˇcega programskega jezika Python imamo na voljo tudi ˇstevilne knjiˇzice, ki omogoˇcajo razˇsiritev njegove funkcionalnosti za bolj kompleksne aplikacije. Dve izmed bolj popularnih razˇsiritvenih knjiˇzic razviti posebej za Django paket, sta Django REST framework [23] za iz-delavo aplikacijskih programskih vmesnikov (API) in Django Channels [24], ki nam omogoˇca implementacijo asinhronih protokolov v aplikacijo. Slednjega smo uporabili v naˇsi aplikaciji in bo nekoliko podrobneje opisan v nadaljevanju.
Osnovna struktura Django
Osnovna enota spletne aplikacije ustvarjene s pomoˇcjo paketa Django je projekt, ki ga sestavljajo ena ali veˇc aplikacij, kot je vidno na shemi 2.6.
Django
Slika 2.6: Sestava spletne aplikacije izdelane z Django paketom [25].
Aplikacija znotraj projekta je samostojen del, ki naj bi opravljal eno nalogo celotnega projekta. Osnovna ideja za aplikacijami je njihova modularnost in da jih lahko znova uporabimo v drugih projektih, Django pa ˇze vkljuˇcuje nekaj aplikacij (te so na 2.6 poimenovane Django aplikacije). Te so recimo admin panel, sistem za autentifikacijo, upravljanje s statiˇcnimi datotekami, sejo, predpomnilnikom itd.
Gledano s strani arhitekture naˇcin delovanja spletne aplikacije izdelane s pomoˇcjo Django paketa opiˇsemo kot model-predloga-pogled (ang. Model-Template-View oz.
MTV). To prikazuje shema 2.7.
Na shemi 2.7 so prikazane komponente in dve regiji (stran streˇznika in stran odjemalca).
Django paket vkljuˇcuje komponente: Model, ki komunicira s podatkovno bazo, pogled, ki vrne odgovor oziroma prikaz in logiko aplikacije, ki opravlja ˇse druge naloge glede na zahtevek (npr. avtentifikacijo uporabnikov). Vse komponente sprogramiramo sami glede na zahteve in strukturo spletne aplikacije. Ko odjemalec preko brskalnika, ki prikazuje predlogo, poˇslje zahtevek, je ta poslan na stran streˇznika in obdelan v logiki pogleda (ang. view). Ta nato preko modela pridobi ustrezne podatke in vrne odgovor.
12
Teoretiˇcne osnove in pregled literature
Django Predloga
Stran odjemalca Stran strežnika
Logika Aplikacije
Model Logika Pogleda
Strežnik
Slika 2.7: Princip delovanja Django paketa.
Za pravilno usmerjanje URL poti, poskrbi Django sam po sebi. Django paket v osnovi implementira HTTP protokol oz. cikel zahtevek/odgovor 2.8. V kontrastu s prej omenjeno shemo, shema 2.9 prikazuje nadgradnjo osnovnega Django paketa s paketom Channels, ki bo predstavljen v nadaljevanju.
Spletni brskalnik
Funkcija pogleda
Spletni strežnik
HttpZahtevek HttpOdgovor
HTTPPython API
Slika 2.8: Osnovna funkcija Django paketa - implementacija HTTP protokola.
Django Channels
Uporaba knjiˇzice Channels [24] omogoˇci, da Django projekt ne podpira le HTTP proto-kola, temveˇc tudi protokole, ki zahtevajo dlje odprte povezave npr. WebSocket, MQTT ... Knjiˇzica je zgrajena na osnovi Python standarda ASGI [26]. Tako lahko v naˇsem projektu uporabimo kombinacijo sinhronih in asinhronih procesov. Za laˇzjo predstavo, kako se spremeni delovanje Django paketa, si lahko pogledamo shemo 2.9.
Teoretiˇcne osnove in pregled literature
Spletni brskalnik
Porabnik (HTTP)
Spletni/WebSocket strežnik
Plast kanala
Http sporočilo WebSocket sporočilo
Vmesniški strežnik
HttpZahtevek
HttpOdgovor
Funkcija pogleda Porabnik
(WebSocket) Procesi v ozadju
Proces delavca
HTTP Python API WebSocket Channels (ASGI)
Slika 2.9: Nadgradnja Django paketa s paketom Channels, ki omogoˇca poleg HTTP ˇse implementacijo WebSocket protokola.
Channels in ASGI razdelita prihajajoˇce povezave na dve komponenti: obseg (ang.
scope) in niz dogodkov (ang. events). Obseg je zbirka dogodkov o prihajajoˇci pove-zavi, kot je recimo pot, od kjer je bil poslan zahtevek, IP naslov WebSocketa ali ime uporabnika. Pri HTTP protokolu obseg traja le ˇcas enega zahtevka, pri WebSocket pa dokler povezava ni zaprta. Med ˇzivljenjsko dobo obsega se pojavi niz dogodkov, pri HTTP protokolu je to le sporoˇcilo z zahtevkom in odgovor, pri WebSocket pa vsi poslani in prejeti paketi s podatki, dokler se povezava ne zapre.
Osnovni sestavni del Channelsov, ki je omenjen tudi na shemi, je porabnik (ang. con-sumer). Lahko si ga predstavljamo kot majhno aplikacijo, ki upravlja z dogodki. Ko je zahtevek za povezavo prejet, Channels sledi definirani usmeritvi, najde ustreznega porabnika (ang. consumer) zahtevane povezave in zaˇzene novo kopijo le-tega. Porab-niki so torej dlje ˇziveˇci in mi skozi kodo definiramo, kako naj upravljajo z dogodki, Channels pa poskrbi, da teˇcejo ob ustreznem ˇcasu in da jih lahko vzporedno teˇce veˇc.
14
Teoretiˇcne osnove in pregled literature ˇSe eden zelo pomemben sestavni del aplikacije so tako imenovane plasti kanala (ang.
channel layer) kot je prikazano na 2.9. Te nam omogoˇcajo, da razliˇcne instance aplika-cije komunicirajo med seboj. Za primer recimo, da ˇzelimo v aplikaciji implementirati klepet. V tem primeru bo vsak uporabnik ob prijavi odprl svojo instanco aplikacije. Da bi lahko vsi uporabniki prejemali sporoˇcila, bi teoretiˇcno morali sporoˇcila shranjevati v podatkovno bazo in jih nato priklicati. Reˇsitev tega so plasti kanala, ki poskrbijo za distribucijo sporoˇcil med prijavljenimi uporabniki v realnem ˇcasu. Dodatno so lahko plasti kanala uporabljene tudi za dodatne delovne procese ali izvajanj nalog v ozadju.
S strani Djanga je Redis [27] trenutno edini podprti ponudnik plasti kanala in bo na kratko opisan v naslednjem odstavku.
Redis
Redis [27] (ang. Remote Dictionary Server) je odprtokodno orodje za shrambo podat-kovne strukture v pomnilnik in se lahko uporablja kot podatkovna baza predpomnilnika ali posrednika sporoˇcil. Ponuja nam uporabo struktur kot so nizi, seznami, mnoˇzice, slovarji itd. Posebnost Redisa je, da shranjuje nabor podatkov v raˇcunalniˇski spo-min. Poslediˇcno je njegov odzivni ˇcas pod milisekundo, kar omogoˇca obdelavo veˇc milijonov zahtevkov na sekundo in je idealna izbira zareal-time aplikacije na razliˇcnih podroˇcjih kot so IoT, finance, tehnologij in igraˇcarstvo. Za uporabo je na voljo v veˇcini programskih jezikov.
V naˇsi aplikaciji smo ga v Django Channels vkljuˇcili s pomoˇcjo knjiˇzicechannels redis.
Kot ˇze zgoraj omenjeno, je njegova naloga v naˇsi aplikaciji, da sluˇzi kot plast kanala.
Enostavneje povedano, opravlja funkcijo posrednika sporoˇcil, kot to podobno poˇcne po-srednik pri MQTT protokolu, katerega smo podrobneje opisali v poglavju 2.2.1.1MQTT protokol. Redis torej poskrbi za komunikacijo med razliˇcnimi instancami aplikacije. Ko poˇsljemo neko sporoˇcilo, je to prejeto na strani drugih porabnikov, ki posluˇsajo na istem kanalu.
2.2.2.2 Kontejnerizacija aplikacije
Docker [21] je platforma za izvajanje aplikacij v lahkih enotah imenovanih kontejnerji (ang. containers). Kako poteka delo s kontejnerji in na kakˇsen naˇcin se uporablja platforma Docker, smo si razjasnili po knjigi avtorja E. Stonemana [28].
Tako imenovani kontejnerji so se zaˇceli uporabljati na razliˇcnih podroˇcjih razvoja pro-gramske opreme, od razliˇcnih aplikacij v oblaku, do zasebne uporabe v podjetjih. Zna-nje Dockerja, ki je najbolj razˇsirjena platforma za kontejnerizacijo, je postalo kljuˇcno za razvijalce, ki se ukvarjajo z razvojem spletnih aplikacij. Kljuˇcna lastnost kontejne-rizacije aplikacije je prenosnost, kar pomeni, da ni razlike med izvajanjem aplikacije v razvojnih fazah na lokalnem raˇcunalniku in med izvajanjem aplikacije v produkcijskem okolju v oblaku. S tem se poenostavi razvoj, saj smo neodvisni od operacijskega sistema in konfiguracije programske opreme, ki jo ima posameznik oziroma ponudnik oblaka.
Druga dobra lastnost je, da vsak gradnik aplikacije operira v kontejnerju. Te skupaj povezuje virtualno omreˇzje in tako lahko med seboj komunicirajo ne da bi bili izpo-stavljeni zunanjemu okolju gostujoˇcega operacijskega sistema. To omogoˇci, da lahko strateˇsko posodabljamo in testiramo posamezne dele aplikacije, jih odstranjujemo in dodajamo. Vsak del aplikacije je definiran v Dockerfile datoteki, povezava celotne
Teoretiˇcne osnove in pregled literature
aplikacje pa v Docker Compose datoteki. Ne glede na to, kateri programski jezik uporablja doloˇcen del aplikacije ali katero tehnologijo uporabljajo naˇse podatkovne baze, razvijalec na svoj sistem namesti Docker, klonira izvorno kodo za postavitev kontejnerjev in zgradi ter zaˇzene celotno aplikacijo z enim ukazom. Za laˇzjo predstavo, kako veˇckontejnerizacija poteka, si lahko ogledamo shemo 2.10.
Računalnik
Slika 2.10: Veˇc kontejnerjev na enemu raˇcunalniku si delijo isti operacijski sistem in raˇcunalniˇske vire [28].
Kontejner si lahko predstavljamo kot zaboj, ki vsebuje aplikacijo. V zaboju ima apli-kacija raˇcunalnik na videz zase. Ima svoje ime, IP naslov in svoj disk. Vse to so le virtualni viri, ki jih ustvari Docker. Virtualni viri, so torej logiˇcni objekti upravljani s strani Dockerja in skupaj tvorijo okolje, kjer lahko aplikacija operira.
Aplikacija znotraj zaboja ne vidi izven njega. Zaboj pa operira na raˇcunalniku, ki lahko poganja veˇc takih zabojev. Aplikacije imajo torej svoja loˇcena okolja vendar si vse de-lijo procesor, spomin in operacijski sistem gostujoˇcega raˇcunalnika. V raˇcunalniˇstvu in informatiki se velikokrat sreˇcujemo z dvema problemoma: izolacijo in gostoto. Sle-dnja pomeni, da lahko na raˇcunalniku izvajamo kar se da veliko ˇstevilo aplikacij, da izkoristimo vire, ki so na voljo. Problem tu je, da v praksi velikokrat pride do kriˇzanja verzij knjiˇzic, ki jih razliˇcne aplikacije potrebujejo za pravilno delovanje. Zato je tu tako pomembna tudi izolacija. V preteklosti se je to reˇsevalo z postavitvijo virtual-nih operacijskih sistemov, kar pa je bilo z vidika procesorske moˇci precej potratno in neuˇcinkovito. Kontejner uporablja le operacijski sistem gostujoˇcega raˇcunalnika, kar ga naredi izjemno lahkega in uˇcinkovitega. Kontejnerji se zaˇzenejo hitro in obratujejo lahkotno, torej je mogoˇce na sistemu poganjati veliko veˇc kontejnerjev kot virtualnih operacijskih sistemov. Kontejnerizacija torej reˇsuje oba problema: izolacijo in gostoto.
16
Teoretiˇcne osnove in pregled literature
2.2.3 Asinhrono programiranje
V naˇsem primeru se ukvarjamo s pretakanjem velike koliˇcine podatkov, saj ˇzelimo podatke zajemati s frekvenco vzorˇcenja do 192kHz in razmeroma visoko dinamiˇcno globino AD pretvorbe (16-bitno ali 24-bitno). Da lahko to doseˇzemo z uporabo pro-gramskega jezika Python, ki sam po sebi ni najhitrejˇsi, je potrebno uporabiti primerna orodja, ustrezne knjiˇzice in naˇcin programiranja. Poleg tega naˇsa aplikacija zahteva ˇse druge funkcionalnosti, kot so istoˇcasno izvajanje procesiranje signalov, prikazovanje podatkov veˇcim uporabnikom hkrati in upravljanje z enoto za zajemanje med tem, ko se meritve izvajajo. Na podlagi teh zahtev in omejitev smo se odloˇcili, da bomo precejˇsen del programa za zajemanje napisali na asinhron naˇcin.
V nadaljevanju bo v grobem predstavljeno asinhrono programiranje in kako se to razlikuje od bolj pogosto uporabljenega sinhronega programiranja. Velik del kode je napisane v programskem jeziku Python, za asinhrone operacije pa njegov vgrajeni modul Asyncio [29]. pri razumevanju tega ter njegove uporabe, smo si pomagali s knjigo avtorja C. Hattingh [30].
2.2.3.1 Primerjava sinhronega in asinhronega programiranja
Pri klasiˇcnemu programiranju se operacijska opravila izvajajo sinhrono oziroma eno za drugim. Z drugimi besedami, vedno moramo ˇcakati, da se trenutno opravilo zakljuˇci, da lahko zaˇcnemo z izvajanjem naslednjega. Za razliko od tega, se lahko pri asinhronemu
Pri klasiˇcnemu programiranju se operacijska opravila izvajajo sinhrono oziroma eno za drugim. Z drugimi besedami, vedno moramo ˇcakati, da se trenutno opravilo zakljuˇci, da lahko zaˇcnemo z izvajanjem naslednjega. Za razliko od tega, se lahko pri asinhronemu