Vplyv komunikačného rozhrania na kvalitu internetového monitorovania činnosti agregátov

Vplyv komunikačného rozhrania na kvalitu internetového monitorovania činnosti agregátov

Pavel Horovčák

Príspevok sa zaoberá hodnotením vplyvov získavania a prenosu meraných hodnôt cez internet na kvalitu procesu monitorovania činnosti agregátov pri rôznych spôsoboch implementácie komunikačného rozhrania. V príspevku je porovnaná implementácia komunikačného rozhrania vo forme súborovej štruktúry a vo forme komunikácie TCP/IP. Je porovnaný vplyv dôb oneskorení pri rôznych podmienkach monitorovania na strane zberu, ako aj na strane klientského počítača. Sú diskutované možnosti monitorovania technologických údajov vzhľadom na ich meranie. Z experimentov vyplýva, že spotreba času na prenos meranej hodnoty v režime TCP je takmer vždy vyššia ako v režime súborovej štruktúry typu INI. V prípade moderných počítačov a rýchlej siete (100 Mb/s) sa pomer týchto dôb mení od 1 : 1 až po 14 : 1 (komunikácia typu INI je štrnásťkrát rýchlejšia ako komunikácia TCP).

1. Úvod

Pri hodnotení kvality procesu monitorovania činnosti agregátov s využitím internetu (teda vlastne rýchlosti a presnosti – v zmysle periódy vzorkovania – procesu komunikácie medzi aplikáciou zberu monitorovaných údajov, dátovým serverom a internetovým klientom) je potrebné uvažovať niekoľko faktorov kvality [6]. Tieto faktory možno podľa miesta ich vzniku rozdeliť na tri skupiny.

Do prvej skupiny možno zaradiť zaťaženie počítača vykonávajúceho zber monitorovaných údajov (počet bežiacich úloh, čerpanie zdrojov systému) a rýchlosť prenosu komunikačného rozhrania medzi počítačom zberu a počítačom dátového servera.

Do druhej skupiny patrí zaťaženie počítača dátového servera, ktoré ovplyvňuje časovú presnosť vysielania vzoriek signálu smerom na klienta. Na zaťaženie servera majú vplyv vnútorné a vonkajšie faktory. Vnútorné faktory reflektujú aktuálnu situáciu na serverovom počítači, ako je počet bežiacich úloh a čerpanie jednotlivých zdrojov systému. Vplyv vonkajších faktorov reprezentuje počet klientov súčasne pripojených k serveru a monitorujúcich daný technologický proces. Ďalej sa tu uplatňuje vplyv pripojenia viacerých zdrojov zberu monitorovaných údajov, teda v tomto zmysle tiež klientov dátového servera v smere k zberu dát.

Do tretej skupiny faktorov patrí rýchlosť prenosu v sieti medzi dátovým serverom a klientom plus analogicky okamžitá situácia (počet bežiacich úloh, čerpanie zdrojov) na lokálnom počítači, kde beží klient [5]. Distribúcia zložiek www monitorovania je znázornená na obr. 1.

2. Hodnotenie kvality monitorovania

Pre účely hodnotenia kvality monitorovania prostredníctvom internetu bola aplikácia zberu upravená tak, že do komunikačného rozhrania zapisuje iba čas zberu signálu (a z neho len sekundy a milisekundy – Delphi ukladá dátum a čas do typu TdateTime, ktorý je typu double, pričom jeho celá časť udáva počet dní od 30. 12. 1899, desatinná časť udáva čas dňa), ktorý sa mení v zmysle periódy vzorkovania aplikácie zberu (obr. 2)

hod:=frac(time*24*60)*60.0;
// na sekundy a milisekundy (1)

Aplikácia dátový server číta z komunikačného rozhrania nameranú hodnotu, zapisuje ju do soketu a pridáva k nej aktuálny čas jej vyslania z dátového servera. Tento čas je vysielaný na pomocnom kanáli číslo 9 a je generovaný analogickým spôsobom ako v aplikácii zberu (1).

