Distribuovaný AIS sa stal každodennou realitou. Početné podnikové AIS využíva distribuované databázy. Rozpracované sú metódy distribúcie údajov a správy distribuovaných údajov, architektonické prístupy zabezpečujúce škálovateľnosť systémov, implementácia princípov viacvrstvovej architektúry klient-server, ako aj architektúra strednej vrstvy.

V praxi sa začínajú uplatňovať mobilné architektúry. Platí to pre databázové systémy aj webové aplikácie.

Oživuje sa prístup k budovaniu distribuovaných systémov založených na architektúre peer-to-peer, v ktorej na rozdiel od architektúry klient-server, ktorá dnes v distribuovaných systémoch dominuje, nie sú úlohy interagujúcich strán v sieti pevne dané. Prideľujú sa v závislosti od situácie v sieti, od zaťaženia jej uzlov.

V súvislosti s intenzívnym rozvojom komunikačných technológií sa aktívne rozvíja mobilný AIS. Boli vyvinuté technické prostriedky a softvér na ich tvorbu. To viedlo k vývoju mobilných databázových systémov. Mnohé výskumné tímy vykonávajú výskum špecifických vlastností takýchto systémov a vytvárajú ich rôzne prototypy. Java technológie sa stali dôležitým nástrojom pre vývoj mobilného softvéru.

Bol vytvorený štandard WAP (Wireless Application Protocol), ktorý už podporujú niektoré modely mobilných telefónov. Na základe WAP a XML vyvinulo W3C značkovací jazyk pre bezdrôtovú komunikáciu WML (Wireless Markup Language).

Pri vývoji AIS sa viac pozornosti venovalo metaúdajom. Tu prebiehajú kroky v dvoch smeroch – štandardizácia prezentácie metadát a zabezpečenie ich podpory v systéme.

AIS využíva rôzne spôsoby a prostriedky prezentácie metadát (rôzne druhy úložísk metadát). Nejednotnosť v tejto oblasti výrazne komplikuje riešenie problémov mobility aplikácií, opätovného využitia a integrácie informačných zdrojov a informačných technológií, ako aj reengineeringu AIS.

Na prekonanie týchto ťažkostí sa aktívne pracuje na vývoji štandardov metadát zameraných na rôzne informačné technológie. V tejto oblasti už existuje množstvo medzinárodných, národných a priemyselných štandardov, ktoré definujú prezentáciu metadát a výmenu metadát v AIS. Niektoré z nich už získali štatút de facto štandardov. Tu sa obmedzíme na uvedenie len tých najvýznamnejších z nich.

Pravdepodobne prvým de facto štandardom pre túto kategóriu bol jazyk popisu údajov CODASYL pre sieťové databázy. Treba pomenovať nasledovné štandardy: štandard dotazovacieho jazyka SQL pre relačné databázy, obsahujúci definíciu takzvanej informačnej schémy - súboru reprezentácií schém relačných databáz; štandardný komponent databázy objektov ODMG, ktorý popisuje rozhrania úložiska schém objektov; medzinárodný štandard IRDS (Information Resource Dictionary Systems), ktorý popisuje systémy na vytváranie a udržiavanie adresárov informačných zdrojov organizácie.

Ďalej je potrebné spomenúť štandard Common Warehouse Metamodel (CWM) na reprezentáciu metadát dátového skladu, ktorý vyvinulo konzorcium OMG, na základe predtým vytvoreného štandardu OIM (Open Information Model) konzorcia MDC (Meta Data Coalition) na širšie účely. .

Nová platforma XML pre webovú technológiu zahŕňa aj štandardy prezentácie metadát. Podpora metadát je jednou z najdôležitejších inovácií webu, ktorá radikálne mení technológiu správy informačných zdrojov. Zatiaľ čo podpora metadát bola pôvodne vyžadovaná v databázových technológiách, metaúdaje neboli podporované na webe prvej generácie.

Štandardy webových metadát zahŕňajú podmnožinu jazyka XML používaného na opis logickej štruktúry určitého typu dokumentu XML. Tento popis sa nazýva DTD (Document Type Definition). Platforma XML navyše obsahuje štandard XML Schema, ktorý ponúka pokročilejšie možnosti na popis dokumentov XML. Štandard RDF (Resource Definition Framework) definuje jednoduchý jazyk reprezentácie znalostí na popis obsahu dokumentov XML. Napokon, vznikajúci štandard OWL (Ontology Web Language) definuje formálny jazyk popisu ontológie pre sémantický web.

Štandard UML (Unified Modeling Language), ktorý poskytuje reprezentáciu metadát pre CASE vizuálnu analýzu objektov a návrhárske nástroje, vyvinulo konzorcium OMG. Tento jazyk je podporovaný v mnohých softvérových produktoch CASE. OMG tiež vytvoril štandard XML Metadata Interchange (XMI) na výmenu metadát medzi nástrojmi CASE pomocou UML.

Tu treba spomenúť aj štandard Dublin Core (DC), súbor prvkov metadát na popis obsahu dokumentov rôzneho charakteru. Tento štandard si rýchlo získal obľubu a našiel široké uplatnenie najmä vo webovom prostredí (pozri časť 3.3).

Pokračujú práce na vývoji existujúcich a tvorbe nových štandardov pre prezentáciu metadát pre AIS. Podrobnejšie informácie o predmetných normách nájdete v encyklopédii.

Podľa známeho odborníka v oblasti informatiky E. Tanenbauma neexistuje všeobecne akceptovaná a zároveň striktná definícia distribuovaného systému. Niektorí rozumní argumentujú, že distribuovaný je taký výpočtový systém, pri ktorej nefunkčnosť počítača, o ktorej existencii používatelia predtým ani netušili, vedie k ukončeniu všetkej ich práce. Značná časť distribuovaných počítačových systémov, žiaľ, spĺňa túto definíciu, ale formálne sa vzťahuje len na systémy s jedinečným bodom zraniteľnosti ( jediný bod zlyhania).

Pri definovaní distribuovaného systému sa často kladie dôraz na rozdelenie jeho funkcií medzi niekoľko počítačov. S týmto prístupom sa distribuuje akékoľvek výpočtový systém kde je spracovanie údajov rozdelené medzi dva alebo viac počítačov. O niečo užšie distribuovaný systém možno na základe definície E. Tanenbauma definovať ako súbor nezávislých počítačov prepojených komunikačnými kanálmi, ktoré z pohľadu používateľa nejakého softvéru vyzerajú ako jeden celok.

Tento prístup k definovaniu distribuovaného systému má svoje nevýhody. Napríklad všetko, čo sa v takomto distribuovanom systéme používa softvér mohol fungovať na jedinom počítači, no z pohľadu vyššie uvedenej definície sa takýto systém už nebude distribuovať. Koncept distribuovaného systému by preto mal byť pravdepodobne založený na analýze softvéru, ktorý takýto systém tvorí.

Ako základ pre popis interakcie dvoch entít zvážte všeobecný model interakcie klient-server, v ktorom jedna zo strán (klient) iniciuje výmenu údajov odoslaním požiadavky druhej strane (serveru). Server požiadavku spracuje a v prípade potreby odošle klientovi odpoveď (obr. 1.1).

Ryža. 1.1.

Interakcia v rámci modelu klient-server môže byť buď synchrónna, keď klient čaká, kým server spracuje svoju požiadavku, alebo asynchrónna, pri ktorej klient odošle požiadavku na server a pokračuje v jej vykonávaní bez čakania na server. odpoveď. Model klienta a servera možno použiť ako základ pre popis rôznych interakcií. Pre tento kurz je dôležitá interakcia jednotlivých častí softvéru, ktorý tvorí distribuovaný systém.

Ryža. 1.2.

Uvažujme o určitej typickej aplikácii, ktorú možno v súlade s modernými koncepciami rozdeliť do nasledujúcich logických úrovní (obr. 1.2): používateľské rozhranie(PI), aplikačná logika (LP) a prístup k dátam (DD), práca s databázou (DB). Používateľ systému s ním komunikuje prostredníctvom používateľského rozhrania, databáza ukladá údaje popisujúce doménu aplikácie a vrstva logiky aplikácie implementuje všetky algoritmy súvisiace s predmetná oblasť.

Keďže v praxi majú rôzni používatelia systému zvyčajne záujem o prístup k rovnakým údajom, najjednoduchším oddelením funkcií takéhoto systému medzi niekoľko počítačov bude oddelenie logických vrstiev aplikácie medzi jednu serverovú časť aplikácie. , ktorá je zodpovedná za prístup k údajom, a klientskym častiam umiestneným na viacerých počítačoch.implementácia používateľského rozhrania. Aplikačnú logiku je možné priradiť k serveru, klientom alebo medzi nimi zdieľať (obrázok 1.3).

Ryža. 1.3.

Architektúra aplikácií postavená na tomto princípe sa nazýva klient-server alebo dvojvrstvová. V praxi takéto systémy často nie sú klasifikované ako distribuované, ale formálne ich možno považovať za najjednoduchších predstaviteľov distribuovaných systémov.

Vývoj architektúry klient-server je trojvrstvová architektúra, v ktorej sú používateľské rozhranie, aplikačná logika a prístup k dátam rozdelené do nezávislých komponentov systému, ktoré môžu bežať na nezávislých počítačoch (obr. 1.4).

Ryža. 1.4.

Požiadavka užívateľa v takýchto systémoch je postupne spracovaná klientskou časťou systému, serverom aplikačnej logiky a databázovým serverom. Distribuovaný systém sa však zvyčajne chápe ako systém so zložitejšou architektúrou ako trojvrstvový.

V predchádzajúcej kapitole sme sa zamerali na úzko prepojené viacprocesorové systémy so zdieľanou pamäťou, zdieľanými dátovými štruktúrami jadra a zdieľaným fondom, z ktorého sa vyvolávajú procesy. Často je však žiaduce alokovať procesory takým spôsobom, aby boli nezávislé od operačného prostredia a prevádzkových podmienok na účely zdieľania zdrojov. Predpokladajme napríklad, že používateľ osobného počítača potrebuje získať prístup k súborom umiestneným na väčšom počítači, no zároveň si ponechať kontrolu nad osobným počítačom. Aj keď niektoré programy, ako napríklad uucp, podporujú sieťový prenos súborov a iné sieťové funkcie, ich používanie nebude pred používateľom skryté, pretože používateľ si je vedomý toho, že sieť používa. Okrem toho je potrebné poznamenať, že programy, ako sú textové editory, nepracujú s odstránenými súbormi ako s bežnými súbormi. Používatelia by mali mať štandardnú sadu funkcií systému UNIX a okrem potenciálneho obmedzenia výkonu by nemali cítiť prekračovanie hraníc stroja. Takže napríklad práca systémových funkcií otváraných a čítaných so súbormi na vzdialených počítačoch by sa nemala líšiť od ich práce so súbormi patriacimi do lokálnych systémov.

