The Monitoring of a Group of Applications in a Local Area Network

(1)

TEKNILLINEN KORKEAKOULU Tietotekniikan osasto

Kai Kataja

Erään lähiverkon sovellusten valvonta

Diplomityö, joka on jätetty opinnäytteenä tarkastettavaksi diplomi-insinöörin tutkintoa varten Espoossa.

Työn valvoja:

professori Reijo Sulonen

(2)

TEKNILLINEN KORKEAKOULU DIPLOMITYÖN TIIVISTELMÄ

Tekijä ja työn nimi: Kai Kataja Erään lähiverkon sovellusten valvonta

Päivämäärä: 19. syyskuuta 1996 Sivumäärä: 94

Osasto: Tietotekniikan osasto Professuuri: Tik-76 Tietojenkäsittelyoppi Työn valvoja: professori Reijo Sulonen

Työn ohjaaja: -

Tässä diplomityössä suunnitellaan erääseen lähiverkkoon, hyperkanavaan, perustuvan tiedonsiirto-ohjelmiston valvontaohjelmisto. Ohjelmisto sisältää sekä reaaliaikaisen valvonnan että pidemmän ajan käytön tilastoinnin ja laskutuksen. Diplomityössä toteu

tetaan valvontaohjelmiston tiedonkemuosa ja kehitetään reaaliaikaisen valvontaohjelmiston prototyyppi.

Sovelluksen suunnittelussa on hyperkanavan erään tiedonsiirto-ohjelmiston, Netexin, istuntotason erilaisia tapahtumia käsitelty kuten viestejä älykkäässä postijärjestelmässä.

Erilaisista tapahtumaketjuista johdetaan istunnoille tarkka lajittelu. Valvonnan ja tilas

toinnin erilaiset taipeet saadaan esitettyä täsmällisesti hyödyntämällä johdettua istunto

jen lajittelua. Lisäksi tapahtumaketjujen jäsentely auttaa suunnittelemaan ohjelmiston tietorakenteet selkeiksi ja tarkoituksenmukaisiksi.

Sovellusten ydinosat on tehty käyttämällä kunkin sovelluksen ympäristöön sopivia työ

kaluja. Tiedonkeruuohjelmat on ohjelmoitu käyttöjärjestelmän ja käytettyjen verkko- ohjelmistojen käsittelyyn hyvin sopivalla C-ohjelmointikielellä. Valvontaohjelma, jonka käyttöliittymän sujuvuus on eräs ohjelmiston avainalueita, on graafinen ja valikko- ohjattu. Sen toteutus on tehty erityisen hyvin käyttöliittymien tekoon sopivalla sovellus- kehittimellä. Tilastointi-ja laskutusohjelmassa on käytetty apuna monipuolista tauluk

kolaskentaohjelmaa.

Tämän työn johdannossa perustellaan, miksi verkonvalvontaohjelmistoista ei sellaise

naan ole verkotettujen sovellusten valvojaksi. Lisäksi rajataan valvottava sovellusympä

ristö ja tapahtumat. Toisessa luvussa esitellään hyperkanavan ja sen erään istunto- ohjelmiston, Netexin, toimintaperiaatteet. Kolmannessa luvussa esitellään kehittämäni Netex-istuntojen luokittelujärjestelmä sekä pohditaan istuntoluokkia valvonta

järjestelmän ja tilastointijärjestelmän kannalta. Työn neljännessä luvussa esitellään toteutettu istuntojen valvonta- ja tilastointiohjelmisto. Viidennessä luvussa pohditaan ohjelmiston tulevaisuuden näkymiä, kuten lisäpiirteiden toteuttamista ja tapoja integroitua SNMP-valvontajärjestelmiin.

(3)

HELSINKI UNIVERSITY OF TECHNOLOGY ABSTRACT OF THE MASTER S THESIS

Author and name of the thesis: Kai Kataja

The Monitoring of a Group of Applications in a Local Area Network Date: September 19, 1996 Number of pages: 94 Faculty: The Department of Computer Science

Professorship: Tik-76 Computer Science Supervisor: Reijo Sulonen, Dr. Eng.

Instructor: -

Tliis thesis is focused on the development of a monitoring system for a group of applications in a Hyperchannel local area network. The monitoring system includes short and long terni accounting. The thesis contains the design and implementation of the data collection module and prototypes of the higher level accounting and monitoring systems.

Events and sequences of events in the proprietary session control software (Netex) are classified by considering them analogous to the message classes and acceptable

messaging sequences of an intelligent electronic mail system. Through this modeling system a session classifying system is born. This formal classification assists in the design of data structures and in selecting the right events to the right reports and displays of a complex monitoring system.

The applications are implemented using carefully selected tools. The data collection software is programmed using C because it is very efficient and has a natural interface to the low layers of the VMS operating system and the synchronizing features of the VAX processor family. Also the networking interface to the TCP/IP utilities is suitable for the C language. The monitoring system and its easy to use graphical user interface prototype are implemented using a higher level tool. The prototypes of the statistical modules are developed using a versatile spreadsheet application.

In the introduction of this thesis some reasons are given why a conventional network management system is not suitable for the monitoring of networked applications. Also the scope of this thesis is drawn. The second chapter introduces the Hyperchannel environment to the reader. The third chapter describes the classification system of the session types and discusses their use in monitoring and accounting. The fourth chapter describes the monitoring and accounting systems developed. In the fifth chapter future enhancements of the system are discussed. For example some ways to tie in with SNMP systems are considered.

(4)

Alkulause

Tämän diplomityön valvojana on toiminut professori Reijo Sulonen, jolle ha

luan esittää lämpimät kiitokseni saamistani hyvistä neuvoista ja ohjeista.

Kiitokset työtovereilleni ymmärtämyksestä diplomityön teon aikana ja työnan

tajilleni FD Finanssidata Oy:lle ja Helsingin Puhelin Oy:lle hyvien puitteiden jäijestämisestä.

Lisäksi tahdon kiittää lähimmäisiäni, erityisesti vaimoani Pia Katajaa, kärsivälli

syydestä ja kannustuksesta.

Helsingissä, 19. syyskuuta 1996

Kai Kataja

Laivapojankatu 3 C 50 00180 Helsinki

(5)

Sisällysluettelo

Kansilehti

Diplomityön tiivistelmä Alkulause

Sisällysluettelo Kuvaluettelo Taulukkoluettelo

Käytetyt merkinnät ja lyhenteet

1. Johdanto... 1

2. Hyperkanava ja Netex... 3

2.1. Mikä on hyperkanava?...3

2.2. Hyperkanavan fyysinen- ja siirtoyhteyskerros... 6

2.3. Netex-ohjelmisto...9

3. Istuntojen luokittelujärjestelmä...22

3.1. Istuntojen luokittelu... 22

3.2. Istunnon tunniste...27

3.3. Istunnot valvontajärjestelmän kannalta... 28

3.4. Istunnot tilastointijärjestelmän kannalta... 30

4. Istuntotason valvonta-ja tilastointiohjelmisto...32

4.1. Ohjelmiston toimintaympäristö... 32

4.2. Ohjelmiston osat...35

4.3. UX-funktiot...39

4.4. Tiedonkeruuohjelma...48

4.5. Valvontaohjelma...56

4.6. Tilastointiohjelma...58

5. Ohjelmiston tulevaisuuden näkymiä...61

5.1. SNMP-liittymä... 61

5.2. Hälytysten levitys...63

5.3. Käyttölaskutusliittymät... 63

5.4. Verkon virheiden analyysi... 65

6. Yhteenveto...66 Lähdeluettelo

Liitteet: Ohjelmalistaukset

ii

(6)

Kuvaluettelo

Kuva 1: Hyperkanavajärjestelmän kerrokset... 4

Kuva 2: Hyperkanavan väylänvaraus... 8

Kuva 3: Uudelleenlähetysalgoritmien teoreettinen tehokkuus... 10

Kuva 4: Netex-istunnon kulku...15

Kuva 5: Istuntoluokkien jatkokäsittely... 23

Kuva 6: Istuntojen jäsennys... 25

Kuva 7: Valvontanäyttö, jossa aikajärjestys... 29

Kuva 8: Valvontanäyttö, jossa tapahtumat lajeittain...30

Kuva 9: Valvottava järjestelmä ja valvojat...35

Kuva 10: Ohjelmiston osat ja tiedon kulku... 36

Kuva 11: Rengaspuskureiden alkioiden käyttö...43

Kuva 12: Tiedonkemuohjelman tiedostojen käyttö...48

Kuva 13: Kuukausitiedoston alkua... 50

Kuva 14: Uudet istuntotiedot... 51

Kuva 15: FTP-tiedostonsiirron esimerkki...54

Kuva 16: Valvontaohjelman prototyypin näyttöjä... 58

(7)

Taulukkoluettelo

Taulukko 1: Netex-tiedonsiiito-ohjelmointiliittymän kutsut...13

Taulukko 2: Netex-ohjausohjelmointiliittymän kutsut...14

Taulukko 3: Netex-palvelutietorakenteen kentät...19

Taulukko 4: Pal vei u tietoraken teen kenttien käyttö palvelupyynnöissä... 21

Taulukko 5: Istuntojen luokittelu... 24

Taulukko 6: UX-funktioiden saamat ja antamat tiedot... 41

Taulukko 7: Istuntotapahtumatieto rengaspuskurin tietueessa...45

Taulukko 8: FTP-siirtoparametritiedoston kentät... 52

IV

(8)

Käytetyt merkinnät ja lyhenteet

API ASCII

BCD

В FX

CSMA/CD

CSV

EBCDIC

FTP

IBM

IEEE

ISO

Netex

NRB

NRF