Aplikácia klienta prijíma v rámci soketovej komunikácie tieto dve hodnoty a pre účely vyhodnotenia generuje aktuálny čas ich prijatia, tiež len sekundy a milisekundy:

cas:=System.currentTimeMillis();
// systemovy cas v ms
caspom:=(cas % (1000*60))/1000.0;
// iba s a ms, udaj v s (2)

Pre účely testovania kvality prenosu a vplyvu sieťových faktorov na priebeh monitorovania je prijímaný signál (hodnota času, t. j. sekundy a milisekundy) na strane klienta transformovaný z reťazca na číselný tvar

hodv[i]:=Double.valueOf(ret[i]).doubleValue();
// prijata hodnota zo servera [s]

kde ret je prijatá hodnota (reťazec) vyslaná z dátového servera a hodv je prevod na double. Priebeh monitorovaného signálu je zobrazovaný ako prvý graf (obr. 2) a označený textom monitorovany priebeh (hodv[0]).

Kvalitu monitorovania signálu je možné hodnotiť z hľadiska presnosti dodržania zadanej periódy vzorkovania a z hľadiska oneskorenia signálu na jednotlivých úsekoch jeho cesty na klientský počítač.

Dodržanie zadanej periódy vzorkovania je hodnotené na strane aplikácie zberu a na strane dátového servera, v oboch prípadoch vzhľadom na periódu vzorkovania dátového servera.

Dodržanie periódy vzorkovania na strane aplikácie zberu je dané porovnaním dvoch po sebe nasledujúcich hodnôt signálu vyslaného aplikáciou zberu a periódy vzorkovania podľa príkazu

hodv[1]:=hodv[0]–hodv[1]–dt;
// presnost zberu dat e_zb (3)

kde hodv[0] je aktuálny čas merania, hodv[1] predstavuje predchádzajúci čas merania a dt je perióda vzorkovania na strane dátového servera. Priebeh nepresnosti vysielania aplikácie zberu je zobrazovaný ako druhý graf označený presnost vzorkovania zberu dat e_zb.

Kvalitu dátového servera vyjadruje presnosť dodržania zadanej periódy vzorkovania na strane servera. Ide o jeho vysielanie v správnom čase a zohľadňuje sa tým okamžitá situácia na serverovom počítači ako aj vplyv počtu pripojených klientských počítačov (popr. počtu jednotlivých aplikácií zberu). Hodnotenie je založené na porovnaní dvoch po sebe nasledujúcich prijatých hodnôt signálu vyslaného dátovým serverom (t. j. hodv[9] a starej hodnoty hodv[2]) so zadanou periódou vzorkovania (dt) podľa príkazu

hodv[2]:=hodv[9]–hodv[2]–dt;
// presnost casoveho
vysielania servera (4)

Priebeh nepresnosti vysielania servera je zobrazovaný ako tretí graf a označený presnost vzorkovania datoveho servera e_ds.

Presnosť prijímania vzoriek vzhľadom na zadanú periódu vzorkovania na strane klienta je možné vyjadriť analogickým spôsobom. Nakoľko jej vplyv je zanedbateľný [3], upustili sme od jej grafickej prezentácie v podobe grafu.

Určenie trvania prenosu medzi serverom a klientom je podmienené synchronizáciou systémového času servera a klienta. Túto synchronizáciu možno zabezpečiť napr. pomocou aplikácie AboutTime [4], ktorá získava aktuálnu hodnotu času z internetu a nastavuje počítačový čas s presnosťou do 50 ms, v prípade iného protokolu ako SNTP (Simple Network Time Protocol) s presnosťou 1 s. Môže slúžiť ako server aj ako klient a pracovať so štyrmi protokolmi: Daytime/TCP – port 13, Time/TCP – port 37, Time/UDP – port 37 a SNTP – port 123.