Architektúra distribuovaného systému je znázornená na obrázku 13.1. Každý počítač zobrazený na obrázku je samostatná jednotka pozostávajúca z CPU, pamäte a periférnych zariadení. Model sa nerozbije, aj keď počítač nemá lokálny súborový systém: musí mať periférne zariadenia na komunikáciu s inými strojmi a všetky súbory, ktoré k nemu patria, môžu byť umiestnené na inom počítači. Fyzická pamäť dostupná každému stroju je nezávislá od procesov bežiacich na iných strojoch. V tomto ohľade sa distribuované systémy líšia od tesne prepojených multiprocesorových systémov, o ktorých sme hovorili v predchádzajúcej kapitole. V súlade s tým jadro systému na každom stroji funguje nezávisle od vonkajších prevádzkových podmienok distribuovaného prostredia.

Obrázok 13.1. Model systému distribuovanej architektúry

Distribuované systémy, dobre opísané v literatúre, tradične spadajú do nasledujúcich kategórií:

Periférne systémy, čo sú skupiny strojov, ktoré majú silnú spoločnú črtu a sú spojené s jedným (zvyčajne väčším) strojom. Periférne procesory zdieľajú svoju záťaž s centrálnym procesorom a preposielajú mu všetky hovory operačného systému. Cieľom periférneho systému je zvýšiť celkový výkon siete a poskytnúť možnosť prideliť procesor jedinému procesu v operačnom prostredí UNIX. Systém sa spustí ako samostatný modul; Na rozdiel od iných modelov distribuovaných systémov, periférne systémy nemajú skutočnú autonómiu, s výnimkou prípadov súvisiacich s dispečingom procesov a alokáciou lokálnej pamäte.

Distribuované systémy ako "Newcastle", umožňujúce vzdialenú komunikáciu podľa názvov vzdialených súborov v knižnici (názov je prevzatý z článku "The Newcastle Connection" - pozri). Vymazané súbory majú kusovník (rozlišujúci názov), ktorý vo vyhľadávacej ceste obsahuje špeciálne znaky alebo voliteľný komponent názvu, ktorý predchádza koreňový adresár systému súborov. Implementácia tejto metódy nezahŕňa vykonávanie zmien v jadre systému, a preto je jednoduchšia ako ostatné metódy diskutované v tejto kapitole, ale menej flexibilná.

Distribuované systémy sú úplne transparentné, v ktorých štandardné rozlišujúce názvy postačujú na odkazovanie na súbory umiestnené na iných počítačoch; je na jadre, aby rozpoznalo tieto súbory ako odstránené. Cesty vyhľadávania súborov špecifikované v ich zložených názvoch prekračujú hranice stroja v bodoch pripojenia, bez ohľadu na to, koľko takýchto bodov sa vytvorí, keď sú súborové systémy pripojené na disky.

V tejto kapitole sa pozrieme na architektúru každého modelu; všetky poskytnuté informácie nie sú založené na výsledkoch konkrétneho vývoja, ale na informáciách publikovaných v rôznych technických článkoch. To predpokladá, že moduly protokolov a ovládače zariadení sú zodpovedné za adresovanie, smerovanie, riadenie toku a detekciu a opravu chýb – inými slovami, že každý model je nezávislý od používanej siete. Príklady použitia systémových funkcií uvedené v ďalšej časti pre periférne systémy fungujú podobným spôsobom pre systémy ako Newcastle a pre úplne transparentné systémy, o ktorých sa bude diskutovať neskôr; preto ich raz podrobne zvážime a v častiach venovaných iným typom systémov sa zameriame najmä na vlastnosti, ktoré tieto modely odlišujú od všetkých ostatných.

13.1 PERIFERNÉ PROCESORY

Architektúra periférneho systému je znázornená na obrázku 13.2. Cieľom tejto konfigurácie je zlepšiť celkový výkon siete prerozdelením bežiacich procesov medzi CPU a periférne procesory. Každý z periférnych procesorov nemá k dispozícii žiadne iné lokálne periférne zariadenia okrem tých, ktoré potrebuje na komunikáciu s centrálnou procesorovou jednotkou. Súborový systém a všetky zariadenia sú k dispozícii centrálnemu procesoru. Predpokladajme, že všetky používateľské procesy sú vykonávané na periférnom procesore a neprechádzajú medzi periférnymi procesormi; po odovzdaní spracovateľovi na ňom zostanú až do dokončenia. Periférny procesor obsahuje odľahčenú verziu operačného systému, určenú na obsluhu lokálnych volaní do systému, správu prerušení, prideľovanie pamäte, prácu so sieťovými protokolmi a s ovládačom zariadenia pre komunikáciu s centrálnym procesorom.

Keď je systém inicializovaný na centrálnom procesore, jadro načíta lokálny operačný systém na každý z periférnych procesorov cez komunikačné linky. Akýkoľvek proces bežiaci na periférii je spojený so satelitným procesom, ktorý patrí centrálnemu procesoru (pozri); keď proces spustený na periférnom procesore volá systémovú funkciu, ktorá vyžaduje len služby centrálneho procesora, periférny proces komunikuje so svojim satelitom a požiadavka sa odošle na spracovanie centrálnemu procesoru. Satelitný proces vykonáva systémovú funkciu a odosiela výsledky späť do periférneho procesora. Vzťah medzi periférnym procesom a jeho satelitom je podobný vzťahu klient-server, ktorý sme podrobne rozoberali v kapitole 11: periférny proces funguje ako klient svojho satelitu, ktorý podporuje funkcie práce so súborovým systémom. V tomto prípade má proces vzdialeného servera iba jedného klienta. V časti 13.4 sa pozrieme na procesy servera s viacerými klientmi.

Obrázok 13.2. Konfigurácia periférneho systému

Obrázok 13.3. Formáty správ

Keď periférny proces volá systémovú funkciu, ktorá môže byť spracovaná lokálne, jadro nemusí posielať požiadavku do satelitného procesu. Napríklad na získanie ďalšej pamäte môže proces zavolať funkciu sbrk na lokálne vykonanie. Ak sú však potrebné služby centrálneho procesora, napríklad na otvorenie súboru, jadro zakóduje informácie o parametroch odovzdaných volanej funkcii a podmienkach vykonania procesu do správy odoslanej satelitnému procesu (obrázok 13.3). Správa obsahuje znak, z ktorého vyplýva, že funkciu systému vykonáva satelitný proces v mene klienta, parametre odovzdané funkcii a údaje o prostredí vykonávania procesu (napríklad identifikačné kódy používateľa a skupiny), ktoré sú rôzne pre rôzne funkcie. Zvyšok správy tvoria údaje s premenlivou dĺžkou (napríklad názov zloženého súboru alebo údaje, ktoré sa majú zapísať pomocou funkcie zápisu).

Satelitný proces čaká na požiadavky periférneho procesu; keď je prijatá požiadavka, dekóduje správu, určí typ systémovej funkcie, vykoná ju a prevedie výsledky na odpoveď odoslanú do periférneho procesu. Odpoveď okrem výsledkov vykonania systémovej funkcie obsahuje chybové hlásenie (ak existuje), číslo signálu a dátové pole s premenlivou dĺžkou obsahujúce napríklad informácie načítané zo súboru. Periférny proces je pozastavený až do prijatia odpovede, po jej prijatí dešifruje a odošle výsledky používateľovi. Toto je všeobecná schéma spracovania volaní operačného systému; teraz prejdime k podrobnejšiemu zváženiu jednotlivých funkcií.

Aby ste vysvetlili, ako periférny systém funguje, zvážte niekoľko funkcií: getppid, open, write, fork, exit a signal. Funkcia getppid je celkom jednoduchá, pretože sa zaoberá jednoduchými formulármi žiadostí a odpovedí, ktoré sa vymieňajú medzi periférnym zariadením a procesorom. Jadro na periférnom procesore vygeneruje správu, ktorá má znamienko, z ktorého vyplýva, že požadovaná funkcia je funkcia getppid, a odošle požiadavku centrálnemu procesoru. Satelitný proces na centrálnom procesore prečíta správu z periférneho procesora, dešifruje typ systémovej funkcie, vykoná ju a získa identifikátor svojho rodiča. Potom vygeneruje odpoveď a odovzdá ju čakajúcemu periférnemu procesu na druhom konci komunikačnej linky. Keď periférny procesor dostane odpoveď, odovzdá ju procesu, ktorý nazval systémovú funkciu getppid. Ak periférny proces ukladá dáta (napríklad ID procesu rodiča) do lokálnej pamäte, nemusí so svojim spoločníkom vôbec komunikovať.

Ak sa zavolá funkcia otvoreného systému, periférny proces odošle správu svojmu spoločníkovi, ktorá obsahuje názov súboru a ďalšie parametre. Ak je úspešný, sprievodný proces pridelí index a vstupný bod tabuľke súborov, pridelí položku v tabuľke deskriptorov súboru užívateľa vo svojom priestore a vráti deskriptor súboru periférnemu procesu. Celý ten čas na druhom konci komunikačnej linky čaká periférny proces na odpoveď. Nemá k dispozícii žiadne štruktúry, ktoré by uchovávali informácie o otváranom spise; Deskriptor vrátený otvorením je ukazovateľ na položku v sprievodnom procese v tabuľke deskriptorov užívateľského súboru. Výsledky vykonania funkcie sú znázornené na obrázku 13.4.

Obrázok 13.4. Volanie otvorenej funkcie z periférneho procesu

Ak sa uskutoční volanie zápisu systémovej funkcie, periférny procesor vygeneruje správu pozostávajúcu zo znaku funkcie zápisu, deskriptora súboru a množstva údajov, ktoré sa majú zapísať. Potom z priestoru periférneho procesu cez komunikačnú linku skopíruje dáta do satelitného procesu. Satelitný proces dešifruje prijatú správu, načíta údaje z komunikačnej linky a zapíše ich do príslušného súboru (deskriptor obsiahnutý v správe sa používa ako ukazovateľ, na ktorý index a záznam o ktorom v tabuľke súborov sa používa ); všetky tieto akcie sa vykonávajú na centrálnom procesore. Na konci práce satelitný proces odošle do periférneho procesu správu, ktorá potvrdzuje prijatie správy a obsahuje počet bajtov dát, ktoré boli úspešne skopírované do súboru. Operácia čítania je podobná; satelit informuje periférny proces o počte skutočne prečítaných bajtov (v prípade čítania dát z terminálu alebo z kanála sa toto číslo nie vždy zhoduje s množstvom uvedeným v požiadavke). Na vykonanie jednej alebo druhej funkcie môže byť potrebné posielať informačné správy viackrát cez sieť, čo je určené množstvom odoslaných dát a veľkosťou sieťových paketov.