Application Programming Interface; ohjelmointiliittymä American Standards Committee for Information Inter

change; akronyymi viittaa nykyään yleensä em. standar

dointikomitean kehittämään merkkitiedon esitystapaan, joka on edelleen laajassa käytössä

Binary Coded Decimal; desimaalilukujen digitaalinen esitys- muotojoukko, joista yleisimmässä luvut 0-9 esitetään neljällä bitillä 0000,0001,0010,... ,1001.

Bulk File Transfer; eräkäsittelypohjainen tiedostonsiirto- järjestelmä Netex-istunto-ohjelmistoa käyttävissä hyper- kanavajärjestelmissä

Carrier Sense, Multiple Access / Collision Detection; kuul- losteluväylä törmäyksen tunnistuksella; yleinen lähiverkoissa käytettävä vuoronvarausjärjestelmä

Comma-Separated Value; eräs taulukkolaskentatiedon tal

letusmuoto

Extended Binary Coded Decimal Interchange Code; IBM- keskuslaitteissa käytettävä tiedon esitysmuoto, vit. ASCII File Transfer Protocol; TCP/IP-verkoissa käytettävä tiedos

tonsiirtomenetelmä

International Business Machines; kansainvälinen tietojen

käsittelyjärjestelmien valmistaja ja markkinoija

Institute of Electrical and Electronics Engineers; elektro- niikkainsinöörien tieteellinen yhteistyöjärjestö, joka harjoit

taa laajaa julkaisu- ja konferenssitoimintaa

International Organization for Standardization; kansain

välinen standardoimisjäijestö

Network Executive; hyperkanavassa käytettävä istuntotason verkko-ohjelmisto

Netex Request Block; Netex-palvelutietorakenne, joka si

sältää Netex-istunnon tärkeimmät tiedot

Netex Reference Number; Netex-ohjelmiston sisäinen is

tunnon tunniste

(9)

NSC

oktetti OSI

SNMP

SNMP-DPI

tavu

TCP/IP

их

VAX

VB VMS

Network Systems Corporation; yhdysvaltalainen tietoliiken

nealan yritys, jonka tuotteita ovat mm. hyperkanava ja Netex

kahdeksan bitin pituinen informaatioyksikkö, vit. tavu Open Systems Interconnection; ISO:n avoimien tiedon

siirtostandardien kehittämismalli

Simple Network Maintenance Protocol; yleinen verkon- hallintajärjestelmä

SNMP Distributed Protocol Interface; menetelmä, jolla SNMP-agenttia voidaan laajentaa

tietokonearkkitehtuurista riippuva informaatioyksikkö, yleensä kahdeksan bittiä

Transmission Control Protocol / Internet Protocol; eräs IP- verkoissa laajassa käytössä oleva yhteydellinen tiedonsiirto

tapa; tämä lyhenne tarkoittaa nykyään myös laajemmin usei

ta IP-verkkoon liittyviä ohjelmistoja ja verkkotuotteita User Exit; ohjelmointiliittymä Netex-ohjelmistoon (Netex API)

Virtual Address Extension; Digital Equipment Corpora

tionin oma prosessorimalli, jossa on monipuolinen käsky- kanta (CISC) ja jonka rekisterit ovat 32-bittisiä

Visual Basic; eräs Windows-sovellusten ohjelmointikieli Virtual Memory System; Digital Equipmentin oma, laaja käyttöjärjestelmä VAX- ja Alpha-prosessorisille laitteille

vt

(10)

1

.

Johdanto

Tietoverkkojen kasvu on räjähdysmäistä ja niiden asukkaat, verkotetut sovel

lukset, liittyvät toisiinsa yhä monipuolisemmilla tavoilla. Monimutkaiset kyt

kennät sovellusten välillä lisäävät toimintahäiriöiden mahdollisuuksia ja edistä

vät niiden vaikutusten leviämistä. Verkotettujen sovellusten kokonaisuuden hallintaan ei riitä pelkästään tietoliikenteen valvontaohjelmisto; tarvitaan kor

keamman tason malli koko sovellusjärjestelmästä, sen riippuvuussuhteista ja ominaisuuksista.

Tietoliikenteen valvontaohjelmistot ovat usein rajoittuneet tietyn, suppean val- mistajajoukon tuotteiden valvontaan, tosin tilanne tässä suhteessa paranee ko

ko ajan, kiitos SNMP-standardien laajan hyväksynnän. Nykyisessä, dynaami

sessa tietoliikennemaailmassa olisi hyödyllistä kehittää yleisempiä valvontajär

jestelmien malleja, joita voitaisiin soveltaa erilaisiin ympäristöihin. Tieto

liikenteen valvontajärjestelmät ovat myös keskittyneet valvomaan siirtoyhteys- ja verkkotason tapahtumia, mikä vaikeuttaa heterogeenisen verkon valvontaa, koska eri verkkoympäristöissä tarvitaan eri työkalut. Työkalujen kirjavuus taas vaikeuttaa laaja-alaisten virhetoimintojen vaikutuksen ilmaisua ja analysointia.

Usein verkon ylempien tasojen - istuntoja sovellustason - valvonta on täysin erillään alempien tasojen verkonvalvonnasta. Istunto- ja sovellustason valvonta täydennettynä alempien tasojen valvonnalla antaa siksi huomattavasti enemmän tietoa häiriöiden todellisista seurauksista.

Valvontaohjelmiston tulee antaa luotettava ja nopeasti tulkittava kuva verkon nykytilasta. Valvontaohjelmisto ei saa kuitenkaan missään tilanteessa kuormit

(11)

taa verkkoa eikä sen komponentteja liikaa. Reaaliaikaisen valvonnan lisäksi valvontajärjestelmä voi myös kerätä verkon käytön laskutustietoja ja pidemmän ajan virheseurantatietoa. Verkon käytön laskutus on erittäin tärkeä sovellus ny

kyaikana myös ylitysten sisäisissä verkoissa, koska kustannusten seurannalle ja kohdentamiselle asetetaan nykyaikana suuria vaatimuksia.

Keskittymällä valvomaan verkon istuntotasoa saadaan kehitettyä valvontajär

jestelmän malli, jota voidaan soveltaa hyvin erilaisiin verkkoihin, koska useim

mista verkkojärjestelmistä voidaan löytää istuntotaso. Lisäksi istunto taso 11a ol

laan lähempänä sovellusten näkemää tiedosiirtoprosessia, jolloin saadut tulok

set ovat lähemmin yhteydessä todellisen hyötytiedonsiirron suorituskykyyn.

Valvontajärjestelmään on myös helpompi lisätä älykkyyttä, joka käyttää hyväk

si eri sovellusten piir teitä ja vaatimuksia, kun saadaan tietoja riittävän korkealta tasolta. Näin eri sovellukset voidaan tunnistaa ja niiden tiedonsiirto-operaatiot eritellä vaivattomasti ja tehokkaasti.

FD Finanssidata Oy:n hyperkanavaverkko tarjoaa vakiintuneen ja rajoitetun ympäristön uuden valvontaohjelmiston kehittämiseksi. Esityö istuntotason val

vontaan on jo tehty [Kataja93]. Siinä on toteutettu tiedonkeruuliittymä erään pienkoneympäristön tietoliikenneohjelmiston istunto tasolle. Tässä työssä suun

nitellaan ja toteutetaan osia istuntotason valvontajärjestelmästä, jossa on muka

na sekä reaaliaikainen valvonta että pidemmän ajan käyttö- ja virhetilastointi.

2

(12)

Hyperkanava ja Netex Mikä on hyperkanava?

2. Hyperkanava ja Netex

2.1. Mikä on hyperkanava?

Hyperkanava on nopea, suurten ja keskisuurten tietokoneiden lähiverkko.

Vaikka hyperkanavaverkko voi olla satelliittilinkkejä hyväksi käyttäen jopa mannertenvälinen, tässä työssä käsiteltävä verkko on maantieteellisestikin lähi

verkko.

Lähes kaikki hyperkanavatuotteet (laitteet ja ohjelmistot) valmistaa yhdysvalta

lainen Network Systems Corporation1. Tuote ei perustu mihinkään standardei

hin, mutta yleistyi 1980-luvulla suurissa ATK-tuotantoympäristöissä, koska se pystyi yhdistämään usean eri laitevalmistajan laitteet toisiinsa silloin suhteellisen suurella 50-200 Mbit/s nopeudella. Tyypillisessä hyperkanavaverkossa on yleensä korkeintaan kymmeniä tietokoneita. Toisaalta niiden väliset etäisyydet voivat olla mannertenvälisiä. Hyperkanavan verkko-ohjelmistoissa on otettu huomioon satelliittilinkkien pitkät viiveet käyttämällä suuria tiedonsiirto yksi

köitä ja erityisesti viipeiseen liikenteeseen sopivaa uudelleenlähetysprotokollaa.

Tiedonsiirtoa eri laitteistoarkkitehtuurien välillä on nopeutettu tekemällä tieto- muotomuunnokset (erilaiset BCD-esitystavat, erilaiset tavuja sananpituudet, ASCII- ja EBCDIC- tekstit...) hyperkanavasovittimen puskureissa ilman isän

täkoneen apua. Ensimmäiset hyperkanavatuotteet tulivat näet markkinoille seit

semänkymmentäluvun lopussa, jolloin eri sana- ja tavupituuden laitteistoarkki

tehtuureja (IBM, Honeywell, Univac, CDC, yms.) oli laajasti käytössä.

•Lisätietoa saa linkistä http://www.network.com/

(13)