Oneskorenie signálu je hodnotené na úseku zber – dátový server, na úseku dátový server – klient a nakoniec celkové ako súčet oboch.

Oneskorenie na prvom úseku je definované ako rozdiel času merania a času vysielania signálu z dátového servera podľa príkazu

hodv[3]:=hodv[9]-hodv[0];
// oneskorenie
dat.server – zber e_dz (5)

Priebeh oneskorenia na prvom úseku medzi dátovým serverom a zberom je zobrazovaný ako štvrtý graf a označený textom oneskorenie datovy server – zber e_dz.

Oneskorenie na druhom úseku je definované ako rozdiel systémového času klienta a času vysielania signálu z dátového servera a počíta sa podľa príkazu

hodv[4]:=caspom-hodv[9];
// oneskorenie klient
dat.server e_kd (6)

kde caspom je systémový čas klienta, hodv[9] je čas vysielania signálu na dátovom serveri. Priebeh trvania prenosu paketov medzi serverom a klientom je zobrazovaný ako štvrtý graf a označený textom oneskorenie klient – datovy server e_kd.

Celkové oneskorenie monitorovaného signálu na klientovi vzhľadom na zber je dané rozdielom času vzniku a príchodu signálu na klienta

hodv[5]:=caspom-hodv[0];
// oneskorenie
klient zber e_kz (7)

Priebeh oneskorenia medzi aplikáciou zberu a serverom je zobrazovaný ako piaty graf a označený textom oneskorenie klient – zber e_kz.

Grafy druhý až piaty by teoreticky v ideálnom prípade boli tvorené nulovým priebehom, v skutočnosti sú tvorené viac alebo menej náhodnými priebehmi, ktoré sa v istých časových úsekoch môžu týmto ideálnym priebehom približovať, inokedy nastáva značný rozkmit priebehu, čo poukazuje na zníženie kvality prenosu signálu, a teda monitorovaného priebehu.

Tab. 2. Porovnanie priemerných oneskorení klient – zber pre podmienky monitorovania B (ms)

3. Implementácia komunikačného rozhrania v tvare súborovej štruktúry

Komunikačné rozhranie v tvare súborovej štruktúry môže byť realizované dvoma spôsobmi. Prvý spôsob predstavuje využitie súborov typu .INI, druhý spôsob využitie štandardných súborov. Využitie súborovej štruktúry spočíva v zápise odpovedajúcich hodnôt aplikáciou zberu do súboru a v následnom čítaní nameraných hodnôt aplikáciou dátového servera. Súbory typu .INI sú obyčajné textové súbory. Ich hlavným využitím je uchovávanie konfiguračných informácií. Informácie sú v týchto súboroch uchovávané v logických skupinách, nazývaných sekcie. Názvy sekcií sú uvádzané v hranatých zátvorkách. V rámci sekcie sú aktuálne údaje ukladané v tvare pomenovaných kľúčov. Kľúč má tvar <meno kľúča> = <hodnota>. Delphi poskytuje celý rad vlastností a metód, ktoré podstatným spôsobom zjednodušujú zápis, čítanie a manipuláciu so súbormi .INI (8 + 15 metód). Stručne možno charakterizovať prednosti práce so súbormi .INI jednoduchosťou obsluhy, prehľadnosťou zápisu a možnosťou uchovávania viacerých meraných alebo monitorovaných veličín (dôsledok použitia pomenovaných kľúčov).

Štandardné súbory je možné využiť v každom programovacom či vývojovom prostredí. Ich rýchlosť je obyčajne vyššia ako v prípade využitia databázového systému, čo je ich podstatnou prednosťou. K istým nevýhodám ich použitia patrí zvýšená náročnosť pri programovaní, potreba synchronizácie v prípade viacerých procesov a využitie najvhodnejších štandardných funkcií pri práci so súborom, ktoré môže podstatne zrýchliť alebo spomaliť výmenu informácií medzi komunikujúcimi subjektami.