Jedinou funkciou, ktorú je potrebné zmeniť počas behu na CPU, je funkcia vidlicového systému. Keď proces vykoná túto funkciu na CPU, jadro preň vyberie periférny procesor a odošle správu špeciálnemu procesu - serveru, v ktorom ho informuje, že začne uvoľňovať aktuálny proces. Za predpokladu, že server akceptoval požiadavku, jadro použije vidlicu na vytvorenie nového periférneho procesu, pričom pridelí záznam v tabuľke procesov a adresný priestor. Centrálny procesor odovzdá kópiu procesu, ktorý zavolal funkciu vidlice, do periférneho procesora, čím prepíše novo pridelený adresný priestor, vytvorí lokálny satelit na komunikáciu s novým periférnym procesom a odošle správu do periférneho zariadenia na inicializáciu programového počítadla pre nový proces. Satelitný proces (na CPU) je potomkom procesu, ktorý sa nazýva fork; periférny proces je technicky potomok serverového procesu, ale logicky je potomkom procesu, ktorý nazýva funkciu fork. Proces servera nemá žiadne logické spojenie s potomkom, keď sa fork dokončí; jedinou úlohou servera je pomôcť vyložiť dieťa. Vďaka silnému prepojeniu medzi komponentmi systému (periférne procesory nemajú autonómiu), periférny proces a satelitný proces majú rovnaký identifikačný kód. Vzťah medzi procesmi je znázornený na obrázku 13.5: súvislá čiara znázorňuje vzťah rodič-dieťa a bodkovaná čiara znázorňuje vzťah medzi rovesníkmi.

Obrázok 13.5. Vykonávanie funkcie vidlice na CPU

Keď proces vykoná funkciu vidlice na periférnom procesore, odošle správu svojmu satelitu na CPU, ktorý potom vykoná celú sekvenciu akcií opísanú vyššie. Satelit vyberie nový periférny procesor a vykoná potrebné prípravy na uvoľnenie obrazu starého procesu: pošle rodičovskému periférnemu procesu požiadavku na prečítanie jeho obrazu, na čo sa na druhom konci začne prenos požadovaných údajov. komunikačného kanála. Satelit prečíta prenášaný obraz a prepíše ho na periférneho potomka. Po dokončení sťahovania obrazu sa satelitný proces rozvetví, vytvorí svoje dieťa na CPU a odovzdá hodnotu programového počítadla periférnemu potomkovi, aby ten vedel, kde má začať vykonávať. Je zrejmé, že by bolo lepšie, keby bol potomok sprievodného procesu priradený k periférnemu potomkovi ako rodič, ale v našom prípade sú generované procesy schopné bežať aj na iných periférnych procesoroch, nielen na tom, na ktorom sú vytvorené. Vzťah medzi procesmi na konci funkcie vidlice je znázornený na obrázku 13.6. Keď periférny proces dokončí svoju prácu, odošle zodpovedajúcu správu satelitnému procesu a tým sa tiež skončí. Sprievodný proces nemôže spustiť vypnutie.

Obrázok 13.6. Vykonávanie funkcie vidlice na periférnom procesore

V multiprocesorových aj jednoprocesorových systémoch musí proces reagovať na signály rovnakým spôsobom: proces buď dokončí vykonanie funkcie systému pred kontrolou signálov, alebo naopak, po prijatí signálu okamžite opustí pozastavený stav a náhle preruší prácu systémovej funkcie, ak je to v súlade s prioritou, s ktorou bol pozastavený. Keďže satelitný proces vykonáva systémové funkcie v mene periférneho procesu, musí reagovať na signály v koordinácii s periférnym procesom. Ak na jednoprocesorovom systéme signál spôsobí, že proces preruší funkciu, sprievodný proces na viacprocesorovom systéme by sa mal správať rovnakým spôsobom. To isté možno povedať o prípade, keď signál vyzve proces, aby ukončil svoju prácu pomocou funkcie exit: periférny proces sa ukončí a odošle zodpovedajúcu správu satelitnému procesu, ktorý sa samozrejme tiež ukončí.

Keď periférny proces zavolá funkciu signálneho systému, uloží aktuálne informácie do lokálnych tabuliek a odošle správu svojmu satelitu, ktorá ho informuje, či má byť určený signál prijatý alebo ignorovaný. Satelitnému procesu je jedno, či zachytí signál alebo predvolenú akciu. Reakcia procesu na signál závisí od troch faktorov (obrázok 13.7): či signál príde, keď proces vykonáva systémovú funkciu, či sa pomocou funkcie signálu signalizuje ignorovanie signálu, či sa signál vyskytuje na na tom istom periférnom procesore alebo na inom. Prejdime k zvažovaniu rôznych možností.

algoritmus sighandle / * algoritmus spracovania signálu * /

if (aktuálny proces je niečím spoločníkom alebo má prototyp)

if (signál je ignorovaný)

if (signál prišiel počas vykonávania systémovej funkcie)

dať signál pred satelitný proces;

poslať signálnu správu periférnemu procesu;