Hyperkanavassa tehdään enimmäkseen raskaita eräluonteisia tiedostonsiirtoja sovellusten välillä. Esimerkiksi FD Finanssidata Oy:ssä ei VAX-laitteistoilla tarvitse olla järeitä varmuuskopiointilaitteita tai tulostimia, vaan varmuuskopiot ja suuret tulosteet siirretään hyperkanavalla suurkoneeseen. Sieltä varmuusko

piot menevät nauharobotille ja tulosteet tehokkaisiin laserkirjoittimiin. Lisäksi suuri joukko sovelluksia pääasiassa siirtää tiedostoja eri keskustietokoneiden välillä.

Netex istunnot

Hyperkanavan laiteajuri

Hyperkanavasovitin ja -kaapelit UX-funktiot Tiedostonsiirto

Kuva 1: Hyperkanavajärjestelmän kerrokset

4

(14)

Esimerkkiympäristömme sovellukset ovat: tulostuspalvelut, varmuuskopiointi ja tiedostonsiirto sovellusten välillä. Itse asiassa kaksi edellämainittua ovat tie

dostonsiirron erikoistapauksia ja kaikki kolme käyttävät saman tiedostonsiirto- ohjelmiston palveluita. Ei kuitenkaan kannata pelkistää sovellusympäristöä niin pitkälle, että tarkasteltaisiin pelkästään tiedostonsiirtoa. Silloin hävitettäisiin nauharobotti- tai tulostinjärjestelmien osuus toimintaketjusta pois. Molemmat em. laitteistot ovat sellaisenaan monimutkaisia laitteistoja ohjelmistokokonai

suuksia, joiden toimintakatkojen vaikutukset niistä riippuviin sovelluksiin on otettava kattavassa sovellusympäristön analyysissä huomioon, vaikka niihin ei tässä työssä juurikaan puututa. Tulostuspalvelut ja varmuuskopiointi käyttävät BFX-tiedostonsiirto-ohjelmistoa, jota voidaan käyttää suoraan myös muista so

vellusohjelmista. Kuvassa on neljäntenä sovelluksena tiedonkeruuohjelma, joka on osa tässä diplomityössä laadittua valvontajärjestelmää. Tiedonkeruuohjelma kerää UX-funktioiden tiedot eikä voi vaikuttaa UX-funktioihin millään tavalla.

Siksi kuvan nuoli tiedonkeruuohjelmaan on yksisuuntainen.

Kuvan seuraavalla tasolla on Netex-istunto-ohjelmisto ja siihen liitetty, tässä diplomityössä laaditun valvontajärjestelmän osa, UX-funktiot. Kuvaan piirretyt NRB-lohkot kuvaavat jokaisen istunnon omaa hallintatietoaluetta. UX-funktiot nimittäin saavat tietoa sekä koko Netexiltä että sen hallitsemilta yksittäisiltä is

tunnoilta. Lisäksi UX-funktiot voivat vaikuttaa sekä koko Netex-ohjelmistoon (mm. estää sen käynnistymisen tai käynnistää sen uudelleen lopetuksen jälkeen) että yksittäiseen istuntoon (mm. valvomalla käyttöoikeuksia ja muuttamalla lii- kenneparametreja). Siksi nuolet UX-funktioiden ja Netexin sekä sen istuntojen välillä ovat kaksisuuntaisia.

(15)

Hyperkanava ja Netex Hyperkanavan fyysinen-ja siirtoyhteyskerros

Hyperkanava ohjelmistoineen on käytännössä osoittautunut erittäin nopeaksi tiedonsiirtojärjestelmäksi. Tavallisen VAX-lait teen varmistukset ovat satoja miljoonia, jopa miljardeja tavuja sisältäviä tiedostoja. Tällaisia varmistuksia otetaan joka päivä useita kymmeniä. Lisäksi niiden on rajoituttava ilta- ja yöai

kaan, koska varmistusten otto häiritsee koneen käyttäjiä. Tällaisessa käytössä hyperkanava on pystynyt siirtämään jatkuvasti miljoonia tavuja muutamassa se

kunnissa.

Eräs mahdollinen hyperkanavan Istunto-ohjelmisto on Netex, jonka palveluilla voi kaksi prosessia viestiä hyperkanavan yli toisilleen. Verkkomme kaikki oh

jelmistot käyttävät hyperkanavaliikenteeseensä ainoastaan Netex-palveluita, jo

ten valvomalla sen istuntotasoa saadaan sovellustason tiedonsiirtotapahtumat tarkasti tutkituksi.

2.2. Hyperkanavan fyysinen- ja siirtoyhteyskerros

Hyperkanavan eri koneita yhdistävä johto on 75 O (± 3%) koaksiaalikaapelia.

Hyperkanavakaapelissa kulkevan signaalin kantataajuus on 100 MHz ja se ky

kenee siirtämään 50 miljoonaa bittiä sekunnissa käyttäen muunnettua Millerin koodausta upotetulla kellolla.2 Hyperkanavassa käytettävä CSMA / CD poik

keaa paljon DIX3 Ethernet tai ISO 8802.3 (IEEE 802.3) -tyyppisestä CSMA / CD -periaatteesta. Hyperkanavassa saattaa kuitenkin tapahtua törmäyksiä, jo

ten CD-liite on paikallaan (CD, Collision Detection). Hyperkanavan valmista

jalla on myös hyperväylä-niminen 10 Mbit/s kuljettava tuote, jonka toimintape-

2NSC86, s. TN:l-2a/4

3Digital Equipment, Intel ja Xerox, jotka kehittivät yhdessä Ethemetin

6

(16)

riaate on CSMA/CA, eli törmäykset vältetään kokonaan (CA, Collision Avoi

dance). Hyperväylää ei tässä työssä käsitellä.

Hyperkanavan väylänvarausalgoritmiin on lisätty ennakkovarausmenetelmän4 (MLMA, Multi-Level Multiple Access) piirteitä. Täten algoritmi vaatii kaik

kien hyperkanavaan liitettyjen sovittimien määritysten muuttamista, kun kana

vaan lisätään tai siitä poistetaan sovittimia tai kanavan kaapeleiden pituuksia muutetaan. Hyperkanavan asentaminen ja toimintakuntoon saattaminen on mo

nimutkaista, toisaalta hyperkanavasovittimilla on tarkka tieto toisistaan ja ne käyttävät tätä tietoa hyväksi saavuttaakseen mahdollisimman suuren tiedonsiir

tonopeuden.

Hyperkanavaliikenteessä lähettäjä odottaa jokaiseen kehykseen vastausta siltä, jolle kehys on lähetetty (tämä on yksinkertaista, koska hyperkanavassa ei ole ryhmäosoitteita). Jos vastausta ei tule, on tapahtunut törmäys tai joku muu häi

riö ja kehys lähetetään uudelleen. Muut sovittimet antavat vastauskehykselle tietä olemalla lähettämättä lähetyksen jälkeen tietyn ajan (kuittausperiodi, fixed delay). Sen jälkeen jokaisella sovittimella on oma lähetysviipaleensa (prioriteettiperiodit, priority delays). Jos ne jäävät käyttämättä, voi kuka ta

hansa lähettää (kilpailu, free-for-all). Aikaviipaleensa käyttänyt sovitin antaa muille tilaisuuden käyttää omansa ennen seuraavaa viipaleen käyttöä. Näin yk

sikään sovitin ei pääse kaappaamaan hyperkanavaa omaan käyttöönsä.5

4Ennakkovarausmenetelmässä jokaista tiedonsiirtoaikaväliä edeltää varausaika väli. Kullakin verkon jäsenellä on oma kiinteä osuutensa (bitti) varausaikavälissä. Näin tiedonsiirtoaika- välin alkaessa jokainen verkon jäsen tietää mitkä jäsenet haluavat lähettää. Rahko84, s. 45 5NSC85, s. SN:4-5

(17)

aika

■ — - »

kehyksen lähetys

kuittausperiodi

prioriteetti-

periodit kilpailu

^{- - -}

Kuva 2: Hyperkanavan väylänvaraus

ISO 8802.3-tyyppisen CSMA / CD eli kuullosteluperiaatteella vuoron varaavan lähiverkon teoreettinen hyötysuhde on noin 90%.6 Tähän verraten hyperkana

van tulisi siten pystyä siittämään 45 miljoonaa bittiä sekunnissa eli 5,6 miljoo

naa 8-bittistä tavua sekunnissa. Tässä on laskettu mukaan siirrettävän tiedon li

säksi myös ohjausinformaatio. Toisaalta edellä esitetty ennakkovarausväylä- luonne ja kuittauskehykset huonontavat hyperkanavan maksimisiirtonopeutta verrattuna ISO 8802.3 CSMA/CD:hen. Ennakkovarausmenetelmällä on kui

tenkin etunsa: ISO 8802.3 kuullosteluperiaatteella toimiva verkko tukkeutuu nopeasti lähestyttäessä teoreettista maksimia. Hyperkanavan prioriteettimeka- nismi estää tukkeutumisen. Koska hyperkanavassa tehdään suuria eräluontoisia tiedostonsiirtoja ja tulostuksia, on laajennustarpeiden arvioimiseksi selvitettävä sen todellinen kapasiteetti.

Hyperkanavassa voi olla rinnan yhdestä neljään fyysistä 50 Mbit/s siirtotietä.

Hyperkanavasovittimet pystyvät jakamaan kuorman niille tasaisesti.7 Esimer

kiksi ISO 8802.3-tyyppisissä verkoissa pelkkä siirtoteiden lisääminen ei samalla tavalla automaattisesti kasvata siirtoyhteystason kapasiteettia. Tällä hetkellä Fi-

6Rahko84, s. 45 7Hardwick88, s. 42

8

(18)

Hyperkanava ja Nelex Netex-ohjelmisto