Pri práci so súborom je možné pre zápis meranej hodnoty využiť dva postupy. Prvý postup zapisuje jedinú (vždy poslednú) nameranú hodnotu, ktorá sa následne prečíta. Tento postup je plne vyhovujúci a dostatočne rýchly [2]. Druhý postup zapisuje do súboru postupne všetky merané hodnoty, pričom pre účely ďalšieho spracovania sa vyberá vždy posledná nameraná hodnota. Takto sa do súboru dostane vlastne celý monitorovaný priebeh, čo umožní prípadné neskoršie prezeranie off-line. To možno pokladať za výhodu takéhoto prístupu. Podstatnou nevýhodou tohto postupu je narastajúca pomalosť, ktorá sa s rastúcim počtom nameraných hodnôt zvyšuje exponenciálne, ako je to znázornené na obr. 3. Údaje boli získané v zostave Pentium MMX 166 MHz, 32 MB RAM, operačný systém Windows NT 4.0, pričom bol využitý mechanizmus súborov typu .INI. Na základe skúseností možno očakávať podobný priebeh nárastu doby čítania poslednej hodnoty aj v prípade štandardných súborov.

Vo všetkých uvedených prípadoch je možné monitorovať jeden alebo viacej sledovaných priebehov technologického procesu.

4. Implementácia komunikačného rozhrania vo forme aplikácie TCP/IP

Komunikačné rozhranie vo forme aplikácie TCP/IP prestavuje moderný spôsob komunikácie dvoch alebo viacerých aplikácií, ktorý môže prebiehať aj v prostredí rôznych operačných systémov. Implementácia TCP/IP je založená na vytvorení soketovej komunikácie medzi všetkými navzájom komunikujúcimi aplikáciami. Soketová komunikácia umožňuje komunikovať s iným systémom na báze protokolu TCP/IP a príbuzných protokolov. Pomocou soketov je možné čítať a zapisovať cez prepojenie do iného počítača bez ohľadu na detaily aktuálneho sieťového softvéru. Sokety poskytujú prepojenie na báze protokolu TCP/IP, ale sú dostatočne univerzálne aj pre prácu s inými príbuznými protokolmi.

Pre komunikáciu medzi aplikáciou zberu a aplikáciou dátového servera bolo zvolené vývojové prostredie Delphi. Serverová časť komunikácie je realizovaná v aplikácii dátového servera, klientská časť v aplikácii zberu. Tento prístup umožní pripojiť viacero aplikácií zberu, a teda monitorovať viacero technologických procesov alebo agregátov s využitím toho istého dátového servera. Soketová komunikácia je implementovaná s využitím štandardných komponentov knižnice VCL (Visual Component Library) TServerSocket a TClientSocket.IP je založená na vytvorení soketovej komunikácie medzi všetkými navzájom komunikujúcimi aplikáciami. Soketová komunikácia umožňuje komunikovať s iným systémom na báze protokolu TCP/IP a príbuzných protokolov. Pomocou soketov je možné čítať a zapisovať cez prepojenie do iného počítača bez ohľadu na detaily aktuálneho sieťového softvéru. Sokety poskytujú prepojenie na báze protokolu TCP/IP, ale sú dostatočne univerzálne aj pre prácu s inými príbuznými protokolmi. Obe aplikácie môžu navzájom komunikovať obojsmerne, pričom hlavný tok dát predstavuje prenos monitorovaných údajov z aplikácie zberu do aplikácie dátového servera. V opačnom smere sú prenášané iba riadiace informácie. Aplikácia zberu využíva komponent Obe aplikácie môžu navzájom komunikovať obojsmerne, pričom hlavný tok dát predstavuje prenos monitorovaných údajov z aplikácie zberu do aplikácie dátového servera. V opačnom smere sú prenášané iba riadiace informácie. Aplikácia zberu využíva komponent konkrétne jeho metódu Socket.SendText pre vysielanie monitorovaných hodnôt, a metódu Socket.ReceiveText pre príjem riadiacej informácie z dátového servera. Aplikácia dátového servera pracuje s komponentom TServerSocket v troch režimoch. V prvom číta monitorovanú hodnotu z aplikácie zberu pomocou metódy Socket.ReceiveText, v druhom nadväzuje spojenie s klientom zberu pomocou metódy Socket.SocketHandle a vysiela späť riadiacu informáciu pomocou metódy Socket.SendText. V treťom režime sa uskutočňuje „upratovanie“ pri odpojení klienta zberu tiež pomocou metódy Socket.SocketHandle. Okrem toho je v aplikácii dátového servera sledovaný celkový počet klientov zberu pomocou metódy Socket.ActiveConnections. Podobným spôsobom je v aplikácii dátového servera riešená aj komunikácia s internetovým klientom, takže táto aplikácia pracuje s dvoma komponentami TserverSocket. Jeden je určený na obsluhu klientov zberu a druhý na obsluhu klientov monitorovania. Ukážka „dispečerskej obrazovky“ aplikácie dátového servera pre dvoch klientov zberu a piatich klientov monitorovania je znázornená na obr. 4. Každá aplikácia zberu vysiela svoj vlastný monitorovaný priebeh, z ktorých si aplikácia klienta monitorovania môže vybrať požadovaný priebeh. V súčasnosti sú vysielané všetky monitorované priebehy na klientov, výber požadovaného priebehu na strane klienta je potrebné ešte dopracovať.