inak (/ * periférny proces * /

/ * či bol signál prijatý počas vykonávania systémovej funkcie alebo nie * /

poslať signál do satelitného procesu;

algoritmus satellite_end_of_syscall / * ukončenie systémovej funkcie volanej periférnym procesom * /

vstupné informácie: chýbajú

odtlačok: žiadny

if (pri vykonávaní systémovej funkcie bolo prijaté prerušenie)

poslať správu o prerušení, signál do periférneho procesu;

else / * vykonávanie funkcie systému nebolo prerušené * /

poslať odpoveď: povoliť príznak, ktorý ukazuje príchod signálu;

Obrázok 13.7. Spracovanie signálu v periférnom systéme

Predpokladajme, že periférny proces prerušil svoju prácu, zatiaľ čo satelitný proces vykonáva systémovú funkciu v jeho mene. Ak sa signál vyskytuje inde, satelitný proces ho deteguje skôr ako periférny proces. Možné sú tri prípady.

1. Ak sa satelitný proces počas čakania na nejakú udalosť nedostal do pozastaveného stavu, z ktorého by vystúpil po prijatí signálu, vykoná funkciu systému až do konca, výsledky vykonania odošle do periférneho procesu a zobrazí aký signál prijal.

2. Ak proces dostane pokyn ignorovať tento typ signálu, satelit bude pokračovať podľa algoritmu vykonávania systémovej funkcie bez toho, aby opustil pozastavený stav pomocou longjmp. V odpovedi odoslanej do periférneho procesu nebude správa o prijatí signálu.

3. Ak satelitný proces po prijatí signálu preruší vykonávanie systémovej funkcie (pomocou longjmp), informuje o tom periférny proces a oznámi mu číslo signálu.

Periférny proces hľadá informácie o prijatí signálov v prijatej odpovedi a ak nejaké sú, spracuje signály pred ukončením funkcie systému. Správanie procesu vo viacprocesorovom systéme sa teda presne zhoduje s jeho správaním v jednoprocesorovom systéme: buď sa ukončí bez opustenia režimu jadra, alebo zavolá vlastnú funkciu spracovania signálu, alebo signál ignoruje a úspešne dokončí funkciu systému.

Obrázok 13.8. Prerušenie počas vykonávania systémovej funkcie

Predpokladajme napríklad, že periférny proces zavolá funkciu čítania z terminálu pripojeného k centrálnemu procesoru a pozastaví svoju prácu, kým satelitný proces túto funkciu vykoná (obrázok 13.8). Ak používateľ stlačí tlačidlo prerušenia, jadro CPU vyšle signál satelitnému procesu. Ak bol satelit v pozastavenom stave a čakal na časť dát z terminálu, okamžite tento stav opustí a ukončí funkciu čítania. Vo svojej odpovedi na požiadavku z periférneho procesu satelit poskytne chybový kód a číslo signálu zodpovedajúce prerušeniu. Periférny proces analyzuje odpoveď a keďže správa hovorí, že prišlo prerušenie, odošle signál sám sebe. Pred ukončením funkcie čítania periférne jadro skontroluje signalizáciu, deteguje signál prerušenia zo satelitného procesu a spracuje ho ako zvyčajne. Ak periférny proces v dôsledku prijatia signálu prerušenia ukončí svoju prácu pomocou funkcie exit, táto funkcia sa postará o zabitie satelitného procesu. Ak periférny proces zachytí signály prerušenia, zavolá používateľom definovanú funkciu spracovania signálov a po ukončení funkcie čítania vráti používateľovi chybový kód. Na druhej strane, ak satelit vykonáva funkciu štatistického systému v mene periférneho procesu, nepreruší jej vykonávanie, keď prijme signál (funkcia štatistických údajov zaručene ukončí akúkoľvek pauzu, pretože má obmedzený čas čakania na zdroje ). Satelit dokončí vykonanie funkcie a vráti číslo signálu do periférneho procesu. Periférny proces si vyšle signál a prijme ho na výstupe zo systémovej funkcie.

Ak sa na periférnom procesore vyskytne signál počas vykonávania systémovej funkcie, periférny proces nebude vedieť, či sa čoskoro vráti k riadeniu zo satelitného procesu, alebo tento prejde do pozastaveného stavu na neurčito. Periférny proces odošle satelitu špeciálnu správu, ktorá ho informuje o výskyte signálu. Jadro na CPU dešifruje správu a odošle signál satelitu, ktorého reakcia na prijatie signálu je popísaná v predchádzajúcich odsekoch (abnormálne ukončenie vykonávania funkcie alebo jej ukončenie). Periférny proces nemôže poslať správu satelitu priamo, pretože satelit je zaneprázdnený vykonávaním systémovej funkcie a nečíta údaje z komunikačnej linky.

S odkazom na príklad čítania je potrebné poznamenať, že periférny proces netuší, či jeho spoločník čaká na vstup z terminálu alebo vykonáva iné akcie. Periférny proces odošle signálnu správu satelitu: ak je satelit v pozastavenom stave s prerušiteľnou prioritou, okamžite tento stav opustí a ukončí funkciu systému; v opačnom prípade sa funkcia prenesie do úspešného konca.

Nakoniec zvážte prípad príchodu signálu v čase, ktorý nie je spojený s vykonaním systémovej funkcie. Ak signál pochádza z iného procesora, satelit ho najskôr prijme a odošle signálnu správu periférnemu procesu, či už sa signál týka periférneho procesu alebo nie. Periférne jadro správu dešifruje a vyšle signál procesu, ktorý naň zareaguje obvyklým spôsobom. Ak signál pochádza z periférneho procesora, proces vykoná štandardné akcie bez toho, aby sa uchýlil k službám svojho satelitu.

Keď periférny proces odošle signál iným periférnym procesom, zakóduje správu o zabíjaní a odošle ju satelitnému procesu, ktorý lokálne vykoná volanú funkciu. Ak je niektorý z procesov, pre ktoré je signál určený, umiestnený na iných periférnych procesoroch, ich satelity signál prijmú (a budú naň reagovať tak, ako je popísané vyššie).

13.2 TYP KOMUNIKÁCIE NEWCASTLE

V predchádzajúcej časti sme uvažovali o type tesne prepojeného systému, ktorý sa vyznačuje odosielaním všetkých volaní funkcií subsystému správy súborov, ktoré vznikajú na periférnom procesore, na vzdialený (centrálny) procesor. Teraz prejdeme k úvahám o systémoch so slabším pripojením, ktoré pozostávajú zo strojov, ktoré volajú súbory umiestnené na iných strojoch. Napríklad v sieti osobných počítačov a pracovných staníc používatelia často pristupujú k súborom umiestneným na veľkom stroji. V nasledujúcich dvoch častiach sa pozrieme na systémové konfigurácie, v ktorých sa všetky funkcie systému vykonávajú v lokálnych podsystémoch, no zároveň je možné pristupovať k súborom (prostredníctvom funkcií podsystému správy súborov) umiestneným na iných strojoch.

Tieto systémy používajú jednu z nasledujúcich dvoch ciest na identifikáciu odstránených súborov. Na niektorých systémoch sa do zloženého názvu súboru pridáva špeciálny znak: komponent názvu, ktorý predchádza tomuto znaku, identifikuje počítač, zvyšok názvu je súbor na tomto počítači. Tak napríklad príznačné meno

"sftig! / fs1 / mjb / rje"

identifikuje súbor "/ fs1 / mjb / rje" na stroji "sftig". Táto schéma identifikácie súborov sa riadi konvenciou uucp pre prenos súborov medzi systémami podobnými UNIX. V inej schéme sa vymazané súbory identifikujú pridaním špeciálnej predpony k názvu, napríklad:

/../sftig/fs1/mjb/rje

kde "/../" je predpona označujúca, že súbor je vymazaný; druhá súčasť názvu súboru je názov vzdialeného počítača. Táto schéma používa známu syntax názvov súborov UNIX, takže na rozdiel od prvej schémy sa používateľské programy nemusia prispôsobovať používaniu mien s nezvyčajnou konštrukciou (pozri).

Obrázok 13.9. Formulovanie požiadaviek na súborový server (procesor)

Zvyšok tejto časti budeme venovať modelu systému využívajúceho odkaz Newcastle, v ktorom sa jadro nezaoberá rozpoznávaním zmazaných súborov; táto funkcia je úplne priradená podprogramom zo štandardnej knižnice C, ktoré v tomto prípade zohrávajú úlohu systémového rozhrania. Tieto rutiny analyzujú prvú zložku názvu súboru, ktorá v oboch opísaných metódach identifikácie obsahuje znak vzdialenosti súboru. Toto je odklon od rutiny, v ktorej rutiny knižníc neanalyzujú názvy súborov. Obrázok 13.9 ukazuje, ako sú formulované požiadavky na súborový server. Ak je súbor lokálny, jadro lokálneho systému spracuje požiadavku normálne. Zvážte opačný prípad:

otvoriť ("/../ sftig / fs1 / mjb / rje / súbor", O_RDONLY);

Otvorený podprogram v knižnici C analyzuje prvé dve zložky rozlíšeného súboru a vie, že má hľadať súbor na vzdialenom počítači "sftig". Aby mal podprogram informáciu o tom, či mal proces predtým spojenie s daným strojom, spustí špeciálnu štruktúru, v ktorej si túto skutočnosť zapamätá a v prípade zápornej odpovede nadviaže spojenie so súborovým serverom bežiacim na vzdialenom stroji. Keď proces sformuluje svoju prvú požiadavku na vzdialené spracovanie, vzdialený server požiadavku potvrdí, v prípade potreby zaznamená do polí identifikačných kódov používateľa a skupiny a vytvorí satelitný proces, ktorý bude konať v mene klientskeho procesu.

Na splnenie požiadaviek klienta musí mať satelit na vzdialenom počítači rovnaké oprávnenia na súbory ako klient. Inými slovami, používateľ „mjb“ musí mať rovnaké prístupové práva k vzdialeným aj lokálnym súborom. Bohužiaľ je možné, že identifikačný kód klienta „mjb“ sa môže zhodovať s identifikačným kódom iného klienta na vzdialenom počítači. Správcovia systému na strojoch bežiacich v sieti by teda mali buď zabezpečiť, aby bol každému používateľovi pridelený identifikačný kód, ktorý je jedinečný pre celú sieť, alebo vykonať konverziu kódu v čase formulovania požiadavky sieťovej služby. Ak tak neurobíte, sprievodný proces bude mať práva iného klienta na vzdialenom počítači.

Delikátnejším problémom je získanie práv superužívateľa v súvislosti s prácou so vzdialenými súbormi. Na jednej strane by klient superužívateľa nemal mať rovnaké práva na vzdialený systém, aby nezavádzal ovládacie prvky zabezpečenia vzdialeného systému. Na druhej strane, niektoré programy, ak im nebudú udelené práva superužívateľa, jednoducho nebudú môcť fungovať. Príkladom takéhoto programu je program mkdir (pozri kapitolu 7), ktorý vytvorí nový adresár. Vzdialený systém by klientovi nedovolil vytvoriť nový adresár, pretože práva superužívateľa nie sú účinné pri vymazaní. Problém vytvárania vzdialených adresárov slúži ako vážny dôvod pre revíziu systémovej funkcie mkdir smerom k rozšíreniu jej možností pri automatickom nadväzovaní všetkých spojení potrebných pre užívateľa. Stále je však bežným problémom, že programy setuid (ako je program mkdir) získavajú privilégiá superužívateľa nad vzdialenými súbormi. Možno najlepším riešením tohto problému by bolo nastavenie dodatočných charakteristík pre súbory, ktoré popisujú prístup vzdialených superužívateľov k nim; Žiaľ, vyžadovalo by si to zmeny v štruktúre indexu disku (v zmysle pridávania nových polí) a vytvorilo by to príliš veľa neporiadku v existujúcich systémoch.

Ak je otvorený podprogram úspešný, lokálna knižnica o tom zanechá zodpovedajúcu poznámku v užívateľsky dostupnej štruktúre obsahujúcej adresu sieťového uzla, ID procesu satelitného procesu, deskriptor súboru a ďalšie podobné informácie. Knižničné rutiny čítania a zápisu určujú na základe deskriptora súboru, či je súbor vymazaný, a ak áno, pošlú správu na satelit. Klientsky proces interaguje so svojím spoločníkom vo všetkých prípadoch prístupu k systémovým funkciám, ktoré vyžadujú služby vzdialeného počítača. Ak proces pristupuje k dvom súborom umiestneným na rovnakom vzdialenom počítači, používa jeden satelit, ale ak sú súbory umiestnené na rôznych počítačoch, používajú sa už dva satelity: jeden na každom počítači. Dva satelity sa používajú aj vtedy, keď dva procesy pristupujú k súboru na vzdialenom počítači. Vyvolaním systémovej funkcie cez satelit proces vygeneruje správu, ktorá obsahuje číslo funkcie, názov vyhľadávacej cesty a ďalšie potrebné informácie, podobné tým, ktoré sú zahrnuté v štruktúre správy v systéme s periférnymi procesormi.

Mechanizmus vykonávania operácií v aktuálnom adresári je zložitejší. Keď proces vyberie vzdialený adresár ako aktuálny, rutina knižnice odošle správu satelitu, ktorý zmení aktuálny adresár a rutina si zapamätá, že adresár je vymazaný. Vo všetkých prípadoch, kde názov cesty vyhľadávania začína iným znakom ako lomkou (/), podprogram odošle názov vzdialenému počítaču, kam ho satelitný proces nasmeruje z aktuálneho adresára. Ak je aktuálny adresár lokálny, rutina jednoducho odovzdá názov vyhľadávacej cesty jadru lokálneho systému. Funkcia chroot systému vo vzdialenom adresári je podobná, ale pre lokálne jadro zostáva nepovšimnutá; presne povedané, proces môže túto operáciu ignorovať, pretože jej vykonanie zaznamenáva iba knižnica.

Keď proces zavolá fork, príslušná rutina knižnice odošle správy každému satelitu. Satelitné procesy sa rozvetvujú a posielajú svoje podriadené identifikátory rodičovskému klientovi. Klientsky proces spúšťa funkciu fork system, ktorá prenáša riadenie na potomka, ktorý vytvorí; miestne dieťa je v dialógu so vzdialeným satelitným dieťaťom, ktorého adresy sú uložené rutinou knižnice. Táto interpretácia funkcie vidlice uľahčuje satelitným procesom ovládanie otvorených súborov a aktuálnych adresárov. Keď sa proces práce so vzdialenými súbormi ukončí (zavolaním funkcie exit), podprogram odošle správy všetkým svojim vzdialeným satelitom, aby urobili to isté, keď správu dostanú. Niektoré aspekty implementácie funkcií exec a exit systému sú diskutované v cvičeniach.

Výhodou prepojenia v Newcastle je, že prístup procesu k vzdialeným súborom sa stáva transparentným (pre používateľa neviditeľným) bez toho, aby bolo potrebné vykonať akékoľvek zmeny v jadre systému. Tento vývoj má však množstvo nevýhod. Po prvé, počas jeho implementácie je možný pokles výkonu systému. Vďaka použitiu rozšírenej knižnice C sa veľkosť pamäte používanej každým procesom zvyšuje, aj keď proces nepristupuje k vzdialeným súborom; knižnica duplikuje funkcie jadra a vyžaduje viac miesta v pamäti. Zväčšenie veľkosti procesov predlžuje dobu spustenia a môže spôsobiť viac sporov o pamäťové zdroje, čím sa vytvárajú podmienky pre častejšie vykladanie a stránkovanie úloh. Lokálne požiadavky sa budú vykonávať pomalšie v dôsledku predĺženia trvania každého volania do jadra a môže sa spomaliť aj spracovanie vzdialených požiadaviek, zvyšujú sa náklady na ich odosielanie cez sieť. Dodatočné spracovanie vzdialených požiadaviek na užívateľskej úrovni zvyšuje počet operácií prepínania kontextu, vykladania a swapovania. Nakoniec, aby ste mali prístup k vzdialeným súborom, programy musia byť prekompilované pomocou nových knižníc; staré programy a dodané objektové moduly bez neho nebudú môcť pracovať so vzdialenými súbormi. Všetky tieto nevýhody v systéme opísanom v nasledujúcej časti chýbajú.

13.3 „TRANSPARENTNÉ“ DISTRIBUOVANÉ SÚBOROVÉ SYSTÉMY

Pojem „transparentná alokácia“ znamená, že používatelia na jednom počítači môžu pristupovať k súborom na inom stroji bez toho, aby si uvedomili, že prekračujú hranice stroja, rovnako ako na svojom stroji, keď prechádzajú z jedného súborového systému na iný a prechádzajú cez body pripojenia. Názvy, ktorými procesy odkazujú na súbory umiestnené na vzdialených počítačoch, sú podobné ako názvy lokálnych súborov: nie sú v nich žiadne charakteristické znaky. V konfigurácii znázornenej na obrázku 13.10 je adresár „/ usr / src“ patriaci stroju B „pripojený“ do adresára „/ usr / src“ patriacemu stroju A. rovnaký systémový zdrojový kód, ktorý sa tradične nachádza v „/ adresár usr / src". Používatelia spustení na počítači A môžu pristupovať k súborom umiestneným na počítači B pomocou obvyklej syntaxe zápisu názvov súborov (napríklad: "/usr/src/cmd/login.c") a samotné jadro rozhoduje, či je súbor vzdialený alebo lokálny. . Používatelia spustení na počítači B majú prístup k svojim lokálnym súborom (nevedomí, že používatelia počítača A môžu pristupovať k tým istým súborom), ale zase nemajú prístup k súborom umiestneným na počítači A. Samozrejme, sú možné aj iné možnosti, napr. najmä tie, v ktorých sú všetky vzdialené systémy pripojené v koreňovom adresári lokálneho systému, takže používatelia majú prístup ku všetkým súborom na všetkých systémoch.

Obrázok 13.10. Súborové systémy po vzdialenom pripojení

Podobnosti medzi pripájaním lokálnych súborových systémov a umožnením prístupu k vzdialeným súborovým systémom podnietili prispôsobenie funkcie pripojenia vzdialeným súborovým systémom. V tomto prípade má jadro k dispozícii tabuľku pripojenia rozšíreného formátu. Vykonaním funkcie pripojenia jadro organizuje sieťové pripojenie so vzdialeným počítačom a ukladá informácie charakterizujúce toto pripojenie do tabuľky pripojenia.

Zaujímavý problém súvisí s názvami ciest, ktoré obsahujú „...“. Ak proces vytvorí aktuálny adresár zo vzdialeného súborového systému, potom použitie znakov „..“ v názve s väčšou pravdepodobnosťou vráti proces do lokálneho súborového systému, a nie prístup k súborom nad aktuálnym adresárom. Vráťme sa znova k obrázku 13.10 a všimnite si, že keď proces patriaci stroju A, ktorý predtým vybral aktuálny adresár "/ usr / src / cmd" umiestnený vo vzdialenom súborovom systéme, vykoná príkaz

aktuálny adresár bude koreňový adresár stroja A, nie stroja B. Algoritmus namei v jadre vzdialeného systému po prijatí sekvencie znakov „..“ skontroluje, či je volajúci proces agentom klientskeho procesu a ak áno, nastaví, či klient považuje aktuálny pracovný adresár za koreňový adresár vzdialeného súborového systému.

Komunikácia so vzdialeným počítačom má jednu z dvoch foriem: vzdialené volanie procedúry alebo vzdialené volanie systémovej funkcie. V prvom formulári každá procedúra jadra zaoberajúca sa indexmi kontroluje, či index ukazuje na vzdialený súbor, a ak áno, odošle vzdialenému počítaču požiadavku na vykonanie špecifikovanej operácie. Táto schéma prirodzene zapadá do abstraktnej štruktúry podpory súborových systémov rôznych typov, opísanej v záverečnej časti kapitoly 5. Prístup k vzdialenému súboru teda môže iniciovať prenos niekoľkých správ po sieti, ktorých počet je určený počtom implicitných operácií so súborom, so zodpovedajúcim zvýšením času odozvy na požiadavku, berúc do úvahy čakaciu dobu akceptovanú v sieti. Každá sada vzdialených operácií obsahuje minimálne akcie na uzamknutie indexu, počítanie referencií atď. Pre zlepšenie modelu boli navrhnuté rôzne optimalizačné riešenia súvisiace so spojením viacerých operácií do jedného dotazu (správy) a uložením najdôležitejších údajov do vyrovnávacej pamäte (cm. ).

Obrázok 13.11. Otvorenie vzdialeného súboru

Zvážte proces, ktorý otvorí vzdialený súbor "/usr/src/cmd/login.c", kde "src" je bod pripojenia. Analýzou názvu súboru (pomocou schémy namei-iget) jadro zistí, že súbor je vymazaný a odošle požiadavku na hostiteľský počítač, aby získal uzamknutý index. Po prijatí požadovanej odpovede lokálne jadro vytvorí kópiu indexu v pamäti zodpovedajúceho vzdialenému súboru. Potom jadro skontroluje potrebné prístupové práva k súboru (napríklad na čítanie) odoslaním ďalšej správy na vzdialený počítač. Otvorený algoritmus pokračuje v úplnom súlade s plánom načrtnutým v kapitole 5 a podľa potreby odosiela správy vzdialenému počítaču, kým sa algoritmus nedokončí a index sa neuvoľní. Vzťah medzi dátovými štruktúrami jadra po dokončení otvoreného algoritmu je znázornený na obrázku 13.11.

Ak klient zavolá funkciu čítania systému, jadro klienta uzamkne lokálny index, zablokuje vzdialený index, požiada o čítanie, skopíruje údaje do lokálnej pamäte, vydá požiadavku na uvoľnenie vzdialeného indexu a uvoľní lokálny index. . Táto schéma je v súlade so sémantikou existujúceho jednoprocesorového jadra, ale frekvencia používania siete (viacnásobné volania každej systémovej funkcie) znižuje výkon celého systému. Na zníženie toku správ v sieti je však možné spojiť viacero operácií do jednej požiadavky. V príklade s funkciou čítania môže klient poslať serveru jednu všeobecnú požiadavku na „čítanie“ a server sa sám rozhodne, že po spustení index uchopí a uvoľní. Zníženie sieťovej prevádzky možno dosiahnuť aj použitím vzdialených vyrovnávacích pamätí (ako sme diskutovali vyššie), ale je potrebné dbať na to, aby sa funkcie systémových súborov používajúce tieto vyrovnávacie pamäte vykonávali správne.

V druhej forme komunikácie so vzdialeným počítačom (volanie funkcie vzdialeného systému) lokálne jadro zistí, že systémová funkcia súvisí so vzdialeným súborom a odošle parametre špecifikované vo svojom volaní do vzdialeného systému, ktorý vykoná a vráti výsledky klientovi. Klientsky počítač dostane výsledky vykonania funkcie a ukončí stav volania. Väčšinu systémových funkcií je možné vykonať pomocou iba jednej sieťovej požiadavky a prijatia odpovede po primeranom čase, ale nie všetky funkcie zapadajú do tohto modelu. Takže napríklad po prijatí určitých signálov jadro vytvorí súbor pre proces s názvom „core“ (kapitola 7). Vytvorenie tohto súboru nie je spojené s konkrétnou funkciou systému, ale končí vykonaním niekoľkých operácií, ako je vytvorenie súboru, kontrola povolení a vykonanie série zápisov.

V prípade funkcie otvoreného systému požiadavka na vykonanie funkcie odoslaná na vzdialený počítač obsahuje časť názvu súboru, ktorá zostala po vylúčení komponentov názvu cesty vyhľadávania, ktoré rozlišujú vzdialený súbor, ako aj rôzne príznaky. V predchádzajúcom príklade otvorenia súboru „/usr/src/cmd/login.c“ odošle jadro vzdialenému počítaču názov „cmd / login.c“. Správa tiež obsahuje prihlasovacie údaje, ako sú identifikačné kódy používateľa a skupiny, ktoré sú potrebné na overenie povolení súboru na vzdialenom počítači. Ak je zo vzdialeného počítača prijatá odpoveď označujúca úspešnú funkciu otvorenia, lokálne jadro načíta voľný index v pamäti lokálneho počítača a označí ho ako index vzdialeného súboru, uloží informácie o vzdialenom počítači a vzdialenom indexe a rutinne prideľuje novú položku v tabuľke súborov. V porovnaní so skutočným indexom na vzdialenom počítači je index vlastnený lokálnym počítačom formálny a neporušuje konfiguráciu modelu, ktorá je vo všeobecnosti rovnaká ako konfigurácia použitá pri volaní vzdialenej procedúry (obrázok 13.11). Ak funkcia volaná procesom pristupuje k vzdialenému súboru pomocou jeho deskriptora, lokálne jadro vie z (lokálneho) indexu, že súbor je vzdialený, sformuluje požiadavku, ktorá obsahuje volanú funkciu, a odošle ju vzdialenému počítaču. Požiadavka obsahuje ukazovateľ na vzdialený index, pomocou ktorého môže satelitný proces identifikovať samotný vzdialený súbor.

Po prijatí výsledku vykonania akejkoľvek systémovej funkcie sa jadro môže uchýliť k službám špeciálneho programu na jeho spracovanie (po dokončení ktorého jadro dokončí prácu s funkciou), pretože lokálne spracovanie výsledkov sa používa v jednoprocesorovom systéme nie je vždy vhodné pre systém s viacerými procesormi. V dôsledku toho sú možné zmeny v sémantike systémových algoritmov, ktorých cieľom je poskytnúť podporu pre vykonávanie funkcií vzdialeného systému. Zároveň však v sieti cirkuluje minimálny tok správ, ktorý zabezpečuje minimálnu dobu odozvy systému na prichádzajúce požiadavky.

13.4 DISTRIBUOVANÝ MODEL BEZ PROCESOV PRENOSU

Použitie prenosových procesov (satelitných procesov) v transparentnom distribuovanom systéme uľahčuje sledovanie vymazaných súborov, ale procesná tabuľka vzdialeného systému je preťažená satelitnými procesmi, ktoré sú väčšinu času nečinné. V iných schémach sa na spracovanie vzdialených požiadaviek používajú špeciálne serverové procesy (pozri a). Vzdialený systém má množinu (pool) serverových procesov, ktoré z času na čas priraďuje na spracovanie prichádzajúcich vzdialených požiadaviek. Po spracovaní požiadavky sa proces servera vráti do oblasti a vstúpi do stavu pripraveného na spracovanie ďalších požiadaviek. Server neukladá užívateľský kontext medzi dvoma hovormi, pretože dokáže spracovať požiadavky z niekoľkých procesov naraz. Preto každá správa prichádzajúca z klientskeho procesu musí obsahovať informácie o svojom vykonávacom prostredí, konkrétne: identifikačné kódy používateľa, aktuálny adresár, signály atď.

Keď proces otvorí vzdialený súbor, vzdialené jadro priradí index pre následné odkazy na súbor. Lokálny počítač udržiava vlastnú tabuľku deskriptorov súborov, tabuľku súborov a tabuľku indexov s pravidelnou sadou záznamov, so záznamom tabuľky indexov identifikujúcim vzdialený počítač a vzdialený index. V prípadoch, keď systémová funkcia (napríklad čítanie) používa deskriptor súboru, jadro odošle správu ukazujúcu na predtým priradený vzdialený index a prenesie informácie súvisiace s procesom: identifikačný kód používateľa, maximálna veľkosť súboru atď., počítač má serverový proces, ktorý má k dispozícii, má interakcia s klientom formu opísanú vyššie, avšak spojenie medzi klientom a serverom je nadviazané len na dobu fungovania systému.

Používanie serverov namiesto satelitných procesov môže sťažiť správu dátovej prevádzky, signálov a vzdialených zariadení. Veľké množstvo požiadaviek na vzdialený počítač pri absencii dostatočného počtu serverov by malo byť zaradené do frontu. Vyžaduje si to protokol vyššej vrstvy ako protokol používaný v hlavnej sieti. Na druhej strane v satelitnom modeli odpadá presýtenie, pretože všetky požiadavky klientov sa spracúvajú synchrónne. Klient môže mať maximálne jednu nevybavenú požiadavku.

Spracovanie signálov, ktoré prerušujú vykonávanie systémovej funkcie, je komplikované aj pri použití serverov, pretože vzdialený stroj musí hľadať vhodný server obsluhujúci výkon funkcie. Je dokonca možné, že z dôvodu vyťaženosti všetkých serverov čaká na spracovanie požiadavka na funkciu systému. Podmienky pre vznik konkurencie vznikajú aj vtedy, keď server vráti výsledok funkcie systému volajúcemu procesu a odpoveď servera zahŕňa odoslanie zodpovedajúcej signalizačnej správy cez sieť. Každá správa musí byť označená, aby ju vzdialený systém mohol rozpoznať a v prípade potreby ukončiť procesy servera. Pri použití satelitov sa automaticky identifikuje proces, ktorý rieši splnenie požiadavky klienta a v prípade príchodu signálu nie je ťažké skontrolovať, či bola požiadavka spracovaná alebo nie.

Nakoniec, ak systémová funkcia volaná klientom spôsobí pozastavenie servera na neurčito (napríklad pri čítaní údajov zo vzdialeného terminálu), server nemôže spracovať ďalšie požiadavky na uvoľnenie serverovej oblasti. Ak niekoľko procesov pristupuje k vzdialeným zariadeniam naraz a ak je počet serverov obmedzený zhora, existuje celkom hmatateľné úzke miesto. Toto sa nestáva so satelitmi, pretože satelit je pridelený každému klientskemu procesu. Ďalší problém s používaním serverov pre vzdialené zariadenia bude popísaný v cvičení 13.14.

Napriek výhodám, ktoré použitie satelitných procesov poskytuje, potreba voľných záznamov v tabuľke procesov sa v praxi stáva natoľko akútnou, že vo väčšine prípadov sa na spracovanie vzdialených požiadaviek stále využívajú služby serverových procesov.

Obrázok 13.12. Koncepčný diagram interakcie so vzdialenými súbormi na úrovni jadra

13.5 ZÁVERY

V tejto kapitole sme zvážili tri schémy práce so súbormi umiestnenými na vzdialených počítačoch, pričom vzdialené súborové systémy považujeme za rozšírenie lokálneho. Architektonické rozdiely medzi týmito rozloženiami sú znázornené na obrázku 13.12. Všetky sa zasa líšia od viacprocesorových systémov popísaných v predchádzajúcej kapitole tým, že procesory tu nezdieľajú fyzickú pamäť. Periférny procesorový systém pozostáva z tesne prepojenej sady procesorov, ktoré zdieľajú súborové prostriedky centrálneho procesora. Pripojenie typu Newcastle poskytuje skrytý („transparentný“) prístup k vzdialeným súborom, nie však pomocou jadra operačného systému, ale pomocou špeciálnej knižnice C. Z tohto dôvodu musia byť všetky programy, ktoré majú v úmysle používať tento typ prepojenia, prekompilované, čo je vo všeobecnosti vážnou nevýhodou tejto schémy. Vzdialenosť súboru je indikovaná pomocou špeciálnej sekvencie znakov popisujúcich stroj, na ktorom sa súbor nachádza, a to je ďalší faktor obmedzujúci prenosnosť programov.

V transparentných distribuovaných systémoch sa na prístup k vzdialeným súborom používa modifikácia funkcie mount systému. Indexy na lokálnom systéme sú označené ako vzdialené súbory a lokálne jadro odošle správu vzdialenému systému s popisom požadovanej systémovej funkcie, jej parametrov a vzdialeného indexu. Komunikácia v „transparentnom“ distribuovanom systéme je podporovaná v dvoch formách: vo forme volania na vzdialenú procedúru (na vzdialený stroj je odoslaná správa obsahujúca zoznam operácií spojených s indexom) a vo forme volania. na funkciu vzdialeného systému (správa popisuje požadovanú funkciu). Záverečná časť kapitoly rozoberá otázky súvisiace so spracovaním vzdialených požiadaviek pomocou satelitných procesov a serverov.

13.6 CVIČENIA

*1. Popíšte implementáciu funkcie výstupného systému v systéme s periférnymi procesormi. Aký je rozdiel medzi týmto prípadom a tým, keď sa proces ukončí po prijatí nezachyteného signálu? Ako by malo jadro vypísať obsah pamäte?

2. Procesy nemôžu ignorovať signály SIGKILL; Vysvetlite, čo sa stane v periférnom systéme, keď proces prijme takýto signál.

* 3. Popíšte implementáciu systémovej funkcie exec na systéme s periférnymi procesormi.

*4. Ako by mal centrálny procesor rozdeliť procesy medzi periférne procesory, aby sa vyrovnala celková záťaž?

*5. Čo sa stane, ak periférny procesor nemá dostatok pamäte na uloženie všetkých procesov, ktoré sú naň uložené? Ako by malo prebiehať vykladanie a swapovanie procesov v sieti?

6. Zvážte systém, v ktorom sa odosielajú požiadavky na vzdialený súborový server, ak sa v názve súboru nachádza špeciálna predpona. Nechajte proces volať execl ("/../ sftig / bin / sh", "sh", 0); Spustiteľný súbor je na vzdialenom počítači, ale musí bežať na lokálnom systéme. Vysvetlite, ako sa vzdialený modul migruje do lokálneho systému.

7. Ak administrátor potrebuje pridať nové počítače do existujúceho systému s pripojením ako Newcastle, aký je potom najlepší spôsob, ako o tom informovať moduly knižnice C?

*osem. Počas vykonávania funkcie exec jadro prepíše adresný priestor procesu vrátane knižničných tabuliek používaných odkazom Newcastle na sledovanie odkazov na vzdialené súbory. Po vykonaní funkcie si proces musí zachovať možnosť prístupu k týmto súborom prostredníctvom ich starých deskriptorov. Popíšte implementáciu tohto bodu.

*deväť. Ako je uvedené v sekcii 13.2, volanie funkcie ukončenia systému na systémoch s pripojením Newcastle má za následok odoslanie správy do sprievodného procesu, čo ho prinúti ukončiť. Toto sa vykonáva na úrovni knižničných rutín. Čo sa stane, keď lokálny proces dostane signál, ktorý mu povie, aby skončil v režime jadra?

*desať. V systéme s odkazom na Newcastle, kde sú vzdialené súbory identifikované predponou názvu so špeciálnou predponou, ako môže používateľ, ktorý zadá „..“ (nadradený adresár) ako komponent názvu súboru, prejsť cez vzdialený bod pripojenia?

11. Zo 7. kapitoly vieme, že rôzne signály spôsobujú, že proces vysype obsah pamäte do aktuálneho adresára. Čo by sa malo stať, ak je aktuálny adresár zo vzdialeného súborového systému? Akú odpoveď by ste dali, keby systém využíval vzťah ako Newcastle?

*12. Aké dôsledky pre miestne procesy by to malo, keby boli zo systému odstránené všetky satelitné alebo serverové procesy?

*13. Zvážte, ako implementovať linkový algoritmus v transparentnom distribuovanom systéme, ktorého parametrami môžu byť dva vzdialené názvy súborov, ako aj algoritmus exec spojený s vykonávaním niekoľkých interných operácií čítania. Zvážte dve formy komunikácie: vzdialené volanie procedúry a vzdialené volanie systémovej funkcie.

*štrnásť. Pri prístupe k zariadeniu môže proces servera vstúpiť do pozastaveného stavu, z ktorého ho vyradí ovládač zariadenia. Prirodzene, ak je počet serverov obmedzený, systém už nebude schopný uspokojiť požiadavky lokálneho počítača. Vymyslite spoľahlivú schému, podľa ktorej nie sú všetky procesy servera pozastavené počas čakania na dokončenie I/O súvisiacich so zariadením. Funkcia systému sa neukončí, kým sú všetky servery zaneprázdnené.

Obrázok 13.13. Konfigurácia terminálového servera

*15. Keď sa užívateľ prihlási do systému, disciplína terminálovej linky uloží informáciu, že terminál je operátorský terminál, ktorý vedie skupinu procesov. Z tohto dôvodu, keď používateľ stlačí tlačidlo "break" na klávesnici terminálu, všetky procesy v skupine dostanú signál prerušenia. Zvážte konfiguráciu systému, v ktorej sú všetky terminály fyzicky pripojené k jednému stroju, ale registrácia používateľa je logicky implementovaná na iných strojoch (obrázok 13.13). V každom prípade systém vytvorí proces getty pre vzdialený terminál. Ak požiadavky na vzdialený systém spracováva množina serverových procesov, všimnite si, že po vykonaní otvorenej procedúry server prestane čakať na pripojenie. Po dokončení funkcie otvorenia sa server vráti späť do oblasti serverov a preruší svoje pripojenie k terminálu. Ako sa spustí signál prerušenia stlačením klávesu „break“ odoslaný na adresy procesov zaradených do rovnakej skupiny?

*16. Zdieľanie pamäte je vlastnosť vlastná lokálnym počítačom. Z logického hľadiska je možné pridelenie spoločnej oblasti fyzickej pamäte (lokálnej alebo vzdialenej) vykonať pre procesy patriace rôznym strojom. Popíšte implementáciu tohto bodu.

* 17. Proces stránkovania a stránkovacie algoritmy diskutované v kapitole 9 predpokladajú použitie lokálneho pagera. Aké zmeny by sa mali vykonať v týchto algoritmoch, aby mohli podporovať zariadenia na vzdialené vykladanie?

*osemnásť. Predpokladajme, že vzdialený počítač (alebo sieť) zaznamená fatálne zlyhanie a protokol lokálnej sieťovej vrstvy túto skutočnosť zaznamená. Vytvorte schému obnovy pre lokálny systém, ktorý odosiela požiadavky na vzdialený server. Okrem toho vytvorte schému obnovy pre serverový systém, ktorý stratil kontakt s klientmi.

*19. Keď proces pristupuje k vzdialenému súboru, je možné, že proces pri hľadaní súboru prejde viacerými počítačmi. Ako príklad si vezmite názov "/ usr / src / uts / 3b2 / os", kde "/ usr" je adresár patriaci počítaču A, "/ usr / src" je bod pripojenia koreňového adresára počítača B, " / usr / src / uts / 3b2 "je bod pripojenia koreňového adresára počítača C. Prechod cez viacero počítačov do konečného cieľa sa nazýva multihop. Ak však medzi strojmi A a C existuje priame sieťové spojenie, odosielanie údajov cez stroj B by bolo neefektívne. Popíšte vlastnosti implementácie „multishoppingu“ v systéme s pripojením Newcastle a v „transparentnom“ distribuovanom systéme.

V súčasnosti majú všetky IS vyvinuté na komerčné účely distribuovanú architektúru, čo znamená použitie globálnych a/alebo lokálnych sietí.

Historicky sa ako prvá rozšírila architektúra súborového servera, pretože jej logika je jednoduchá a na takúto architektúru je najjednoduchšie preniesť už používané IS. Potom sa pretransformovala na architektúru server-klient, ktorú možno interpretovať ako jej logické pokračovanie. Moderné systémy používané v globálnej sieti INTERNET sa týkajú najmä architektúry distribuovaných objektov (pozri obr. III‑15 )

IS si možno predstaviť pozostávajúci z nasledujúcich komponentov (obr. III-16)

III.03.2. a Aplikácie súborového servera.

Ide o historicky prvú distribuovanú architektúru (obr. III-17). Je organizovaný veľmi jednoducho: na serveri sú len dáta a všetko ostatné patrí klientskemu stroju. Keďže lokálne siete sú pomerne lacné a vzhľadom na to, že pri takejto architektúre je aplikačný softvér autonómny, dnes sa takáto architektúra často používa. Dá sa povedať, že ide o variant architektúry klient-server, v ktorej sú na serveri umiestnené iba dátové súbory. Rôzne osobné počítače interagujú iba prostredníctvom spoločného úložiska dát, preto je najjednoduchšie prispôsobiť programy napísané pre jeden počítač takejto architektúre.

výhody:

Výhody architektúry súborového servera:

Jednoduchosť organizácie;

Nie je v rozpore s nevyhnutnými požiadavkami na databázu na zachovanie integrity a spoľahlivosti.

preťaženie siete;

Nepredvídateľná reakcia na požiadavku.

Tieto nevýhody sú vysvetlené skutočnosťou, že každá požiadavka do databázy vedie k prenosu značného množstva informácií cez sieť. Napríklad, ak chcete vybrať jeden alebo niekoľko riadkov z tabuliek, celá tabuľka sa stiahne do klientskeho počítača a DBMS tam už vyberie. Významná sieťová prevádzka je spojená najmä s organizáciou vzdialeného prístupu k databáze.

III.03.2. b Aplikácie klient-server.

V tomto prípade existuje rozdelenie zodpovedností medzi server a klient. V závislosti od toho, ako sú oddelené, rozlišujte tuku a tenkého klienta.

V modeli tenkého klienta sa všetka práca s aplikáciami a správa údajov vykonáva na serveri. Používateľské rozhranie v týchto systémoch „migruje“ na osobný počítač a samotná softvérová aplikácia plní funkcie servera, t.j. spúšťa všetky aplikačné procesy a spravuje dáta. Model tenkého klienta možno implementovať aj tam, kde sú klientmi počítače alebo pracovné stanice. Na sieťových zariadeniach je prevádzkovaný internetový prehliadač a používateľské rozhranie implementované v systéme.

Hlavná chyba modely tenkých klientov - vysoké zaťaženie servera a siete. Všetky výpočty sa vykonávajú na serveri, čo môže viesť k značnému sieťovému zaťaženiu medzi klientom a serverom. V moderných počítačoch je dostatok výpočtového výkonu, ale v modeli / tenkom klientovi banky sa prakticky nepoužíva

Naproti tomu model hrubého klienta využíva výpočtový výkon lokálnych počítačov: samotná aplikácia je umiestnená na klientskom počítači. Príkladom tohto typu architektúry sú ATM systémy, v ktorých je ATM klientom a server je centrálnym počítačom obsluhujúcim databázu zákazníckych účtov.

III.03.2. c Dvoj- a trojvrstvová architektúra klient-server.

Všetky vyššie diskutované architektúry sú dvojvrstvové. Rozlišujú medzi úrovňou klienta a úrovňou servera. Presne povedané, IC pozostáva z troch logických úrovní:

· Používateľská úroveň;

Úroveň aplikácie:

· Dátová vrstva.

Preto v dvojvrstvovom modeli, kde sú zahrnuté iba dve vrstvy, sa vyskytujú problémy so škálovateľnosťou a výkonom, ak sa zvolí model tenkého klienta, alebo problémy so správou systému, ak sa zvolí model hrubého klienta. Týmto problémom sa dá predísť, ak použijeme model pozostávajúci z troch úrovní, pričom dve z nich sú servery (obr. III-21).

Dátový server

V skutočnosti sa aplikačný server a údajový server môžu nachádzať na rovnakom počítači, ale nemôžu navzájom vykonávať funkcie. Na trojvrstvovom modeli je pekné, že logicky oddeľuje vykonávanie aplikácií a správu údajov.

Tabuľka III-5 Aplikácia rôznych typov architektúr

Architektúra	Aplikácia
Dvojvrstvový tenký klient	1 Staršie systémy, v ktorých nie je vhodné oddeľovať vykonávanie aplikácií a správu údajov. 2 Výpočtovo náročné aplikácie s malou správou údajov. 3 Aplikácie s veľkým množstvom údajov, ale malým počtom výpočtov.
Dvojvrstvový hrubý klient	1 Aplikácie, kde užívateľ vyžaduje intenzívne spracovanie dát, t.j. vizualizáciu dát. 2 Aplikácie s relatívne konštantnou sadou užívateľských funkcií aplikované na dobre spravované systémové prostredie.
Trojvrstvový server-klient	1 Veľké aplikácie s bunkami a tisíckami klientov 2 Aplikácie, v ktorých sa často menia údaje aj metódy spracovania. 3 Aplikácie, ktoré integrujú údaje z viacerých zdrojov.

Tento model je vhodný pre mnoho typov aplikácií, no obmedzuje vývojárov IS, ktorí sa musia rozhodnúť, kde budú poskytovať služby, poskytovať podporu škálovateľnosti a vyvíjať nástroje na pripojenie nových zákazníkov.

III.03.2. d Architektúra distribuovaných objektov.

Všeobecnejší prístup poskytuje architektúra distribuovaných objektov, ktorej hlavnými komponentmi sú objekty. Poskytujú súbor služieb prostredníctvom svojich rozhraní. Ostatné objekty odosielajú požiadavky bez rozlišovania medzi klientom a serverom. Objekty môžu byť umiestnené na rôznych počítačoch v sieti a interagovať cez middleware, podobne ako systémová zbernica, ktorá umožňuje prepojiť rôzne zariadenia a podporovať komunikáciu medzi hardvérovými zariadeniami.

…

Správca ovládačov ODBC

Vodič 1

Vodič K

DB 1

DB K

Práca s SQL

…

Architektúra ODBC obsahuje komponenty:

1. Aplikácia (napr. IS). Vykonáva úlohy: požaduje pripojenie k zdroju údajov, odosiela dotazy SQL do zdroja údajov, popisuje oblasť úložiska a formát dotazov SQL, spracováva chyby a upozorňuje na ne používateľa, zaväzuje alebo odvoláva transakcie, požaduje pripojenie k dátový zdroj.

2. Správca zariadení. Načíta ovládače na požiadanie aplikácií, ponúka jednotné rozhranie pre všetky aplikácie a rozhranie správcu ODBC je rovnaké a bez ohľadu na to, s ktorým DBMS bude aplikácia interagovať. Správca ovládačov dodaný spoločnosťou Microsoft je knižnica s dynamickým načítaním (DLL).

3. Ovládač závisí od DBMS. Ovládač ODBC je dynamická knižnica (DLL), ktorá implementuje funkcie ODBC a spolupracuje so zdrojom údajov. Ovládač je program, ktorý spracuje požiadavku na funkciu špecifickú pre DBMS (môže modifikovať požiadavky v súlade s DBMS) a vráti výsledok do aplikácie. Každý DBMS, ktorý podporuje technológiu ODBC, musí poskytnúť vývojárom aplikácií ovládač pre daný DBMS.

4. Zdroj údajov obsahuje riadiace informácie špecifikované používateľom, informácie o zdroji údajov a používa sa na prístup ku konkrétnemu DBMS. V tomto prípade sa používajú prostriedky OS a sieťovej platformy.

Dynamický model

Tento model predpokladá mnoho aspektov, pre ktoré sa v UML používa aspoň 5 diagramov, pozri str. 2.04.2- 2.04.5.

Zvážte aspekt riadenia. Model riadenia dopĺňa štrukturálne modely.

Bez ohľadu na to, ako je štruktúra systému opísaná, pozostáva zo súboru štruktúrnych jednotiek (funkcií alebo objektov). Aby fungovali ako celok, musia byť riadené a v statických diagramoch nie sú žiadne riadiace informácie. Modely riadenia navrhujú tok riadenia medzi systémami.

V softvérových systémoch existujú dva hlavné typy riadenia.

1. Centralizované riadenie.

2. Manažment založený na udalostiach.

Centralizované riadenie môže byť:

· Hierarchický- na princípe "call-return" (takto najčastejšie fungujú vzdelávacie programy)

· Model dispečera ktorý sa používa pre paralelné systémy.

V modely dispečerov predpokladá sa, že jednou zo zložiek systému je dispečer. Riadi spúšťanie a vypínanie systémov a koordináciu ostatných procesov v systéme. Procesy môžu prebiehať navzájom paralelne. Proces sa vzťahuje na program, podsystém alebo procedúru, ktorá je práve spustená. Tento model je možné aplikovať aj v sekvenčných systémoch, kde riadiaci program volá jednotlivé podsystémy v závislosti od niektorých stavových premenných (prostredníctvom operátora prípad).

Manažment podujatí predpokladá absenciu akéhokoľvek podprogramu zodpovedného za riadenie. Ovládanie sa vykonáva vonkajšími udalosťami: stlačenie tlačidla myši, stlačenie klávesnice, zmena hodnôt snímača, zmena hodnôt časovača atď. Každá externá udalosť je zakódovaná a umiestnená do frontu udalostí. Ak je poskytnutá reakcia na udalosť vo fronte, potom sa zavolá procedúra (podprogram), ktorá vykoná reakciu na túto udalosť. Udalosti, na ktoré systém reaguje, môžu nastať buď v iných podsystémoch, alebo vo vonkajšom prostredí systému.

Príkladom takejto správy je organizácia aplikácií v systéme Windows.

Všetky vyššie opísané štrukturálne modely môžu byť implementované pomocou centralizovaného riadenia alebo riadenia založeného na udalostiach.

Používateľské rozhranie

Pri vývoji modelu rozhrania by sa mali brať do úvahy nielen úlohy navrhnutého softvéru, ale aj funkcie mozgu spojené s vnímaním informácií.

III.03.4. a Psychofyzikálne charakteristiky človeka spojené s vnímaním a spracovaním informácií.

Časť mozgu, ktorú môžeme konvenčne nazvať procesorom vnímania, neustále, bez účasti vedomia, spracováva prichádzajúce informácie, porovnáva ich s minulou skúsenosťou a ukladá ich do zásoby.

Keď vizuálny obraz upúta našu pozornosť, potom sa informácie, ktoré nás zaujímajú, dostanú do krátkodobej pamäte. Ak naša pozornosť nebola pritiahnutá, informácie v pamäti zmiznú a nahradia ich nasledujúce časti.

V každom okamihu je možné zamerať pozornosť na jeden bod, takže ak je potrebné súčasne sledovať niekoľko situácií, zaostrenie sa presunie z jedného sledovaného objektu na druhý. Zároveň je pozornosť rozptýlená a niektoré detaily môžu byť prehliadnuté. Je tiež dôležité, že vnímanie je z veľkej časti založené na motivácii.

Keď zmeníte rám, mozog sa na chvíľu zablokuje: zvládne nový obrázok a zvýrazní najvýznamnejšie detaily. To znamená, že ak potrebujete rýchlu odpoveď od používateľa, nemali by ste obrázky náhle meniť.

Krátkodobá pamäť je prekážkou v systéme spracovania informácií človeka. Jeho kapacita je 7 ± 2 nepripojené objekty. Nevyžiadané informácie sú v ňom uložené maximálne 30 sekúnd. Aby sme na žiadnu pre nás dôležitú informáciu nezabudli, väčšinou si ju opakujeme, čím si aktualizujeme informácie v krátkodobej pamäti. Pri navrhovaní rozhraní si teda treba uvedomiť, že pre drvivú väčšinu je ťažké napríklad zapamätať si a zadávať čísla obsahujúce viac ako päť číslic na inej obrazovke.

Hoci kapacita a doba uloženia dlhodobej pamäte je neobmedzená, prístup k informáciám nie je jednoduchý. Mechanizmus extrakcie informácií z dlhodobej pamäte má asociatívny charakter. Aby sa zlepšilo zapamätanie informácií, sú viazané na údaje, ktoré už pamäť ukladá a uľahčuje ich získanie. Keďže prístup k dlhodobej pamäti je zložitý, je vhodné počítať s tým, že používateľ si informáciu nezapamätá, ale že ju spozná.

III.03.4. b Základné kritériá hodnotenia rozhraní

Početné prieskumy a prieskumy uskutočnené poprednými spoločnosťami zaoberajúcimi sa vývojom softvéru ukázali, že používatelia oceňujú rozhranie:

1) jednoduchosť zvládnutia a zapamätania - konkrétne odhadnite čas zvládnutia a dobu uchovávania informácií a pamäte;