nanssidatalla on käytössä kaksi siirtotietä lähinnä vikasietoisuuden lisäämiseksi, mutta niiden kuormittuessa olisi mahdollista lisätä kolmas ja neljäs 50 Mbit/s väylä lisäämään tiedonsiirtokapasiteettia muuttamatta verkon ylempiä tasoja mitenkään.

2.3. Netex-ohjelmisto

Edellisessä kappaleessa siis esiteltiin OSI-mallin kerrokset 1 ja 2, eli fyysinen- ja siirtoyhteyskerros. Tämän kappaleen otsikoksi valitsin Netex-ohjelmiston, koska se on sovellusohjelmien kehittäjille mono hitti, joka kattaa OSI-mallin kerrokset 3-5, eli verkko-, kuljetus- ja istuntokerrokset. Nykyisen käsityksen mukaan tämä ei ole nun tuomittavaa kuin vielä muutama vuosi sitten. Silloin ymmärrettiin ainakin joillakin tahoilla koko OSI-mallin tarkoitus hieman väärin, kun kaikkien kerrosten piti ehdottomasti löytyä erillisinä itse tiedonsiirtojärjes

telmistä. Hyperkanavankin dokumentaatiossa luvataan avata verkko- ja kulje

tustasojen sovellusrajapinnat joskus tulevaisuudessa. Nykyään ymmärretään kerrosten olevan standardointityötä helpottamaan tarkoitettuja, jokseenkin ab

strakteja käsitteitä. On jopa esitetty, että istuntokerros on tarpeeton.8

Netex on tiedonsiirtoistuntopalveluja hyperkanavaympäristössä tuottava ohjel

misto. Netexin tarkempaan toteutukseen ei tässä työssä tutustuta, mutta esitte

len sen yhden erityispiirteen. Netex käyttää tiedonsiirtoyksiköiden uudelleenlä

hetyksissä valintaista algoritmia (selective callback) yksinkertaisemman uudel-

8Partridge93, s.8-10

(19)

Hyperkanava ja Netex Netex-ohjelmisto

leenlähetysalgoriimin (go-back-N) sijasta. Algoritmien tehokkuuden ero selviää kuvasta:9