Tab. 3. Porovnanie priemerných oneskorení klient – zber pre podmienky monitorovania B (ms)

5. Hodnotenie prenosových dôb

Hodnotenie prenosových dôb a tým kvality monitorovania [1] pri jednotlivých podmienkach bolo realizované voľbou kritéria maximálnych a priemerných hodnôt jednotlivých priebehov týchto dôb za dostatočne dlhú dobu. Za dostatočne dlhú dobu bola považovaná doba okolo 60 sekúnd. Rozsah časovej osi grafov je 60 sekúnd, hodnota času od začiatku monitorovania je uvedená pred začiatkom časovej osi. Pre vybrané podmienky monitorovania bolo vykonané porovnanie hodnotenia cez kritérium maximálnych a priemerných hodnôt. Podmienky monitorovania boli:

• A – všetky tri aplikácie (aplikácia zberu, dátového servera a klienta) pracujú na rovnakom počítači (procesor Pentium MMX 166 MHz, 64 MB RAM, Microsoft Windows 98).

• B – aplikácia zberu pracuje na jednom počítači (procesor Pentium 166 MHz, 64 MB RAM, Microsoft Windows 2000), aplikácia dátového servera a klienta na druhom počítači (procesor Celeron 850 MHz, 512 MB RAM, Microsoft Windows 2000). Synchronizácia systémových časov oboch počítačov je zabezpečená pomocou programu AboutTime.

Porovnávané sú hodnoty priemerných a maximálnych oneskorení získané pri realizácii komunikačného rozhrania vo forme TCP/IP a vo forme súborov .INI. Periódy vzorkovania na strane aplikácie zberu boli dzb = 1; 5; 10; 20; 50; 100; 200; 500; 1 000; 2 000 a 5 000 ms, periódy vzorkovania aplikácie dátového servera dds = 10; 100; 200; 500; 1 000; 2 000 a 5 000 ms. Hodnotenie prenosových dôb je vykonané pre podmienky monitorovania A, pretože tu sa neuplatňuje vplyv premenlivého zaťaženia siete. Možno však konštatovať, že priebehy jednotlivých sledovaných faktorov pre podmienky monitorovania A aj B majú takmer identický charakter.

5.1 Presnosť zberu
TCP/IP: Kritérium priemerných hodnôt – nepresnosti sa pohybujú asi od 10 po 100 ms, kritérium maximálnych hodnôt – nepresnosti sú od 100 do 5 000 ms.