2) rýchlosť dosahovania výsledkov pri používaní systému, ktorá je určená počtom príkazov a nastavení zadaných alebo zvolených myšou;

3) subjektívna spokojnosť s prevádzkou systému (jednoduchosť používania, únava atď.).

Navyše pre profesionálnych používateľov, ktorí neustále pracujú s rovnakým balíkom, sa druhé a tretie kritérium rýchlo dostane na prvé miesto a pre neprofesionálnych používateľov, ktorí so softvérom pracujú pravidelne a vykonávajú relatívne jednoduché úlohy - prvé a tretie.

Z tohto hľadiska sú dnes najlepšie vlastnosti pre profesionálnych používateľov rozhrania s bezplatnou navigáciou a pre neprofesionálnych používateľov priame manipulačné rozhrania. Už dlho sa zistilo, že pri vykonávaní operácie kopírovania súborov, pričom všetky ostatné veci sú rovnaké, väčšina profesionálov používa shelly ako Far, zatiaľ čo neprofesionáli používajú Windows "ťahaním a pustením".

III.03.4. c Typy používateľských rozhraní

Rozlišujú sa tieto typy používateľských rozhraní:

Primitívne

Bezplatná navigácia

Priama manipulácia.

Rozhranie je primitívne

Primitívne sa nazýva rozhranie, ktoré organizuje interakciu s používateľom a používa sa v režime konzoly. Jedinou odchýlkou ​​od sekvenčného procesu, ktorý údaje poskytujú, je cyklovanie viacerých súborov údajov.