p(p bio frameldi) := 1 - (l - p bijjframelen delay

a(delay, frame) :=--- fnmie

E gbN^P’3^ :_ ^{1 - P} 1 +(a- l)-p Esei(p) := 1 - P

bit := 1 k := 1024 M := k" s := see byte := 8-bit

a := a

p := 10

1-km 4-k-byte\

200-— »Ä

s s /

. 3 . 3

,3-10 .. 1

a =8

0.001 0.01 0.1 1

p

Kuva 3: Uudelleenlähetysalgoritmien teoreettinen tehokkuus

Kuvassa on yksinkertaisen algoritmin tehokkuus (ЕбЬм) kuvattu katkoviivalla ja valintaisen uudelleenlähetysalgoriimin tehokkuus (Е^,) yhtenäisellä viivalla.

9Yksinkertaisessa uudelleenlähetysalgoritmissa lähetetään uudelleen kuittaamaton ja kaikki sen jälkeiset tiedonsiirtoyksiköt. Valintainen algoritmi lähettää uudelleen vain kuittaamatto-

10

(20)

Huomaa, että yhtenäinen viiva leikkaa pisteet (0,1; 0,9), (0,5; 0,5) jne. kuten pitääkin. X-akselilla oleva logaritminen asteikko muuttaa suoran logaritmikäy- räksi. Pystyakselilla on tiedonsiirron suhteellinen tehokkuus teoreettisesta mak

simista ja vaaka-akselilla (p) on todennäköisyys, jolla yksittäinen tiedonsiirto- yksikkö ei mene perille.10 Parametri a kertoo montako tiedonsiirtoyksikköä eh

ditään lähettää, kunnes saadaan tieto tiedonsiirtoyksikön perille menosta. Ku

vassa on käytetty arvoa 8, joka saadaan esimerkiksi puolen kilometrin pituises

sa hyperkanavassa neljän kilotavun tiedonsiirtoyksiköillä. A:n arvolla yksi algo

ritmit ovat teoreettisesti aivan yhtä tehokkaita.

Valintaisen algoritmin tehokkuus ei riipu parametrista a, koska se lähettää uu

delleen vain ne tiedonsiirtoyksiköt, jotka eivät menneet perille. Yksinkertaisem

pi algoritmi lähettää uudelleen perille menemättömästä lähtien kaikki tiedonsiir

toyksiköt. Siksi sen tehokkuuteen vaikuttaa a, joka kertoo montako jo lähetet

tyä tiedonsiirtoyksikköä joudutaan lähettämään uudelleen.

Vaikka kuvassa olevassa kaavassa lasketaan parametrille a arvo fyysisten omi

naisuuksien (signaalin kulkunopeus 200 km/s, matka 2 • 500 m = 1 km, siirto

nopeus 50 Mbit/s, yksikkö 4 kilotavua) avulla, on se mahdollista yleistää koko tiedonsiirtojärjestelmää ja sen viiveitä koskevaksi. Valintainen algoritmi auttaa sitä enemmän, mitä enemmän tiedonsiirrossa puskuroidaan tiedonsiirtoyksiköi- tä millä kerroksella tahansa. Toisaalta valintainen algoritmi kuluttaa enemmän sekä muistia että laskentatehoa kuin yksinkertainen algoritmi. Valintaista algo-

man tiedonsiirtoyksikön. Schwartz87, s. 132-156

10Kuvan ensimmäisessä kaavassa on esitetty, miten p saadaan lasketuksi tietoliikenneteknii

kassa enemmän käytetystä bittivirhesuhteesta ры,, kun tiedetään tiedonsiirtoyksikön pituus

(21)

ritmia on siksi toistaiseksi käytetty varsin harvoin. Laskentatehon ja muistin hinnan laskiessa koko ajan on tämä algoritmityyppi hyvä pitää mielessä uusien protokollien suunnittelussa.

Kuvan mukaan valintainen algoritmi on yksinkertaista huomattavasti parem

pi, kun tiedonsiirtoyksiköiden tuhoutumistodennäköisyys on yli 0,01 (yksi sa

dasta). Tämä voidaan saavuttaa ruuhkaisissa verkoissa. Valintainen algoritmi auttaa myös sitä enemmän, mitä suurempi parametri a on. Viipeiset siirtotiet, erityisesti satelliittilinkit, kasvattavat algoritmien tehokkuuseroa huomattavasti.

Netex käyttää menestyksellä sekä parempaa algoritmia että erittäin suuria tie- donsiirtoyksiköitä taatakseen erinomaisen suorituskyvyn kaikissa tilanteissa.

Netex-istunto avataan aina kahden prosessin välille11; mikäli halutaan siirtää tietoa useamman prosessin kesken, avataan riittävä määrä kahden prosessin vä

lisiä Netex-istuntoja. Netex-istunnossa ensin toinen prosessi ilmoittaa o levänsä valmis tiedonsiirtoon. Se siirtää Netex-palvelutietorakenteessa paikalliselle Ne- tex-ohjelmalle suuren joukon parametreja, joista istunnon muodostumisen suh

teen tärkein on nimi, jolla juuri tähän odottavaan prosessiin voidaan ottaa yh

teyttä. Tämä nimi12 on korkeintaan kahdeksan merkkiä pitkä, kirjaimia ja nu

meroita sisältävä merkkijono.

Netex-tiedonsiirtoa ohjelmoidaan kaikkiaan kahdeksalla aliohjelmakutsulla:

bitteinä (framelen). Olen kuitenkin käyttänyt kuvaajassa mielestäni tähän tapaukseen ha

vainnollisempaa parametria p.

1'Kaksi tiedonsiirtoprosessia voidaan tietysti sisällyttää saman prosessin säikeisiin tms. Joka tapauksessa kyse on aina kahden, ei monenvälisestä viestinnästä.

12Katso taulukosta "Netex-palvelutietorakenteen kentät" sekä liitteenä olevan Netex-palvelu- tietorakenteen C-kielisestä kuvauksesta kenttä nrbnam.

12

(22)

Hyperkanava ja Nelex Netex-ohjelmisto

OFFER tarjous Ohjelma on valmis tiedonsiirtoon.

CONNECT yhteys Pyyntö muodostaa istunto tatjouksen antaneen ohjelman kanssa.

CONFIRM kuittaus Tarjouksen antanut ohjelma kuittaa istunto- kumppanin yhteys-pyynnön ja ilmoittaa olevansa valmis istunnon muodostamiseen.

WRITE kirjoitus Lähettää tietoa istuntokumppanille.

READ luku Vastaanottaa tietoa. Tätä käytetään myös kuit

tausten, sulkujen ja katkaisujen vastaanottami

seen.

WAIT odotus Tämä aliohjelmakutsu palaa vasta kun edellinen, asynkronisena annettu palvelupyyntö on

päättynyt.

CLOSE sulku Viimeinen kirjoituspyyntö. Ohjelma kertoo ole

vansa valmis istunnon lopettamiseen. Kump

panin antaessa sulkupyynnön istunto on päät

tynyt.

DISCONNECT katkaisu Istunnon välitön katkaisu. Tämä voidaan antaa koska tahansa.

Taulukko 1: Netex-tiedonsiirto-ohjelmointiliittymän kutsut

Tämän tiedonsiirto-ohjelmointiliittymän lisäksi on olemassa ohjausohjelmointi- liittymä. Sitä käytetään liittämällä Netex-istuntoja ylläpitävän Netex-prosessin kutsuttavaksi itse tehtyjä aliohjelmia, joille Netex antaa parametreinä erilaisia istuntotietoja ja jotka voivat myös vaikuttaa Netexin toimintaan. Ohjausohjel- mointiliittymään liitetyillä ahohjelmilla, joita jäljempänä kutsun UX-funktioiksi (UX tulee englanninkielisistä sanoista User Exit13), voidaan mm. estää minkä tahansa istunnon muodostuminen. Erilaisia UX-funktioita on seitsemän:

13UserExit -termi on laajasti käytössä mm. IBM-suurkoneympäristön ohjelmistoissa.

(23)

UXINI alustus Tätä kutsutaan NETEX-ohjelman alustukses

sa. UXINI-aliohjelmassa voidaan varata ja alustaa muidenkin UX-funktioiden tarvitsemat tietorakenteet.

UXTRM lopetus Tätä kutsutaan NETEX:n lopetuksessa.

UXTRM-aliohjelmassa vapautetaan UX- funktioiden tarvitsemat resurssit.

UXOFR tarjous Kutsutaan jonkun istunnon annettua tarjous

pyynnön.

UXCNN yhteys Kutsutaan vastaavasti yhteyspyynnössä.

UXCNF kuittaus Kutsutaan vastaavasti kuittauspyynnössä.

UXCMP valmis Kutsutaan jonkun saatua tarjouspyyntöönsä vastaukseksi yhteys-sanoman tai lukupyyn- töönsä kuittaussanoman.

UXDSC katkaisu Kutsutaan istunnon katkettua. Tämä funktio saa parametrina istunnossa vaihdettujen sano

mien ja tavujen määrän.

Taulukko 2: Netex-ohjausohjelmointiliittymän kutsut

Netex-istunnon kulku ja ohjausohjelmointiliittymän toiminta voidaan esittää ha- vainnollisimmin kaavoina, jossa näkyy myös istunnon kolme erilaista osaa:

muodostus, tiedonsiirto ja lopetus. Nämä on eroteltu toisistaan paksuilla vaa

kaviivoilla.

14

(24)

Prosessi A Prosessi В

UXOFR UXCMP UXCNF

OFFER

^_____ CONNECT UXCNN

CONFIRM —► READ UXCMP

READ WRITE —►

UXDSC

CLOSE READ

CLOSE

READ ⁴ UXDSC

Kuva 4: Netex-istunnon kulku

Aika etenee kuvassa ylhäältä alaspäin. Ensiksi prosessi A tekee tarjouspyyn

nön. Se välittyy Netex-istuntoja ohjaavalle ohjelmalle, joka aloittaa tarjous

pyynnön käsittelyn. Mikäli tarjouspyyntö oli muotoiltu oikein, hypätään UXOFR-funktioon. Jos UXOFR-funktio päästää tarjouspyynnön hyväksytysti läpi, on tarjouspyyntö palveltu loppuun. Tästä ilmoitetaan tarjouspyynnön teki

jälle.

Seuraavaksi jokin toinen prosessi tekee yhteyspyynnön, jossa se täyttää palve- lutietorakenteeseen prosessia A ajavan koneen Netex-nimen ja prosessin A tar

jouspyynnössään antaman nimen, jolla siihen otetaan yhteyttä. Yhteyspyyntö käsitellään kuten tarjouspyyntökin; ensin yhteyden yrittäjän Netex-istunnoista vastaava ohjelma tutkii, onko yhteyspyyntö muodollisesti pätevä. Jos se on,

(25)

niin kutsutaan UXCNN-funktiota, joka päättää, päästetäänkö yhteyspyyntö lähtemään verkkoon.

Kun tieto B:n yhteyspyynnöstä saapuu A:lie, merkitään A:n tarjouspyyntö lo

pullisesti täyttyneeksi. Merkiksi tarjouksen onnistumisesta suoritetaan UXCMP-funktio. Jos A ei jostain syystä halua viestiä B:n kanssa, se voi vasta

ta yhteyspyyntöön katkaisupyynnöliä. Yleensä A on halukas viestimään B:n kanssa, jolloin A tekee vastaukseksi kuittauspyynnön. Kuittauspyyntökin käsi

tellään kuten tarjous- ja yhteyspyynnöt, eli ensin Netex-ohjelma tarkistaa kut

sun ja sitten suorittaa UXCNF-funktion.

Verkkoon päässyt kuittauspyyntö saapuu lopulta B:lle. В on yhteyspyyntönsä jälkeen antanut lukupalvelupyynnön ja kun A:n kuittaus täyttää B:n lukupyyn- nön on istunto sekä A:n että B:n puolesta valmis. B:n luettua A:n kuittauksen laukeaa В-puolen Netex-ohjelmassa vielä UXCMP-funktio. Se päättää istun

non muodostusvaiheen.

Istunnon toisessa vaiheessa A ja В antavat luku- ja kirjoituspalvelupyyntöjä.

Näistä ei seuraa mitään ohjausohjelmointiliittymän tapahtumia, joten valvonta- ohjelmistolla ei ole mitään tietoa tiedonsiirron kulusta. Tiedonsiirto-ohjelmoin- tiliittymä rajoittaa tämän vaiheen asynkronista toteutusta sallimalla ainoastaan yhden luku- ja yhden kirjoituspyynnön samanaikaisen suorituksen.14

Istunnon kolmas, eli lopetusvaihe, alkaa jommankumman istunnon osapuolen antamalla sulku- tai katkaisupyynnöliä. Näiden ero on siinä, että sulku on istun

16

(26)

non normaali, järjestynyt lopetustapa, jossa molemmat istuntokumppanit sopi

vat istunnon lopettamisesta, kun taas katkaisussa toinen istuntokumppani lo

pettaa istunnon äkillisesti. Kuvan istunto päättyy A:n antamaan sulkupyyntöön, jonka В lukee ja vastaa sulkupyynnöllä. Istunnon päättyessä suoritetaan aina

UXDSC-funktio.

Netex-palvelutietorakenne

Katsahtaaksemme hieman syvemmälle Netex-istuntoon käydään esittelynomai- sesti läpi Netex-palvelutietorakenteen kentät.14 15 Kursiivilla olevat kentät eivät muutu istunnon avaamisen jälkeen. Palvelu tieto rakenteen VAX-arkkitehtuurin C-kielinen esitys on liitteenä. Vasemmassa sarakkeessa on esitetty sekä lyhyet että pitkät nimet. Koska Netex-tuotteita on kymmeniä erilaisia, nimitykset eivät kaikissa implementaatioissa ole samat, joten joillakin kentillä on useita eri ni

miä.

asp Tämä on asynkroniselle aliohjelmalle (katso kenttä ast) annettava parametri.

ast Tähän laitetaan sellaisen aliohjelman osoite, jota kutsutaan asynkronisesti palvelupyynnön päätyttyä.

bfl,

BufferLength

Tällä kentällä kerrotaan tiedonsiirtopuskurin koko. Mikäli tuleva tieto ei mahdu tähän kokoon, jää osa tiedosta saa

matta. Huomaa, että lähtevän tiedon pituus on kentässä Ien.

bsi,

MaxInBlock

Tähän kenttään kerrotaan suurin odotettu luettavan tiedon määrä. Jos kenttä jätetään nollaksi käytetään oletusarvoa.

Mikäli kenttä on -1, niin käytetään suurinta sallittua arvoa.

14NSC85, s. SN:3-6/l 15NSC89, s. 25-34

(27)

bso,

MaxOutBlock

Tähän kenttään keirotaan suurin odotettu kirjoitettavan tiedon määrä. Jos kenttä jätetään nollaksi käytetään ole

tusarvoa. Mikäli kenttä on -1, niin käytetään suurinta sallittua arvoa.

buf.

Buffer

Tähän kenttään asetetaan tiedonsiirtopuskurin alkuosoite.

cis, Class

Tämä kertoo käytettävän Netex-linjakurin tason. Kentässä saa käyttää vain joko arvoa nolla tai kaksi.

dmod, mod, DataMode

Tällä kentällä kerrotaan siirrettävän tiedon tyyppi, jotta automaattinen tiedonmuunnos tietäisi, miten tietoa tulee käsitellä. Mahdollisia aivoja ovat bittivirta (0), oktettitieto (1), 8-bittinen ASCII (2), EBCDIC (3), CDC:n BCD (4), Honeywellin BCD (5), UNIVACm Fieldata (6) ja CDC:n Display code (7).

hst,

HostName

Tähän kenttään laitetaan yhteyspyynnössä sen koneen nimi, johon halutaan ottaa yhteyttä. Jos kenttä täytetään välilyönneillä, otetaan sisäinen yhteys tähän koneeseen.

ind, Indication

Tämä kenttä kertoo, minkälainen vastaus saatiin tarjous- tai lukupyyntöön. Eri vaihtoehdot ovat: yhteys (1), kuittaus (2), tavallinen kirjoituskomennolla lähetetty paketti (3), sulku (5) ja katkaisu (6). Arvo 4 ei ole käytössä.

ios Tämä on käyttöjärjestelmäkohtainen tiedon syöttö- ja tulostustoimintojen tilakenttä.

len,

DataLength

Lähetettävän tiedon pituus sanoina. Huomaa, että eri lait

teistoissa sanan pituus vaihtelee. Nykyään tämä pituus on lähes aina 8-bittiä eli oktetti, vaikka tietokoneen sanan pituus olisikin pidempi (tavallisesti 32 tai 64 bittiä). Katso myös kenttää ubc.

nam,

ProcessName

Tähän kenttään laitetaan korkeintaan kahdeksan merkkiä pitkä, aakkosnumeerinen prosessin tunnus. Sitä käytetään ohjaamaan istunnot oikealle prosessille.

nrf, Nref

Tämä on yhteyden tunnusnumero. Kenttä jätetään nollaksi yhteys tai tarjouspyynnöissä ja istuntoja hoitava ohjelma täyttää tunnuksen siihen, kun istunto syntyy. Tämän jälkeen kenttää ei saa muuttaa.

18

(28)

nrs, Status

Palvelupyynnön tilakenttä. Tämä on -1, jos pyynnön palvelu on kesken, ja 0, jos pyyntö palveltiin virheettä.

Mikäli palvelupyyntöä suoritettaessa tapahtui virhe, on tässä kentässä positiivinen virhekoodi.

obf,

ODataAddress

Tähän laitetaan oktettitietopuskurin16 alkuosoite.

obs, obl, ODataLength

Tässä kerrotaan oktettitiedon pituus. Kirjoitettaessa siihen laitetaan kirjoitettavan tiedon pituus ja luettaessa puskurin pituus. Luvun päätyttyä kentässä on saapuneen oktettitie

don pituus.

osd Tämä on Netex-ohjelman työaluetta. Sitä ei saa muuttaa.

rat, MaxRate

Tähän kenttään voi esittää toivomuksen tiedonsiirron nopeudesta. Yksikkönä on tuhat bittiä sekunnissa. Jos kenttään laitetaan nolla, niin silloin käyttäjä haluaa mah

dollisimman nopean yhteyden. Istunnon muodostuttua istunto-ohjelmisto täyttää kenttään käytettävän tiedon

siirtonopeuden.

req,

UserRequest

Tämä kertoo palvelupyynnön tyypin; onko se synkroninen vai asynkroninen ja onko se tyyppiä yhteys, kuittaus, kirjoitus, sulku, katkaisu, tarjous vai luku.

rsl Kenttä on varattu tulevia ohjelmistomuutoksia varten.

rs2 Kenttä on varattu tulevia ohjelmistomuutoksia varten.

rs3 Kenttä on varattu tulevia ohjelmistomuutoksia varten.

rsu Kenttä on varattu UX-funktioiden käyttöön.

tmo, Timeout

Kenttä kertoo, miten monta sekuntia luku- tai tarjous

pyyntö odottaa vastausta. Jos annetaan nolla, niin odo

tetaan ikuisesti.

ubc,

UnusedBits

Tämä kenttä kertoo montako bittiä viimeisestä lähetettä

västä sanasta ei kuulu itse tietoon. Tällä voidaan lähettää tietoa muuttamatta bittiäkään eri sananpituuden tietoko

neiden kesken. Katso myös kenttä Ien.

Taulukko 3: Netex-palvelutietorakenteen kentät

16Netex-istunnossa voidaan siirtää kahdenlaista tietoa: sovellustietoa (Pdata, presentation data) ja oktettitietoa (Odata, octet data). Sovellustieto muunnetaan siirrettäessä dmod-kentäs- sä olevan ohjeen mukaisesti, mutta oktettitiedon muotoon ei kosketa.

(29)

Palvelutietorakenne on nimensä mukaisesti vain Netexiä kutsuttaessa käytettä

vä paikallinen parametrijoukko, jota ei koskaan kuljeteta verkon yli. Istunnon kummassakin päässä on oma palvelutietorakenteensa, eikä saman istunnon eri puoliskojen palvelu tieto rakenteilla ole välttämättä mitään yhteistä varsinkaan eri sana- tai tavupituutta käyttävissä järjestelmissä. Se on olemassa ainoastaan Netexiä käyttävän prosessin ja paikallisen Netex-ohjelman väliseen viestintään.

Tämä on luonnollista, kun muistetaan hyperkanavan päätarkoituksen olevan yhdistää jopa täysin eri arkkitehtuurisia järjestelmiä toisiinsa. Kussakin ympä

ristössä voidaan käyttää sille ominaisia ohjelmointitapoja ja tiedon esitysmuoto

ja, mikä parantaa järjestelmän tehokkuutta ja helpottaa sovellusten tekemistä.

Seuraavassa taulukossa17 on esitetty palvelutietorakenteen kenttien käyttö eri palvelupyyntötyypeissä:

17NSC85, s. 3-6

(30)

Hyperkanava ja Netex Nelex-ohjelmisto

tarjous yhteys kuittaus luku kirjoitus sulku katkaisu

Status R R R R R R R

Indication R D D R D D D

Data Length R S S R S S S

UnuscdBits R

s

^S ^R S S S

Nref R R X X X X X

Buffer S S

s

S S S S

BufferLength S S

Datamode R S

s

^R S S

s

Timeout S S

Class N N

MaxRate N N

MaxInBlock N N

MaxOutBlock N N

ODataAddress S S

s

S S S

s

ODataLength

c

S

s

C S S

s

ProcessName

c s

HostNamc R

s

selitykset:

R palautetaan Returned

D palautetaan katkaisun yhteydessä returned if Disconnected

S annetaan parametrina Specified

N annetaan parametrina mutta lopullinen arvo neuvotellaan

specified but Negotiated

C annetaan parametrina mutta sisältö muuttuu

specified but Changed

X vain luku sallittu, ei saa muuttaa read only Taulukko 4: Palvelutietorakenteen kenttien käyttö palvelupyynnöissä

(31)

Istuntojen luokittelujärjestelmä Istuntojen luokittelu

3. Istuntojen luokittelujärjestelmä

3.1. Istuntojen luokittelu

Netex-istunto on aina kahden prosessin välinen viestien vaihtoketju. Prosessit ovat kuten mitkä tahansa kaksi oliota, joilla on tavoitteena vaihtaa jotakin tie

toa. Viestijöiden tavoitteet voivat toteutua joko kokonaan, osittain tai ei ollen

kaan. Tavoitteiden toteutumisaste vaikuttaa merkittävästi istunnon jatkokäsit

telyyn:

Valvontajärjestelmä on kiinnostunut pääasiassa kesken olevista ja osittain tai ei ollenkaan onnistuneista istunnoista. Onnistuneet istunnot on jätetty valvontajär

jestelmän ulkopuolelle, koska valvonnan tehoa huonontaa liika informaatio. Jos halutaan jättää jokin merkki onnistuneesta istunnosta valvontajärjestelmään se on mielestäni lyhyen ajan tilastointia, eikä valvontaa sinänsä. Netex-ympäris- tön erikoispiirre, jossa vasta päättyneen istunnon siirtämän tiedon määrä saa

daan selville, vielä korostaa onnistuneiden istuntojen tilastointiluonnetta. Aino

astaan onnistuneet istunnot tuottavat volyymitietoa tiedonsiirrosta, joka on erittäin tärkeää laskutus- ja seurantamekanismeille, mutta turruttaa valvojat no

peasti.

Tilastointijärjestelmän päähuomion kohteena ovat kaikki päättyneet istunnot ja niiden yritykset, vaikka verkon käytön laskutusosa käsitteleekin ainoastaan täy

sin onnistuneita istuntoja. Epäonnistuneiden istuntojen tilastointia voidaan pe

rustella sillä, että halutaan seurata verkon luotettavuutta. Tilastointijärjestel

mällä ei sen sijaan ole mitään mielenkiintoa kesken olevia istuntoja kohtaan.

22

(32)

Seuraavassa kuvassa jaetaan neljä istuntopääluokkaa tilastoinnin ja valvonnan kesken:

Kuva 5: Istuntoluokkien jatkokäsittely

Käytännössä istunnot jaetaan eri luokkiin tarkastelemalla niiden tapahtumien järjestyksiä. Tapahtumiahan ovat kaikki seitsemän UX-funktio tyyppiä: alustus, lopetus, tarjous, yhteys, kuittaus, valmis ja katkaisu. Käsittely helpottuu, kun otetaan huomioon, että vain tapahtumat valmis ja katkaisu voivat joko onnis

tua tai epäonnistua. Muut viisi jakautuvat nekin kahteen eri tyyppiin. Alustus ja lopetus kertovat koko Netex-ohjelman alustuksesta ja lopetuksesta. Ne siis liit

tyvät istuntoihin kollektiivisesti. Kummankaan tapahtuman jäljiltä ei ole Netex- istuntoja kesken, vaan kaikki keskeneräisiin istuntoihin liittyvät tietorakenteet voidaan alustaa. Tarjous, yhteys ja kuittaus taas ovat vain indikaatioita istun

non tilan muutoksista ja ovat sinänsä aina onnistuneita. Soveltamalla näitä omi-

(33)

naisuuksia ja Netex-istunnon dokumentoitua kulkua saadaan rakennettua seu- raava taulukko, johon on luokiteltu erilaiset istuntotyypit niiden sisältämien ta

pahtumien lajin ja järjestyksen mukaan:

onnistunut istunto (kaksi erilaista)

1.1 TARJOUS, VALMIS, KUITTAUS, KATKAISU tai

1.2 YHTEYS, VALMIS, KATKAISU Lisäksi VALMIS ja KATKAISU ovat onnistuneet.

osittain onnistunut is

tunto

(kaksi erilaista)

2.1 TARJOUS, VALMIS, KUITTAUS, KATKAISU tai

2.2 YHTEYS, VALMIS, KATKAISU Lisäksi VALMIS on onnistunut ja KATKAISU on epäonnistunut.

kesken oleva istunto (viisi erilaista)

3.1 TARJOUS

3.2 TARJOUS, VALMIS, jossa VALMIS on onnistunut

3.3 TARJOUS, VALMIS, KUITTAUS, jossa VALMIS on onnistunut

3.4 YHTEYS

3.5 YHTEYS, VALMIS, jossa VALMIS on onnistunut

epäonnistunut istunto (kuusi erilaista)

4.3.1 tilasta 3.1 ulos kaaviosta 4.3.2 tilasta 3.2 ulos kaaviosta 4.3.3 tilasta 3.3 ulos kaaviosta 4.3.4 tilasta 3.4 ulos kaaviosta 4.3.5 tilasta 3.5 ulos kaaviosta

4 heti ulos kaaviosta

Taulukko 5: Istuntojen luokittelu

Valmis-ja katkaisu-tapahtumat voivat olla joko onnistuneita tai epäonnistunei

ta, koska ne ovat istunto-ohjelman antamia indikaatioita istunnon tilan muutok

sista. Tarjous-, kuittaus- ja yhteys-tapahtumat onnistuvat aina, koska ne ovat osa istunto-ohjelmalle annettujen palvelupyyntöjen käsittelyä. Valmis- tai kat- kaisutapahtuman onnistuminen nähdään istunnon palvelutietorakenteen paluu-

24

(34)

koodikentästä.18 Lisäksi, jos katkaisussa ilmoitettu siirretyn tiedon määrä on molempiin suuntiin nolla, on tiedon siirto todennäköisesti epäonnistunut. Täl

löin ei vika välttämättä ole tiedonsiirtojärjestelmässä, vaan siirto voi epäonnis

tua jos siirrettävät tiedostot tai hakemistot puuttuvat. Ne voivat olla myös tois

ten sovellusten varaamia. Kenties tilaa tiedoston kirjoittamiseen ei ole riittäväs

ti. Näissä kaikissa tapauksissa tiedonsiirtoistunto on sujunut hyvin, mutta so

vellus ei. Siten on perusteltua käsitellä tällainen katkaisu epäonnistuneena.

Seuraavasta kuvasta nähdään, miten istunnon luokka voidaan määrittää jäsen

tämällä istunnon tapahtumaketjua samalla kun istuntoon liittyviä uusia tapahtu

mia saadaan selville. Kuvassa olevassa jäsennyspuussa edetään juuresta lehtiin päin kunnes siirrytään pois jäsennyspuusta tai päädytään johonkin äärimmäisis

tä lehdistä.

Kuva 6: Istuntojen jäsennys

18Katso taulukosta "Netex-palvelutietorakenteen kentät" sekä liitteenä olevan Netex-palvelu- tietorakenteen C-kielisestä kuvauksesta kenttä nrbnrs.

(35)

Kuvassa lähdetään ratkaisemaan istunnon luokkaa juuresta eli tilasta neljä.

Kaaviossa edetään tilasta toiseen seuraamalla istuntotapahtumanuolia. Mikäli jostakin tilasta ei mikään sopiva nuoli johda pois, on istunto epäonnistunut ja asetetaan luokkaan neljä.

Luokassa neljä on kaksi erikoisistuntotyyppiä: alustus ja lopetus. Kumpikin koostuu yhdestä tapahtumasta, joka ilmoittaa kyseisen verkkosolmun Netex- ohjelmiston joko aloittaneen toimintansa tai lopettaneen sen. Kun tällainen is

tunto tulee valvontajärjestelmän näköpiiriin, on päätettävä kaikki kyseiseen ko

neeseen kesken olleet istunnot. Lisäksi nämä erikoisistunnot on ilmaistava val- vontaohjelmIstossa näkyvästi.

Luokan neljä istunnot voidaan luokitella edelleen tarkemmin sen mukaan mikä oli se tila, josta jouduttiin kaaviosta ulos. Esimerkiksi, jos heti ensimmäinen is

tunnon tapahtuma on katkaisu, on istunto luokkaa neljä. Mikäli istunnon tapah

tumaketju oli tarjous-kuittaus-katkaisu on se luokkaa 4.3.1. Tällä tarkemmalla luokittelulla saadaan luokan neljä istunnot jaettua kymmeneen aliluokkaan.

Näistä aliluokista kuitenkin hylätään ne neljä, jotka jatkaisivat jo katkaisutapah- tumaan johtanutta tapahtumaketjua. Niissä tapauksissa olisi suuri vaara sotkea jo päättyneen istunnon kirjanpitoa jonkin jälkeenpäin sattuneen virheen takia, joten hylkäämme aliluokat 4.1.1, 4.1.2, 4.2.1 ja 4.2.2. Jäljelle jääneet aliluokat

on esitetty taulukossa Istuntojen luokittelu.

26

(36)

Istuntojen luokittelujärjestelmä Istunnon tunniste

3.2. Istunnon tunniste

Eri istunnot erotellaan toisistaan yhdistämällä kolme eri tietoa yhdeksi, yksikä

sitteiseksi istunnon tunnisteeksi. Tunnisteen rungon muodostaa Netex-ohjelman istunnolle antama numero (NRF).19 Se ei kuitenkaan kelpaa sellaisenaan ainoaksi tunnisteeksi, koska eri laitteiden Netex-ohjelmat saattavat käyttää sa

moja numeroita istunnoissaan ja samankin laitteiston Netex-ohjelma alkaa tois

taa istuntonumeroita käynnistyttyään uudelleen. Niinpä tunnisteeseen lisätään sen koneen hyperkanavanimi, jossa istuntoa tarkkaillaan. Tämä nimi on kor

keintaan kahdeksan merkkiä pitkä kirjain- ja numeroyhdistelmä. Viimeiseksi li

sätään tunnisteeseen istunnon ensimmäisen tapahtuman aikaleima.

Edellä esitetystä kolmiosaisesta istunnon tunnisteesta voidaan jättää istunnon ensimmäisen tapahtuman aikaleima pois. Tämän yksinkertaisemman tunnisteen etuna on huomattavasti vaivattomampi ylläpito. Tällöin on kuitenkin mahdollis

ta, että Netex-ohjelmiston alustamisen tai istunnon numeron uudelleenkäytön vuoksi eri istunnoille muodostuu samanlainen tunniste. Se on kuitenkin lyhyellä tarkasteluvälillä harvinaista. Niinpä valvontajärjestelmä, joka ei muutenkaan säilytä istuntotietoa pitkään, voi käyttää tätä yksinkertaisempaa kaksiosaista is

tunnon tunnistetta ja pidemmän ajan tilastoinnissa käytetään kolmiosaista, täy

sin yksikäsitteistä tunnistetta.

19Katso taulukosta "Netex-palvelutietorakenteen kentät" sekä liitteenä olevan Netex-palvelu- tietorakenteen C-kielisestä kuvauksesta kenttä nrbnrf.

(37)

Istuntojen luokittelujärjestelmä Istunnot valvontajärjestelmän kannalta

3.3. Istunnot valvontajärjestelmän kannalta

Istuntojen luokittelua voidaan käyttää hyväksi valvontajärjestelmässä monin eri tavoin. Istunto täytyy jossakin vaiheessa päästää pois valvontajärjestelmän pii

ristä. Toisaalta valvontajärjestelmän olennainen osa on Käyttöjärjestelmä, siis se tapa, jolla kiinnostavat tiedot saadaan esille massatiedosta. Siinä auttaa tie

don järjestäminen ryhmiin. Edellä esittämäni istuntoluokat ovat istunnoille juuri tällainen järjestäjä.

Valvontajärjestelmä seuraa lyhyellä aikavälillä kaikkia istuntoja joista sillä on tietoa. Jottei säilytettävän tiedon määrä kasva liian suureksi, on lopulta päätet

tävä, mistä tiedosta on pakko luopua uuden tilan saamiseksi. Edellä jo totesin, että valvontajärjestelmä on kiinnostunut pääasiassa muista kuin onnistuneista istunnoista. Ensimmäinen käsittelysääntö onkin luopua ensiksi vanhimpien, on

nistuneiden istuntojen tiedoista, koska näiden kiinnostavuus on pienin. Seuraa- vaksi luovumme vanhojen osittain onnistuneitten istuntojen tiedoista, sillä nii

den joukossa on myös tarkoituksellisesti keskeytettyjä istuntoja. Sitten seuraa kesken olevat istunnot ja lopuksi epäonnistuneet istunnot. Epäonnistuneiden is

tuntojen tiedoista luovutaan viimeksi, koska ne ovat aina odottamattoman ti

lanteen aiheuttamia.

Käytännössä on pakko määritellä tarkemmin, mitä ovat vanhimmat tiedot.

Vuorokautta vanhempi istunto on vanha, ja sen tiedoista luovutaan edellä esite

tyn suunnitelman mukaan. Lisäksi, koska mikään valvontajärjestelmässä oleva istunto ei ole yli vuorokautta vanhempi, voidaan näytöissä jättää päivämäärät pois ja käsitellä vain kellonaikoja. Valvontajärjestelmän istuntokapasiteetin on

28

(38)

Istuntojen luokittelujärjestelmä Istunnot valvontajäijestelmän kannalta

oltava niin suuri, ettei koko käytettävissä oleva istuntotila täyty viimeisen vuo

rokauden epäonnistuneiden istuntojen tiedoista.

Valvontajärjestelmän näyttöjä voidaan rakentaa istuntojen luokituksen mukaan.

Olen hahmotellut kahta eri tapaa näyttää istuntoja. Toisessa viimeisimmät is

tunnot näkyvät aikajärjestyksessä ja istunnon luokka ilmaistaan värillä tai taus

takuvalla. Tämän näyttötavan etuna on ajan kulun helppo seuranta. Tapahtu

mien syy-seuraussuhde on helppo nähdä. Siirto tulkitaan aina tapahtuvaksi yh

teydenottajasta tarjouksen antajaan, vaikka todellinen hyötytieto voi siirtyä kumpaan suuntaan tahansa tai vaikka molempiin suuntiin.

штттттттт

lllilllllilllllliiilill11111111111

мшшшшшм

.^44%%v.v.v.v.v.%ssx.kí«.:w:.:.:.

NETEX-valvontajärjestelmä: tiedonsiirrot 12.4.1996 21.59

aika I mistä (ohjelma) I minne (ohjelma) I tila I lähetetty1 I vastaanotettu I siirtonopeus

0934 I VAX3 () I 0K088 (BFXJS) I oo I 0 (0) I 0 (0) I 0 Mbit/s

1012 I 0K088 (2214Z-01) I VAX3 (ОРТОНPR) I о I 4 (168) I 13 (133 935) I 1,53 Mbit/s 1027 I 0K088 (2218Z-01) I VAX3 (VOTTOHPR) I о I 4 (168) I 7 (33 639) I 1,07 Mbit/s

Шpii iSl

Kuva 7: Valvontanäyttö, jossa aikajärjestys

Toinen tapa on asettaa eri istuntoluokat näytön eri osiin. Tällöin on vaikeampi hahmottaa istuntojen tilamuutosten tapahtuma-aikojen suhdetta toisiinsa. Toi-

(39)

Istuntojen luokittelujärjestelmä Istunnot tilastointijärjestelmän kannalta

saalia, jos olemme kiinnostuneita ainoastaan tietyntyyppisistä istunnoista, on tällaisesta näytöstä helpompi etsiä haluamaansa tietoa. Valvontajärjestelmän näytöissä on pystyttävä valitsemaan kumpi tahansa esitetyistä tavoista näyttää istuntotietoa.

Ш1Р

ISIS

■pl

¡lili.

N ETEX-valvontajärjestelmä: tiedonsiirrot lajeittain 12.4.1996 21.57 li.

Kesken Osittaiset Epäonnistuneet

'li!

0922 VAX1 -> VAX2 43234 0922 VAX1 -> VAX2 43234 0922 VAX1 -> VAX2 43234 ¡III 0952 VAX1 -> VAX2 43234 0952 VAX1 -> VAX2 43234 0952 VAX1 -> VAX2 43234

Jill

1027 VAX2 -> VAX1 556 1027 VAX2 -> VAX1 556 1027 VAX2 -> VAX1 556 II 0922 VAX1 -> VAX2 43234 0922 VAX1 -> VAX2 43234 0922 VAX1 -> VAX2 43234

0922 VAX1 -> VAX2 43234 0922 VAX1 -> VAX2 43234 0922 VAX1 -> VAX2 43234 ЩЩ

0922 VAX1 -> VAX2 43234 0922 VAX1 -> VAX2 43234 0922 VAX1 -> VAX2 43234

0922 VAX1 -> VAX2 43234 0922 VAX1 -> VAX2 43234 0922 VAX1 -> VAX2 43234 lili 0922 VAX1 -> VAX2 43234 0922 VAX1 -> VAX2 43234 0922 VAX1 -> VAX2 43234

III

0922 VAX1 -> VAX2 43234 0922 VAX1 -> VAX2 43234 0922 VAX1 -> VAX2 43234

ill

0922 VAX1 -> VAX2 43234 0922 VAX1 -> VAX2 43234 0922 VAX1 -> VAX2 43234 1:11 0922 VAX1 -> VAX2 43234 0922 VAX1 -> VAX2 43234 0922 VAX1 -> VAX2 43234 III 0922 VAX1 -> VAX2 43234 0922 VAX1 -> VAX2 43234 0922 VAX1 -> VAX2 43234 Hf

siili

ттттттттттж

Kuva 8: Valvontanäyttö, jossa tapahtumat lajeittain

3.4. Istunnot tilastointijärjestelmän kannalta

Tilastoja pidetään kaikesta muusta paitsi keskeneräisestä istuntotiedosta. Tämä tilastoinnin kattavuus johtuu ennen kaikkea tilastoinnin jatkuvasti muuttuvasta luonteesta. Aina tulee uusia tiedon tarpeita, jolloin tarvitaan jotain sen tyyppis

tä tietoa, minkä keräämiseen ei ole edeltä varauduttu. Tällöin on hyvä, että kai

kesta mahdollisesta on kerätty tiedot talteen. Tietoa on myös säilytettävä usei-

30

(40)

Istuntojen luokittelujärjestelmä Istunnot tilastointijärjestelmän kannalta

den vuosien ajalta, koska niitä voidaan tarvita erilaisissa selvittelyissä (rikokset, ohjelmistovirheet, jne.).

Tilastoja voidaan tehdä hyvin erilaisiin tarkoituksiin. Helposti luulisi, että ver

kon käytön laskutukseen tarvitaan vain täysin onnistuneiden istuntojen tietoja.

Kuitenkin asiakas saattaa vaatia hyvitystä epäonnistuneista istunnoista, mikäli epäonnistuminen johtui tiedonsiirtopalvelun tuottajan virheestä. Tällöin epäon

nistuneiden istuntojen tilastoja tarvitaan laskutuksen tukena.

Ylläpidolle voi olla tärkeää raportoida pelkästään osittain tai täysin epäonnistu

neista istunnoista. Jos epäonnistumisista voidaan osoittaa jokin tietty kellonai

ka, päivä, vuodenaika, laitteisto tai jokin muu yhteinen tekijä, voi siitä olla hyö

tyä ongelman syyn selvittämisessä.

Yhteenvetona voidaan todeta, että tilastojen raakatieto on talletettava mahdol

lisimman täydeUisenä muuttuvia tarpeita varten. Tieto on myös säilytettävä luo

tettavasti useiden vuosien ajan.

(41)

Istuntotason valvonta- ja tilastointiohjelmisto Ohjelmiston toimintaympäristö

4. Istuntotason valvonta- ja tilastointiohjelmisto

4.1. Ohjelmiston toimintaympäristö

FD Finanssidata Oy:n tietojenkäsittelylaitteisto koostuu kymmenistä eri valmis

tajien eri kokoisista tietokoneista ja niiden oheislaitteista. Oheislaitteet vaihtele- vat levykeasemista suurtehotulostimiin. Laitteistoja käytetään ja niitä valvotaan ympäri vuorokauden. Jotta saavutettu palvelutaso voidaan säilyttää yhä vähe

nevällä työntekijäjoukolla on valvontaohjelmIstoja jatkuvasti kehitettävä pa

remmiksi.

Millainen sitten on parempi valvontaohjelmisto? Usean vuoden aikana on mo

nissa operointi- ja valvontaympäristön kehitysprojekteissa selkiytynyt joukko hyvän valvontajärjestelmän ominaisuuksia. Luonnollisesti ne ovat usein ristirii

taisia, joten aina joudutaan valitsemaan useista hyvistä ominaisuuksista ne, joi

den kehittämiseen keskitytään.

Hyvä valvontajärjestelmä toimii poikkeustilanteissakin. Huonompia esi

merkkejä ovat järjestelmät, jotka tukehduttavat järjestelmän poikkeustilanteis

sa. Käytännössä suuri osa valvontajärjestelmistä toimii poikkeustilanteissa huo

nosti, toisin sanoen, ne on suunniteltu toimimaan, kun levytilaa on riittävästi, tietoliikenneverkko ei ole tukossa, keskusyksikkö ei ole ylikuormittunut, näyt

töruudulla on tilaa uusille ikkunoille ja kirjoittimen paperi ei lopu koskaan.

Käytännön valvontaympäristössä on aina pula resursseista. Siksi valvontajärjes

telmän jokaisessa osassa on huolehdittava, ettei se omalla toiminnallaan vaikeu

ta tai jopa ehkäise virheen korjaamista.

32

(42)

Istuntotason valvonta- ja tilastointiohjelmisto Ohjelmiston toimintaympäristö

Hyvä valvontajärjestelmä hälyttää ajoissa, tehokkaasti ja oikein. Nämä ominaisuudet ovat vielä vaikeampia saavuttaa kuin edellinen poikkeustilanteis

sa toimivuuden vaatimus. Hälytysrajojen ylityttyä hälytys saadaan mahdollisim

man ajoissa, kun varmistetaan, että hälytyksen tekeminen vaatii mahdollisim

man vähän resursseja. Resursseilla tarkoitan tässä keskusyksikköä, muistia, le

vytilaa ja kaikkia muitakin tietojenkäsittely-ympäristön resursseja. Tämä vaati

muksen täyttäminen on luonnollisesti sitä vaikeampaa, mitä korkeamman tason työkaluilla valvontajärjestelmää kehitetään. On joka tapauksessa hyvä etsiä jo

kaisesta kehitystyökalusta esiin sen taloudelliset ja tuhlailevat ohjelmointitavat.

Poikkeustilanteissa on usein välittömästi pulaa resursseista. Mikäli valvontaoh

jelma on ohjelmoitu samoilla työkaluilla samoja ohjelmointitapoja käyttäen kuin muut sovellukset se joutuu kilpailemaan sovellusohjelmien kanssa samoista re

sursseista eikä ehkä saa hälytystä perille.

Hälytyksen tehokkuus on hyvin suhteellinen käsite. Mikäli hälytettävänä on ih

minen, tekevät yksilölliset erot tehokkaan hälyttämisen vaikeaksi. Joku voi ko

kea hälytyksen liian tehokkaana ja liian tehokas hälytys ärsyttää. Esimerkiksi kovaääninen puhesyntetisaattori jäi lyhytaikaiseksi kokeiluksi. Liian tehokas hälytys, mikäli se ei toistu liian usein, on kuitenkin huomaamatonta hälytystä parempi. Hälytysjärjestelmän suunnittelussa on aina muistettava pitää yhteyttä valvontahenkilökunnan kanssa. Heillä on pitkäaikaista käytännön kokemusta eri valvomojärjestelmien parissa ja he osaavat usein neuvoa hälytysjärjestelmän kehittäjää. Turhat hälytykset johtavat hyvin nopeasti koko järjestelmän hyl

käämiseen. Loppujen lopuksi käyttäjät määrittelevät mikä on siedettävä häly

tysten määrä ja mitkä ovat toimivat hälytysrajat.