INI: Kritérium priemerných hodnôt – nepresnosti sa pohybujú asi od 10 po 200 ms, kritérium maximálnych hodnôt – nepresnosti sú od 50 do 6 000 ms.

Celkové hodnotenie: súbory priemerných aj maximálnych hodnôt sú veľmi podobné, nepresnosti v prípade priemerných hodnôt sú takmer rovnaké, v prípade maximálnych hodnôt v niektorých prípadoch (dds = 1 000, 2 000 ms) boli hodnoty pre TCP približne dvakrát väčšie ako pre INI.

Tab. 4. Porovnanie maximálnych oneskorení klient – zber pre podmienky monitorovania A (ms)

5.2 Presnosť dátového servera
TCP/IP: Kritérium priemerných hodnôt – nepresnosti sa pohybujú asi od 9 po 110 ms, kritérium maximálnych hodnôt – nepresnosti sú od 50 do 210 ms.

INI: Kritérium priemerných hodnôt – nepresnosti sa pohybujú asi od 10 po 60 ms, kritérium maximálnych hodnôt – nepresnosti sú od 40 do 590 ms.

Celkové hodnotenie: podobne ako v prípade presnosti zberu možno hodnotiť súbory priemerných aj maximálnych hodnôt ako veľmi podobné, nepresnosti v oboch prípadoch sú takmer rovnaké.

5.3 Doba prenosu zber – dátový server
TCP/IP: Kritérium priemerných hodnôt – nepresnosti sa pohybujú asi od 80 po 3 600 ms, kritérium maximálnych hodnôt – nepresnosti sú od 110 do 6 860 ms.

INI: Kritérium priemerných hodnôt – nepresnosti sa pohybujú asi od 45 po 2 750 ms, kritérium maximálnych hodnôt – nepresnosti sú od 60 do 6 150 ms.

Celkové hodnotenie: priemerné hodnoty pre TCP sú vo väčšine prípadov väčšie ako pre INI, a to približne dvojnásobne. Podobne to platí aj pre maximálne hodnoty – hodnoty pre TCP a INI sú niekde rovnaké, niekde sú pre TCP až dvojnásobne väčšie.

5.4 Doba prenosu dátový server – klient
TCP/IP: Kritérium priemerných hodnôt – pre dds = 200 až 2 000 ms sa nepresnosti pohybujú asi od 0 po 18 ms, pre dds = 10 až 100 ms je to 90 až 125 ms, kritérium maximálnych hodnôt – pre dds = 200 až 2 000 ms je to 0 až 60 ms, pre dds = 10 až 100 ms je to 220 ms.

INI: Kritérium priemerných hodnôt – pre dds = 200 až 2 000 ms sú nepresnosti od 0 do 22 ms, pre dds = 10 až 100 ms je to 100 až 124 ms, kritérium maximálnych hodnôt – pre dds = 200 až 2 000 ms je to 0 až 60 ms, pre dds = 10 až 100 ms je to 220 ms.

Celkové hodnotenie: priemerné aj maximálne hodnoty pre TCP sú vo väčšine prípadov rovnaké ako pre INI.

5.5 Doba prenosu zber – klient
TCP/IP: Kritérium priemerných hodnôt – nepresnosti sa pohybujú asi od 60 po 3 140 ms, kritérium maximálnych hodnôt – nepresnosti sú od 110 do 6 860 ms.

INI: Kritérium priemerných hodnôt – nepresnosti sa pohybujú asi od 0 po 2 750 ms, kritérium maximálnych hodnôt – nepresnosti sú od 60 do 6 150 ms.

Celkové hodnotenie: priemerné hodnoty pre TCP sú vo väčšine prípadov väčšie ako pre komunikáciu INI.

Tab. 5. Porovnanie priemerných oneskorení klient – dátový server pre podmienky monitorovania A (ms)

6. Hodnotenie vplyvu komunikačného rozhrania