Rozhranie menu.

Na rozdiel od primitívneho rozhrania umožňuje používateľovi vybrať operáciu zo špeciálneho zoznamu zobrazeného programom. Tieto rozhrania predpokladajú implementáciu mnohých scenárov práce, pričom postupnosť akcií je určená používateľmi. Stromová organizácia menu naznačuje, že nájsť položku vo viac ako dvojúrovňových ponukách je ťažké.

(Materiál stránky http://se.math.spbu.ru)

Úvod.

V súčasnosti sú distribuované prakticky všetky veľké softvérové ​​systémy. Distribuovaný systém- systém, v ktorom je spracovanie informácií sústredené nie na jednom počítači, ale je rozdelené medzi viacero počítačov. Pri navrhovaní distribuovaných systémov, ktorý má veľa spoločného s návrhom softvéru vo všeobecnosti, je stále potrebné zvážiť niektoré špecifiká.

Existuje šesť hlavných charakteristík distribuovaných systémov.

1. Zdieľanie zdrojov. Distribuované systémy umožňujú zdieľanie prostriedkov hardvéru (pevné disky, tlačiarne) aj softvéru (súbory, kompilátory).
2. Otvorenosť.Je to schopnosť rozširovať systém pridávaním nových zdrojov.
3. Paralelnosť.V distribuovaných systémoch môže bežať viacero procesov súčasne na rôznych počítačoch v sieti. Tieto procesy môžu interagovať, keď sú spustené.
4. Škálovateľnosť . Pod škálovateľnosť možnosť pridania nových vlastností a metód sa chápe.
5. Odolnosť proti chybám. Prítomnosť viacerých počítačov umožňuje duplikáciu informácií a odolnosť voči niektorým hardvérovým a softvérovým chybám. Distribuované systémy môžu podporovať čiastočnú funkčnosť v prípade chyby. K úplnému zlyhaniu systému dochádza iba pri chybách siete.
6. Transparentnosť.Používateľom je poskytnutý plný prístup k zdrojom v systéme, pričom sú pred nimi zároveň skryté informácie o rozmiestnení zdrojov v celom systéme.

Distribuované systémy majú aj množstvo nevýhod.

1. Zložitosť... Oveľa ťažšie je pochopiť a zhodnotiť vlastnosti distribuovaných systémov vo všeobecnosti a je náročnejšie ich navrhovať, testovať a udržiavať. Výkon systému tiež závisí od rýchlosti siete a nie od jednotlivých procesorov. Prerozdelenie zdrojov môže výrazne zmeniť rýchlosť systému.
2. Bezpečnosť... Typicky je k systému možné pristupovať z niekoľkých rôznych strojov, správy v sieti možno monitorovať a zachytávať. Preto je v distribuovanom systéme oveľa ťažšie udržať bezpečnosť.
3. Ovládateľnosť... Systém môže pozostávať z rôznych typov počítačov, na ktorých je možné nainštalovať rôzne verzie operačných systémov. Chyby na jednom stroji sa môžu šíriť na iné stroje nepredvídateľným spôsobom.
4. Nepredvídateľnosť ... Reakcia distribuovaných systémov na niektoré udalosti je nepredvídateľná a závisí od plného zaťaženia systému, jeho organizácie a zaťaženia siete. Keďže sa tieto parametre môžu neustále meniť, čas odozvy na požiadavku sa môže výrazne líšiť od času.

Z týchto nedostatkov môžete vidieť, že pri navrhovaní distribuovaných systémov vzniká množstvo problémov, ktoré musia vývojári zvážiť.

1. Identifikácia zdroja ... Prostriedky v distribuovaných systémoch sú umiestnené na rôznych počítačoch, takže systém pomenovávania prostriedkov by sa mal myslieť tak, aby používatelia mohli ľahko pristupovať a odkazovať na zdroje, ktoré potrebujú. Príkladom je systém URL (Uniform Resource Locator), ktorý definuje názvy webových stránok.
2. Komunikácia... Univerzálna funkčnosť internetu a efektívna implementácia protokolov TCP/IP na internete pre väčšinu distribuovaných systémov sú príklady najefektívnejšieho spôsobu organizácie komunikácie medzi počítačmi. V niektorých prípadoch, kde sa vyžaduje špeciálny výkon alebo spoľahlivosť, je však možné použiť špecializované nástroje.
3. Kvalita systémových služieb ... Tento parameter odráža výkon, zdravie a spoľahlivosť. Kvalitu služby ovplyvňuje množstvo faktorov: distribúcia procesov, zdrojov, hardvéru a prispôsobivosť systému.
4. Architektúra softvéru ... Softvérová architektúra popisuje distribúciu systémových funkcií medzi komponenty systému, ako aj distribúciu týchto komponentov medzi procesory. Ak potrebujete udržiavať vysokú kvalitu systémových služieb, výber správnej architektúry je rozhodujúci.

Výzvou pre dizajnérov distribuovaných systémov je navrhnúť softvér a hardvér tak, aby poskytovali všetky požadované vlastnosti distribuovaného systému. To si vyžaduje poznať výhody a nevýhody rôznych architektúr distribuovaných systémov. Existujú tri typy architektúr distribuovaných systémov.

1. Architektúra klient / server ... V tomto modeli si systém možno predstaviť ako súbor služieb poskytovaných servermi klientom. V takýchto systémoch sa servery a klienti navzájom výrazne líšia.
2. Trojvrstvová architektúra ... V tomto modeli server neposkytuje služby klientom priamo, ale prostredníctvom servera obchodnej logiky.

O prvých dvoch modeloch to už bolo povedané viackrát, pri treťom sa zastavíme podrobnejšie.

1. Architektúra distribuovaných objektov ... V tomto prípade neexistujú žiadne rozdiely medzi servermi a klientmi a systém si možno predstaviť ako súbor vzájomne pôsobiacich objektov, na ktorých umiestnení v skutočnosti nezáleží. Neexistuje žiadny rozdiel medzi poskytovateľom služieb a ich používateľmi.

Táto architektúra je dnes široko používaná a nazýva sa aj tzv architektúra webových služieb. Webová služba je aplikácia, ktorá je dostupná cez internet a poskytuje niektoré služby, ktorých forma je nezávislá od poskytovateľa (keďže sa používa univerzálny dátový formát - XML) a platformy prevádzky. V súčasnosti existujú tri rôzne technológie, ktoré podporujú koncepciu distribuovaných objektových systémov. Ide o technológie EJB, CORBA a DCOM.

Najprv pár slov o tom, čo je XML vo všeobecnosti. XML je všeobecný dátový formát používaný na poskytovanie webových služieb. Webové služby sú založené na otvorených štandardoch a protokoloch: SOAP, UDDI a WSDL.

1. SOAP ( Simple Object Access Protocol, vyvinutý W3C, definuje formát pre požiadavky na webové služby. Správy medzi webovou službou a jej používateľom sú zabalené do takzvaných SOAP obálok (niekedy nazývaných aj XML obálky). Samotná správa môže obsahovať buď požiadavku na vykonanie nejakej akcie, alebo odpoveď – výsledok tejto akcie.
2. WSDL (Web Service Description Language).Rozhranie webovej služby je opísané v dokumentoch WSDL (a WSDL je podmnožinou XML). Pred nasadením služby vývojár vytvorí jej popis v jazyku WSDL, špecifikuje adresu webovej služby, podporované protokoly, zoznam povolených operácií a formáty požiadaviek a odpovedí.
3. UDDI (univerzálny popis, objavovanie a integrácia) - Internet Web Services Search Protocol ( http://www.uddi.org/). Ide o obchodný register, kde poskytovatelia webových služieb registrujú služby a vývojári nachádzajú služby, ktoré potrebujú zahrnúť do svojich aplikácií.

Z rozprávania sa môže zdať, že webové služby sú najlepším a nesporným riešením a jedinou otázkou je výber vývojových nástrojov. Avšak nie je. Existuje alternatíva k webovým službám, sémantický web, o ktorom tvorca WWW Tim Berners-Lee hovoril pred piatimi rokmi.

Ak je cieľom webových služieb uľahčiť komunikáciu medzi aplikáciami, potom je sémantický web navrhnutý tak, aby riešil oveľa komplexnejší problém – používanie mechanizmov metadát na zvýšenie efektívnosti hodnoty informácií, ktoré možno na webe nájsť. Dá sa to dosiahnuť opustením dokumentovo orientovaného prístupu v prospech objektovo orientovaného.

Bibliografia

1. SomervilleI. Softvérové ​​inžinierstvo.
2. Dranitsa A. Java vs. .NET. - "Computerra", # 516.
3. internetové zdroje.