Na základe vysokého počtu vykonaných experimentov a ich vyhodnotenia je možné konštatovať, že na celkové oneskorenie monitorovaného signálu má vo všetkých prípadoch podstatný vplyv doba prenosu signálu medzi aplikáciou zberu a aplikáciou dátového servera. Toto oneskorenie je rádovo päť až dvadsaťkrát väčšie ako oneskorenie medzi aplikáciou dátového servera a klienta. Preto je opodstatnené sústrediť pozornosť na skúmanie mechanizmov prenosu medzi aplikáciou zberu a aplikáciou dátového servera.

Porovnávané boli dva komunikačné mechanizmy – prenos formou TCP s využitím soketovej komunikácie a prenos s využitím komunikácie cez súbor typu .INI. Z experimentov vyplýva, že spotreba času na prenos meranej veličiny vo forme TCP je takmer vždy väčšia ako u súborov typu .INI. V prípade kvalitných počítačov a rýchlej siete (100 Mb/s) sa ich pomer pohybuje od 1 : 1 až po 14 : 1.

Výhodou použitia TCP je možnosť zadania IP adresy (na ktorej pracuje aplikácia dátového servera) do aplikácie zberu. Tým je aplikácia zberu v podstate nezávislá od jej umiestnenia na sieti. Nevýhodou je väčšie časové oneskorenie meranej hodnoty v klientskej aplikácii.

Výhodou použitia súboru typu INI je vo väčšine prípadov vyššia rýchlosť spracovania ako pri TCP. Nevýhodou je nutnosť „konštantnej“ konfigurácie siete, v ktorej chceme experimentovať. Táto konfigurácia sa priamo premieta do cesty, kde je umiestnený súbor použitia. Cesta je zadaná v tvare \CompNameDisk_NameFolderData.ini, kde CompName je meno počítača v sieti, Disk_Name označenie disku, Folder označenie zložky a Data.ini označenie súboru typu .INI. Je samozrejmé, že v prípade zmeny počítača je nutná opätovná kompilácia aplikácie, čo je ďalšou nevýhodou použitia súboru typu .INI.

Tab. 6. Porovnanie priemerných oneskorení dátový server – zber pre podmienky monitorovania A (ms)

V tab. 3 sú tieňovaním vyznačené hodnoty oneskorenia väčšie ako periódy vzorkovania aplikácie zberu a aplikácie dátového servera, ktoré zhoršujú kvalitu procesu monitorovania. Je zrejmé, že pracovný rozsah je podstatne väčší pre komunikáciu cez súbory typu .INI ako pre komunikáciu TCP/IP. Dostávame sa tak k typickému protirečeniu: rýchlosť kontra univerzálnosť.

7. Záver

Obidva sledované postupy riešenia komunikačného rozhrania potvrdili svoju funkčnosť. Výhodou komunikácie TCP je jej univerzálnosť, ktorá umožňuje umiestniť aplikáciu zberu na hociktorý sieťový počítač. Jej nevýhodou je vyššia hodnota oneskorenia monitorovaného signálu. Výhodou komunikácie cez súbory typu .INI je jej podstatne vyššia rýchlosť, nevýhodou viazanosť skompilovanej aplikácie na konkrétne podmienky siete LAN. Preto je nevyhnutné, aby súbor typu .INI bol umiestnený na počítači, kde pracuje aplikácia dátového servera.

Jednou z perspektívnych možností zrýchlenia komunikácie TCP je využitie vlákien (threads). Osobitné vlákna na čítanie a zápis do soketov v aplikácii dátového servera môžu prispieť ku skráteniu režijných dôb spracovania jednotlivých konekcií.

Pozn.: Príspevok bol riešený v rámci grantu Sokrates Minerva 90511-CP-1-2001-UK-MINERVA-M.

Pavel Horovčák,
Technická univerzita v Košiciach,
Fakulta baníctva, ekológie, riadenia a geotechnológií,
katedra informatizácie a riadenia procesov
(Pavel.Horovcak@tuke.sk)

Lektoroval:
Ing. Zdeněk Bradáč, ÚAMT FEKT VUT