Rozproszony AIS stał się codziennością. Wiele korporacyjnych systemów AIS korzysta z rozproszonych baz danych. Opracowano metody dystrybucji i zarządzania danymi rozproszonymi, podejścia architektoniczne zapewniające skalowalność systemów, realizujące zasady wielowarstwowej architektury klient-serwer, a także architekturę warstwy środkowej.

Architektury mobilne zaczynają być stosowane w praktyce. Dotyczy to zarówno systemów bazodanowych, jak i aplikacji internetowych.

Odradza się podejście do budowania systemów rozproszonych w oparciu o architekturę peer-to-peer, w której w przeciwieństwie do dominującej obecnie w systemach rozproszonych architektury klient-serwer, role stron interakcji w sieci nie są stałe. Są one przydzielane w zależności od sytuacji w sieci, od obciążenia jej węzłów.

W związku z intensywnym rozwojem technologii komunikacyjnych aktywnie rozwija się mobilny AIS. Opracowano środki techniczne i oprogramowanie do ich tworzenia. Doprowadziło to do rozwoju mobilnych systemów baz danych. Wiele zespołów badawczych prowadzi badania nad specyfiką takich systemów i tworzy ich różne prototypy. Technologie Java stały się ważnym narzędziem do tworzenia oprogramowania mobilnego.

Stworzono standard protokołu WAP (Wireless Application Protocol), który jest już obsługiwany przez niektóre modele telefonów komórkowych. W oparciu o WAP i XML, W3C opracowało język znaczników dla komunikacji bezprzewodowej, WML (Wireless Markup Language).

W rozwoju AIS zwrócono większą uwagę na metadane. Tutaj działania podejmowane są w dwóch kierunkach – ujednolicenia prezentacji metadanych i zapewnienia ich obsługi w systemie.

AIS wykorzystuje różne sposoby i środki prezentacji metadanych (różne rodzaje repozytoriów metadanych). Brak unifikacji w tym obszarze znacznie komplikuje rozwiązywanie problemów mobilności aplikacji, ponownego wykorzystania i integracji zasobów informacyjnych oraz technologii informatycznych, a także reengineeringu AIS.

Aby przezwyciężyć te trudności, aktywnie dąży się do rozwoju standardów metadanych skoncentrowanych na różnych technologiach informatycznych. W tym obszarze istnieje już szereg międzynarodowych, krajowych i branżowych standardów, które definiują prezentację metadanych i wymianę metadanych w AIS. Część z nich uzyskała już status norm de facto. Ograniczymy się tutaj do wymienienia tylko najważniejszych z nich.

Prawdopodobnie pierwszym de facto standardem dla tej kategorii był język opisu danych CODASYL dla sieciowych baz danych. Należy wymienić następujące standardy: standard języka zapytań SQL dla relacyjnych baz danych, zawierający definicję tzw. schematu informacyjnego - zbioru reprezentacji schematów relacyjnych baz danych; standardowy komponent bazy danych obiektów ODMG, który opisuje interfejsy repozytorium schematów obiektów; międzynarodowy standard IRDS (Information Resource Dictionary Systems), który opisuje systemy tworzenia i utrzymywania katalogów zasobów informacyjnych organizacji.

W dalszej kolejności należy wspomnieć o opracowanym przez konsorcjum OMG standardzie Common Warehouse Metamodel (CWM) do reprezentacji metadanych hurtowni danych, opartym na stworzonym wcześniej dla szerszych celów standardzie OIM (Open Information Model) przez konsorcjum MDC (Meta Data Coalition) .

Nowa platforma technologiczna XML for the Web obejmuje również standardy prezentacji metadanych. Obsługa metadanych jest jedną z najważniejszych innowacji w sieci, radykalnie zmieniającą technologię zarządzania jej zasobami informacyjnymi. Chociaż obsługa metadanych była pierwotnie wymagana w technologiach baz danych, metadane nie były obsługiwane w sieci Web pierwszej generacji.

Standardy metadanych internetowych obejmują podzbiór języka XML używanego do opisywania logicznej struktury pewnego typu dokumentu XML. Opis ten nosi nazwę DTD (Definicja Typu Dokumentu). Dodatkowo platforma XML zawiera standard XML Schema, który oferuje bardziej zaawansowane możliwości opisu dokumentów XML. Standard Resource Definition Framework (RDF) definiuje prosty język reprezentacji wiedzy do opisu zawartości dokumentów XML. Wreszcie, powstający standard OWL (Ontology Web Language) definiuje formalny język opisu ontologii dla Sieci Semantycznej.

Konsorcjum OMG opracowało standard Unified Modeling Language (UML), który zapewnia reprezentację metadanych na potrzeby wizualnej analizy obiektów i narzędzi projektowych CASE. Język ten jest obsługiwany w wielu produktach oprogramowania CASE. OMG stworzyło również standard XML Metadata Interchange (XMI) do wymiany metadanych między narzędziami CASE za pomocą UML.

W tym miejscu należy również wspomnieć o standardzie Dublin Core (DC), czyli zbiorze elementów metadanych opisujących zawartość dokumentów o różnym charakterze. Standard ten szybko zyskał popularność i znalazł szerokie zastosowanie w szczególności w środowisku WWW (patrz Rozdział 3.3).

Trwają prace nad rozwojem istniejących i tworzeniem nowych standardów prezentacji metadanych dla AIS. Bardziej szczegółowe informacje na temat omawianych norm można znaleźć w encyklopedii.

Zdaniem znanego eksperta w dziedzinie informatyki E. Tanenbauma, nie ma ogólnie przyjętej, a zarazem ścisłej definicji systemu rozproszonego. Niektórzy sprytni twierdzą, że dystrybucja jest taka system komputerowy, w którym awaria komputera, której istnienia użytkownicy nawet wcześniej nie podejrzewali, prowadzi do zakończenia całej ich pracy. Znaczna część systemów przetwarzania rozproszonego niestety spełnia tę definicję, ale formalnie odnosi się to tylko do systemów z unikalnym punktem podatności ( pojedynczy punkt awarii).

Często przy definiowaniu systemu rozproszonego nacisk kładzie się na podział jego funkcji na kilka komputerów. Dzięki takiemu podejściu każdy jest rozproszony system komputerowy gdzie przetwarzanie danych jest podzielone między dwa lub więcej komputerów. Opierając się na definicji E. Tanenbauma, nieco węższy system rozproszony można zdefiniować jako zbiór niezależnych komputerów połączonych kanałami komunikacyjnymi, które z punktu widzenia użytkownika jakiegoś oprogramowania wyglądają jak jedna całość.

Takie podejście do definiowania systemu rozproszonego ma swoje wady. Na przykład wszystko, co jest używane w tak rozproszonym systemie oprogramowanie mógłby pracować na jednym komputerze, ale z punktu widzenia powyższej definicji taki system nie będzie już dystrybuowany. Dlatego też koncepcja systemu rozproszonego powinna prawdopodobnie opierać się na analizie oprogramowania tworzącego taki system.

Jako podstawę do opisu interakcji dwóch podmiotów rozważ ogólny model interakcji klient-serwer, w którym jedna ze stron (klient) inicjuje wymianę danych wysyłając żądanie do drugiej strony (serwer). Serwer przetwarza żądanie iw razie potrzeby wysyła odpowiedź do klienta (rys. 1.1).

Ryż. 1.1.

Interakcja w ramach modelu klient-serwer może być synchroniczna, gdy klient oczekuje na przetworzenie jego żądania przez serwer, lub asynchroniczna, w której klient wysyła żądanie do serwera i kontynuuje jego wykonanie bez oczekiwania na odpowiedź. Model klienta i serwera może służyć jako podstawa do opisu różnych interakcji. W przypadku tego kursu ważna jest interakcja części składowych oprogramowania, które tworzy system rozproszony.

Ryż. 1.2.

Rozważ pewną typową aplikację, którą zgodnie ze współczesnymi koncepcjami można podzielić na następujące logiczne poziomy (ryc. 1.2): interfejs użytkownika(PI), logika aplikacji (LP) i dostęp do danych (DD), praca z bazą danych (DB). Użytkownik systemu wchodzi z nim w interakcję poprzez interfejs użytkownika, baza danych przechowuje dane opisujące domenę aplikacji, a warstwa logiki aplikacji implementuje wszystkie algorytmy związane z Tematyka.

Ponieważ w praktyce różni użytkownicy systemu są zwykle zainteresowani dostępem do tych samych danych, najprostszym rozdzieleniem funkcji takiego systemu na kilka komputerów będzie rozdzielenie warstw logicznych aplikacji pomiędzy jedną serwerową częścią aplikacji , który odpowiada za dostęp do danych oraz części klienckich znajdujących się na kilku komputerach implementujących interfejs użytkownika. Logika aplikacji może być przypisana do serwera, klientów lub współdzielona między nimi (rysunek 1.3).

Ryż. 1.3.

Architektura aplikacji zbudowana na tej zasadzie nazywana jest klient-serwer lub dwuwarstwowa. W praktyce takie systemy często nie są klasyfikowane jako rozproszone, ale formalnie można je uznać za najprostszych przedstawicieli systemów rozproszonych.

Rozwój architektury klient-serwer jest architekturą trójwarstwową, w której interfejs użytkownika, logika aplikacji i dostęp do danych są rozdzielone na niezależne komponenty systemu, które mogą działać na niezależnych komputerach (rys. 1.4).

Ryż. 1.4.

Żądanie użytkownika w takich systemach jest sekwencyjnie przetwarzane przez część kliencką systemu, serwer logiki aplikacji i serwer bazy danych. Jednak system rozproszony jest zwykle rozumiany jako system o bardziej złożonej architekturze niż system trójwarstwowy.

W poprzednim rozdziale przyjrzeliśmy się ściśle powiązanym systemom wieloprocesorowym z pamięcią współdzieloną, współdzielonymi strukturami danych jądra i współdzieloną pulą, z której wywoływane są procesy. Często jednak pożądane jest przydzielenie procesorów w taki sposób, aby były niezależne od środowiska operacyjnego i warunków pracy w celu współdzielenia zasobów. Załóżmy na przykład, że użytkownik komputera osobistego musi uzyskać dostęp do plików znajdujących się na większym komputerze, ale jednocześnie zachować kontrolę nad komputerem osobistym. Chociaż niektóre programy, takie jak uucp, obsługują przesyłanie plików w sieci i inne funkcje sieciowe, ich użycie nie będzie ukryte przed użytkownikiem, ponieważ użytkownik jest świadomy, że korzysta z sieci. Ponadto należy zauważyć, że programy takie jak edytory tekstu nie działają z usuniętymi plikami, tak jak ze zwykłymi. Użytkownicy powinni mieć standardowy zestaw funkcji systemu UNIX i, poza potencjalnym wąskim gardłem wydajności, nie powinni odczuwać przekraczania granic maszyn. Na przykład praca funkcji systemowych otwieranych i czytanych z plikami na zdalnych maszynach nie powinna różnić się od ich pracy z plikami należącymi do systemów lokalnych.

Architektura systemu rozproszonego jest pokazana na rysunku 13.1. Każdy komputer pokazany na rysunku jest samodzielną jednostką składającą się z procesora, pamięci i urządzeń peryferyjnych. Model nie psuje się, mimo że komputer nie ma lokalnego systemu plików: musi mieć urządzenia peryferyjne, aby komunikować się z innymi komputerami, a wszystkie należące do niego pliki mogą znajdować się na innym komputerze. Pamięć fizyczna dostępna dla każdej maszyny jest niezależna od procesów działających na innych maszynach. Pod tym względem systemy rozproszone różnią się od ściśle powiązanych systemów wieloprocesorowych omówionych w poprzednim rozdziale. W związku z tym rdzeń systemu na każdej maszynie działa niezależnie od zewnętrznych warunków pracy rozproszonego środowiska.

Rysunek 13.1. Model systemu architektury rozproszonej

Systemy rozproszone, dobrze opisane w literaturze, tradycyjnie dzielą się na następujące kategorie:

Systemy peryferyjne, które są grupami maszyn, które mają silne podobieństwo i są powiązane z jedną (zwykle większą) maszyną. Procesory peryferyjne dzielą swoje obciążenie z procesorem centralnym i przekazują do niego wszystkie wywołania do systemu operacyjnego. Celem systemu peryferyjnego jest zwiększenie ogólnej wydajności sieci i zapewnienie możliwości przydzielenia procesora do pojedynczego procesu w środowisku operacyjnym UNIX. System uruchamia się jako osobny moduł; W przeciwieństwie do innych modeli systemów rozproszonych, systemy peryferyjne nie mają rzeczywistej autonomii, z wyjątkiem przypadków związanych z rozsyłaniem procesów i alokacją pamięci lokalnej.

Systemy rozproszone takie jak „Newcastle”, umożliwiające zdalną komunikację poprzez nazwy zdalnych plików w bibliotece (nazwa zaczerpnięta z artykułu „The Newcastle Connection” – zobacz). Usunięte pliki mają BOM (nazwę wyróżniającą), która w ścieżce wyszukiwania zawiera znaki specjalne lub opcjonalny składnik nazwy poprzedzający katalog główny systemu plików. Implementacja tej metody nie wiąże się z wprowadzaniem zmian w jądrze systemu, dlatego jest prostsza niż inne metody omówione w tym rozdziale, ale mniej elastyczna.

Systemy rozproszone są całkowicie przezroczyste, w których standardowe nazwy wyróżniające są wystarczające, aby odnosić się do plików znajdujących się na innych maszynach; od jądra zależy rozpoznanie tych plików jako usuniętych. Ścieżki wyszukiwania plików określone w ich nazwach złożonych przekraczają granice komputera w punktach montowania, bez względu na to, ile takich punktów jest tworzonych, gdy systemy plików są montowane na dyskach.

W tym rozdziale przyjrzymy się architekturze każdego modelu; wszystkie podane informacje nie są oparte na wynikach konkretnych zmian, ale na informacjach opublikowanych w różnych artykułach technicznych. Zakłada się, że moduły protokołów i sterowniki urządzeń są odpowiedzialne za adresowanie, routing, kontrolę przepływu oraz wykrywanie i korygowanie błędów — innymi słowy, że każdy model jest niezależny od używanej sieci. Przykłady użycia funkcji systemowych pokazane w następnej sekcji dla systemów peryferyjnych działają w podobny sposób dla systemów takich jak Newcastle i dla systemów całkowicie przezroczystych, co zostanie omówione później; dlatego przyjrzymy się im szczegółowo raz, a w działach poświęconych innym typom systemów skupimy się głównie na cechach, które wyróżniają te modele spośród wszystkich innych.

13.1 PROCESORY PERYFERYJNE

Architekturę systemu peryferyjnego pokazano na rysunku 13.2. Celem tej konfiguracji jest poprawa ogólnej wydajności sieci poprzez ponowne przydzielanie uruchomionych procesów między procesorem a procesorami peryferyjnymi. Każdy z procesorów peryferyjnych nie ma do dyspozycji żadnych innych lokalnych urządzeń peryferyjnych poza tymi, których potrzebuje do komunikacji z jednostką centralną. System plików i wszystkie urządzenia są do dyspozycji procesora centralnego. Załóżmy, że wszystkie procesy użytkownika są wykonywane na procesorze peryferyjnym i nie przemieszczają się między procesorami peryferyjnymi; raz przeniesione do procesora pozostają na nim aż do zakończenia. Procesor peryferyjny zawiera lekką wersję systemu operacyjnego, przeznaczoną do obsługi połączeń lokalnych do systemu, zarządzania przerwaniami, alokacji pamięci, pracy z protokołami sieciowymi oraz ze sterownikiem urządzenia do komunikacji z procesorem centralnym.

Gdy system jest inicjowany na procesorze centralnym, rdzeń ładuje lokalny system operacyjny na każdym z procesorów peryferyjnych za pośrednictwem linii komunikacyjnych. Każdy proces działający na peryferiach jest powiązany z procesem satelitarnym należącym do procesora centralnego (patrz); gdy proces działający na procesorze peryferyjnym wywołuje funkcję systemową, która wymaga usług tylko procesora centralnego, proces peryferyjny komunikuje się ze swoim satelitą i żądanie jest wysyłane do procesora centralnego w celu przetworzenia. Proces satelitarny pełni funkcję systemową i wysyła wyniki z powrotem do procesora peryferyjnego. Relacja między procesem peryferyjnym a jego satelitą jest podobna do relacji klient-serwer, którą szczegółowo omówiliśmy w rozdziale 11: proces peryferyjny działa jako klient swojego satelity, który obsługuje funkcje pracy z systemem plików. W takim przypadku proces serwera zdalnego ma tylko jednego klienta. W sekcji 13.4 przyjrzymy się procesom serwera z wieloma klientami.

Rysunek 13.2. Konfiguracja systemu peryferyjnego

Rysunek 13.3. Formaty wiadomości

Gdy proces peryferyjny wywołuje funkcję systemową, która może być przetwarzana lokalnie, jądro nie musi wysyłać żądania do procesu satelitarnego. Na przykład, aby uzyskać dodatkową pamięć, proces może wywołać funkcję sbrk w celu wykonania lokalnego. Jeśli jednak usługi centralnego procesora są wymagane, na przykład do otwarcia pliku, jądro koduje informacje o parametrach przekazywanych do wywoływanej funkcji i warunkach wykonania procesu w wiadomości wysyłanej do procesu satelitarnego (rysunek 13.3). Komunikat zawiera znak, z którego wynika, że ​​funkcja systemu jest wykonywana przez proces satelitarny w imieniu klienta, parametry przekazywane do funkcji oraz dane o środowisku wykonania procesu (np. kody identyfikacyjne użytkownika i grupy), które są różne dla różnych funkcji. Pozostała część komunikatu to dane o zmiennej długości (na przykład złożona nazwa pliku lub dane, które mają zostać zapisane za pomocą funkcji write).

Proces satelitarny czeka na żądania z procesu peryferyjnego; po otrzymaniu żądania dekoduje komunikat, określa typ funkcji systemowej, wykonuje ją i przekształca wyniki w odpowiedź wysłaną do procesu peryferyjnego. Odpowiedź, poza wynikami wykonania funkcji systemowej, zawiera komunikat o błędzie (jeśli występuje), numer sygnału oraz tablicę danych o zmiennej długości zawierającą np. informacje odczytane z pliku. Proces peryferyjny jest zawieszony do momentu otrzymania odpowiedzi, po jej odebraniu deszyfruje i przesyła wyniki do użytkownika. Jest to ogólny schemat obsługi wywołań systemu operacyjnego; przejdźmy teraz do bardziej szczegółowego rozważenia poszczególnych funkcji.

Aby wyjaśnić, jak działa system peryferyjny, rozważ kilka funkcji: getppid, open, write, fork, exit i signal. Funkcja getppid jest dość prosta, ponieważ zajmuje się prostymi formularzami żądań i odpowiedzi, które są wymieniane między urządzeniem peryferyjnym a procesorem. Rdzeń w procesorze peryferyjnym generuje komunikat, który ma znak, z którego wynika, że ​​żądana funkcja jest funkcją getppid i wysyła żądanie do centralnego procesora. Proces satelitarny na centralnym procesorze odczytuje wiadomość z procesora peryferyjnego, odszyfrowuje typ funkcji systemowej, wykonuje ją i uzyskuje identyfikator swojego rodzica. Następnie generuje odpowiedź i przekazuje ją do oczekującego procesu peryferyjnego na drugim końcu linii komunikacyjnej. Gdy procesor peryferyjny otrzyma odpowiedź, przekazuje ją do procesu, który nazywa funkcję systemową getppid. Jeśli proces peryferyjny przechowuje dane (takie jak identyfikator procesu rodzica) w pamięci lokalnej, nie musi w ogóle komunikować się ze swoim towarzyszem.

Jeśli wywołana zostanie funkcja otwartego systemu, proces peryferyjny wysyła wiadomość do swojego towarzysza, która zawiera nazwę pliku i inne parametry. Jeśli się powiedzie, proces towarzyszący przydziela indeks i punkt wejścia do tabeli plików, przydziela wpis w tablicy deskryptorów plików użytkownika w swojej przestrzeni i zwraca deskryptor pliku do procesu peryferyjnego. Cały czas na drugim końcu linii komunikacyjnej proces peryferyjny czeka na odpowiedź. Nie ma do dyspozycji żadnych struktur, które przechowywałyby informacje o otwieranym pliku; Deskryptor zwrócony przez open jest wskaźnikiem do wpisu w procesie towarzyszącym w tablicy deskryptorów pliku użytkownika. Wyniki wykonania funkcji przedstawia rysunek 13.4.

Rysunek 13.4. Wywołanie funkcji otwartej z procesu peryferyjnego

W przypadku wywołania funkcji systemowej write, procesor peryferyjny generuje komunikat składający się ze znaku funkcji write, deskryptora pliku i ilości danych do zapisu. Następnie z przestrzeni procesu peryferyjnego kopiuje dane do procesu satelitarnego poprzez linię komunikacyjną. Proces satelitarny odszyfrowuje odebraną wiadomość, odczytuje dane z linii komunikacyjnej i zapisuje je do odpowiedniego pliku (deskryptor zawarty w wiadomości służy jako wskaźnik do którego indeksu i rekordu o którym w tabeli plików jest używany ); wszystkie te działania są wykonywane na procesorze centralnym. Na koniec pracy proces satelitarny wysyła do procesu peryferyjnego komunikat potwierdzający odebranie komunikatu i zawierający liczbę bajtów danych, które zostały pomyślnie skopiowane do pliku. Operacja odczytu jest podobna; satelita informuje proces peryferyjny o liczbie faktycznie odczytanych bajtów (w przypadku odczytu danych z terminala lub z kanału liczba ta nie zawsze pokrywa się z ilością określoną w żądaniu). Aby wykonać jedną lub drugą funkcję, może być konieczne wielokrotne wysyłanie wiadomości informacyjnych przez sieć, co jest określane przez ilość wysyłanych danych i rozmiar pakietów sieciowych.

Jedyną funkcją, którą należy zmienić podczas pracy na procesorze, jest funkcja fork system. Kiedy proces wykonuje tę funkcję na CPU, jądro wybiera dla niego procesor peryferyjny i wysyła komunikat do specjalnego procesu - serwera, informując go, że rozpocznie rozładowywanie bieżącego procesu. Zakładając, że serwer zaakceptował żądanie, jądro używa fork do utworzenia nowego procesu peryferyjnego, przydzielając wpis w tablicy procesów i przestrzeń adresową. Centralny procesor rozładowuje kopię procesu, który wywołał funkcję rozwidlenia, do procesora peryferyjnego, nadpisując nowo przydzieloną przestrzeń adresową, tworzy lokalnego satelitę, aby komunikować się z nowym procesem peryferyjnym i wysyła wiadomość do urządzenia peryferyjnego, aby zainicjować licznik programu dla nowy proces. Proces satelitarny (na procesorze) jest potomkiem procesu, który wywołał fork; proces peryferyjny jest technicznie potomkiem procesu serwera, ale logicznie jest potomkiem procesu, który nazywa się funkcją fork. Proces serwera nie ma logicznego połączenia z dzieckiem po zakończeniu fork; jedynym zadaniem serwera jest pomoc w wyładowaniu dziecka. Ze względu na silne połączenie między elementami systemu (procesory peryferyjne nie mają autonomii), proces peryferyjny i proces satelitarny mają ten sam kod identyfikacyjny. Związek między procesami pokazano na rysunku 13.5: linia ciągła pokazuje relację rodzic-dziecko, a linia przerywana pokazuje relację między rówieśnikami.

Rysunek 13.5. Wykonywanie funkcji fork na procesorze

Gdy proces wykonuje funkcję rozwidlenia na procesorze peryferyjnym, wysyła wiadomość do swojego satelity na procesorze, który następnie wykonuje całą sekwencję działań opisanych powyżej. Satelita wybiera nowy procesor peryferyjny i dokonuje niezbędnych przygotowań do rozładowania obrazu starego procesu: wysyła żądanie do nadrzędnego procesu peryferyjnego, aby odczytał jego obraz, w odpowiedzi na który na drugim końcu rozpoczyna się przesyłanie żądanych danych kanału komunikacji. Satelita odczytuje przesyłany obraz i nadpisuje go peryferyjnemu potomkowi. Po zakończeniu rozładowywania obrazu satelita rozwidla się, tworząc swój element potomny na procesorze i przekazuje wartość licznika programu do elementu potomnego peryferyjnego, aby ten wiedział, gdzie rozpocząć wykonywanie. Oczywiście byłoby lepiej, gdyby dziecko procesu towarzyszącego zostało przypisane do dziecka peryferyjnego jako rodzic, ale w naszym przypadku wygenerowane procesy mogą działać na innych procesorach peryferyjnych, a nie tylko na tym, na którym zostały utworzone. Zależność między procesami na końcu funkcji rozwidlenia pokazano na rysunku 13.6. Kiedy proces peryferyjny kończy swoją pracę, wysyła odpowiednią wiadomość do procesu satelitarnego i to również się kończy. Proces towarzyszący nie może zainicjować zamknięcia.

Rysunek 13.6. Wykonywanie funkcji fork na procesorze peryferyjnym

Zarówno w systemach wieloprocesorowych, jak i jednoprocesorowych proces musi odpowiadać na sygnały w ten sam sposób: proces albo kończy wykonywanie funkcji systemowej przed sprawdzeniem sygnałów, albo przeciwnie, po odebraniu sygnału natychmiast wychodzi ze stanu wstrzymania i nagle przerywa pracę funkcji systemu, jeśli jest to zgodne z priorytetem, z jakim został zawieszony. Ponieważ proces satelitarny wykonuje funkcje systemowe w imieniu procesu peryferyjnego, musi odpowiadać na sygnały w koordynacji z tym ostatnim. Jeśli w systemie jednoprocesorowym sygnał powoduje przerwanie funkcji przez proces, proces towarzyszący w systemie wieloprocesorowym powinien zachowywać się w ten sam sposób. To samo można powiedzieć o przypadku, gdy sygnał nakazuje procesowi zakończenie pracy za pomocą funkcji wyjścia: proces peryferyjny kończy się i wysyła odpowiednią wiadomość do procesu satelity, który oczywiście również się kończy.

Gdy proces peryferyjny wywołuje funkcję systemu sygnałowego, przechowuje bieżące informacje w lokalnych tabelach i wysyła wiadomość do swojego satelity, informując go, czy określony sygnał powinien zostać odebrany, czy zignorowany. Proces satelitarny nie dba o to, czy przechwytuje sygnał, czy domyślną akcję. Reakcja procesu na sygnał zależy od trzech czynników (Rysunek 13.7): czy sygnał nadchodzi w czasie, gdy proces wykonuje funkcję systemową, czy następuje wskazanie przy użyciu funkcji sygnału w celu zignorowania sygnału, czy sygnał pojawia się na ten sam procesor peryferyjny lub inny. Przejdźmy do rozważenia różnych możliwości.

algorytm sighandle / * algorytm przetwarzania sygnału * /

if (bieżący proces jest czyimś towarzyszem lub ma prototyp)

jeśli (sygnał jest ignorowany)

jeśli (sygnał nadszedł podczas wykonywania funkcji systemowej)

umieść sygnał przed procesem satelitarnym;

wysłać wiadomość sygnałową do procesu peryferyjnego;

else (/ * proces peryferyjny * /

/ * czy sygnał został odebrany podczas wykonywania funkcji systemowej, czy nie * /

wysłać sygnał do procesu satelitarnego;

algorytm Satellite_end_of_syscall / * zakończenie funkcji systemowej wywoływanej przez proces peryferyjny * /

informacje wejściowe: brak

nadruk: brak

if (odebrano przerwanie podczas wykonywania funkcji systemowej)

wyślij wiadomość przerwania, sygnał do procesu peryferyjnego;

else / * wykonanie funkcji systemowej nie zostało przerwane * /

wyślij odpowiedź: włącz flagę pokazującą nadejście sygnału;

Rysunek 13.7. Przetwarzanie sygnału w systemie peryferyjnym

Załóżmy, że proces peryferyjny zawiesił swoją pracę, podczas gdy proces satelitarny wykonuje w jego imieniu funkcję systemową. Jeśli sygnał pojawi się gdzie indziej, proces satelitarny wykryje go wcześniej niż proces peryferyjny. Możliwe są trzy przypadki.

1. Jeżeli w oczekiwaniu na jakieś zdarzenie proces satelity nie wszedł w stan wstrzymania, z którego wyszedłby po otrzymaniu sygnału, wykonuje funkcję systemową do końca, przesyła wyniki wykonania do procesu peryferyjnego i pokazuje jaki sygnał otrzymał.

2. Jeśli proces został poinstruowany, aby zignorować ten typ sygnału, satelita kontynuuje działanie algorytmu wykonania funkcji systemowej bez wychodzenia ze stanu zawieszenia przez longjmp. W odpowiedzi wysłanej do procesu peryferyjnego nie będzie komunikatu o odebraniu sygnału.

3. Jeżeli po odebraniu sygnału proces satelity przerywa wykonywanie funkcji systemowej (przez longjmp), informuje o tym proces peryferyjny i podaje numer sygnału.

Proces peryferyjny poszukuje informacji o odebraniu sygnałów w otrzymanej odpowiedzi i, jeśli takie istnieją, przetwarza sygnały przed wyjściem z funkcji systemu. Zatem zachowanie procesu w systemie wieloprocesorowym dokładnie odpowiada jego zachowaniu w systemie jednoprocesorowym: albo kończy działanie bez wychodzenia z trybu jądra, albo wywołuje niestandardową funkcję przetwarzania sygnału, albo ignoruje sygnał i pomyślnie kończy funkcję systemową.

Rysunek 13.8. Przerwa podczas wykonywania funkcji systemowej

Załóżmy, na przykład, że proces peryferyjny wywołuje funkcję odczytu z terminala podłączonego do centralnego procesora i wstrzymuje swoją pracę, podczas gdy proces satelitarny wykonuje tę funkcję (rysunek 13.8). Jeśli użytkownik naciśnie klawisz przerwy, rdzeń procesora wyśle ​​sygnał do procesu satelitarnego. Jeśli satelita był w stanie zawieszenia, czekając na porcję danych z terminala, natychmiast wychodzi z tego stanu i kończy funkcję odczytu. W odpowiedzi na żądanie z procesu peryferyjnego satelita dostarcza kod błędu i numer sygnału odpowiadający przerwaniu. Proces peryferyjny analizuje odpowiedź i, ponieważ komunikat mówi o nadejściu przerwania, wysyła sygnał do siebie. Przed wyjściem z funkcji odczytu rdzeń peryferyjny sprawdza sygnalizację, wykrywa sygnał przerwania z procesu satelitarnego i przetwarza go w zwykły sposób. Jeżeli w wyniku odebrania sygnału przerwania proces peryferyjny zakończy swoją pracę za pomocą funkcji wyjścia, funkcja ta zajmie się zabiciem procesu satelity. Jeśli proces peryferyjny przechwytuje sygnały przerwań, wywołuje funkcję obsługi sygnałów zdefiniowaną przez użytkownika i zwraca kod błędu użytkownikowi po wyjściu z funkcji odczytu. Z drugiej strony, jeśli satelita wykonuje funkcję systemu stat w imieniu procesu peryferyjnego, nie przerwie jego wykonywania po odebraniu sygnału (funkcja stat ma gwarancję wyjścia z każdej pauzy, ponieważ ma ograniczony czas oczekiwania na zasoby ). Satelita kończy wykonywanie funkcji i zwraca numer sygnału do procesu peryferyjnego. Proces peryferyjny wysyła do siebie sygnał i odbiera go przy wyjściu z funkcji systemowej.

Jeśli sygnał pojawi się na procesorze peryferyjnym podczas wykonywania funkcji systemowej, proces peryferyjny nie będzie wiedział, czy wkrótce powróci do sterowania z procesu satelitarnego, czy ten ostatni przejdzie w stan zawieszenia na czas nieokreślony. Proces peryferyjny wysyła do satelity specjalną wiadomość informującą go o pojawieniu się sygnału. Rdzeń w CPU odszyfrowuje wiadomość i wysyła sygnał do satelity, którego reakcja na odebranie sygnału została opisana w poprzednich akapitach (nieprawidłowe zakończenie wykonywania funkcji lub jej zakończenie). Proces peryferyjny nie może wysłać wiadomości bezpośrednio do satelity, ponieważ satelita jest zajęty wykonywaniem funkcji systemowych i nie odczytuje danych z linii komunikacyjnej.

Odnosząc się do przykładu odczytu, należy zauważyć, że proces peryferyjny nie ma pojęcia, czy jego towarzysz czeka na dane wejściowe z terminala, czy też wykonuje inne działania. Proces peryferyjny wysyła wiadomość sygnałową do satelity: jeśli satelita jest w stanie zawieszenia z przerywanym priorytetem, natychmiast wychodzi z tego stanu i kończy działanie systemu; w przeciwnym razie funkcja jest przenoszona do pomyślnego zakończenia.

Na koniec rozważmy przypadek nadejścia sygnału w czasie niezwiązanym z wykonaniem funkcji systemu. Jeśli sygnał pochodzi z innego procesora, satelita odbiera go jako pierwszy i wysyła wiadomość sygnałową do procesu peryferyjnego, niezależnie od tego, czy sygnał dotyczy procesu peryferyjnego, czy nie. Rdzeń peryferyjny odszyfrowuje wiadomość i wysyła sygnał do procesu, który reaguje na nią w zwykły sposób. Jeśli sygnał pochodzi z procesora peryferyjnego, proces wykonuje standardowe czynności bez korzystania z usług swojego satelity.

Gdy proces peryferyjny wysyła sygnał do innych procesów peryferyjnych, koduje komunikat o zabiciu i wysyła go do procesu satelitarnego, który lokalnie wykonuje wywołaną funkcję. Jeśli któryś z procesów, dla których przeznaczony jest sygnał, znajduje się na innych procesorach peryferyjnych, ich satelity odbiorą sygnał (i zareagują na niego w sposób opisany powyżej).

13.2 TYP KOMUNIKACJI NEWCASTLE

W poprzedniej sekcji rozważaliśmy rodzaj systemu ściśle powiązanego, który charakteryzuje się wysyłaniem wszystkich wywołań funkcji podsystemu zarządzania plikami, które powstają na procesorze peryferyjnym, do zdalnego (centralnego) procesora. Przejdziemy teraz do rozważenia systemów o słabszym połączeniu, które składają się z maszyn wywołujących pliki znajdujące się na innych maszynach. Na przykład w sieci komputerów osobistych i stacji roboczych użytkownicy często uzyskują dostęp do plików znajdujących się na dużym komputerze. W kolejnych dwóch rozdziałach przyjrzymy się konfiguracjom systemu, w których wszystkie funkcje systemowe są wykonywane w podsystemach lokalnych, ale jednocześnie możliwy jest dostęp do plików (poprzez funkcje podsystemu zarządzania plikami) znajdujących się na innych maszynach.

Systemy te wykorzystują jedną z dwóch następujących ścieżek do identyfikacji usuniętych plików. W niektórych systemach do złożonej nazwy pliku dodawany jest znak specjalny: składnik nazwy poprzedzający ten znak identyfikuje komputer, reszta nazwy to plik na tym komputerze. Na przykład nazwa wyróżniająca

„sftig! / fs1 / mjb / rje”

identyfikuje plik "/fs1/mjb/rje" na maszynie "sftig". Ten schemat identyfikacji plików jest zgodny z konwencją uucp dotyczącą przesyłania plików między systemami typu UNIX. W innym schemacie usunięte pliki identyfikowane są poprzez dodanie do nazwy specjalnego prefiksu, na przykład:

/../sftig/fs1/mjb/rje

gdzie "/../" jest prefiksem wskazującym, że plik został usunięty; drugim składnikiem nazwy pliku jest nazwa zdalnej maszyny. Ten schemat wykorzystuje znaną składnię nazw plików UNIX, więc w przeciwieństwie do pierwszego schematu, programy użytkownika nie muszą dostosowywać się do używania nazw o nietypowej konstrukcji (patrz).

Rysunek 13.9. Formułowanie żądań do serwera plików (procesora)

Resztę tej sekcji poświęcimy modelowi systemu korzystającego z łącza Newcastle, w którym jądro nie zajmuje się rozpoznawaniem usuniętych plików; funkcja ta jest w całości przypisana do podprogramów ze standardowej biblioteki C, które w tym przypadku pełnią rolę interfejsu systemowego. Procedury te analizują pierwszy składnik nazwy pliku, który w obu opisanych metodach identyfikacji zawiera znak oddalenia pliku. Jest to odejście od procedury, w której procedury biblioteczne nie analizują nazw plików. Rysunek 13.9 przedstawia sposób formułowania żądań do serwera plików. Jeśli plik jest lokalny, jądro systemu lokalnego przetwarza żądanie normalnie. Rozważ odwrotny przypadek:

otwórz ("/../ sftig / fs1 / mjb / rje / plik", O_RDONLY);

Otwarty podprogram w bibliotece C analizuje dwa pierwsze składniki wyróżnionej nazwy pliku i wie, jak szukać pliku na zdalnej maszynie „sftig”. Aby uzyskać informację o tym, czy proces miał wcześniej połączenie z daną maszyną, podprogram uruchamia specjalną strukturę, w której pamięta o tym fakcie iw przypadku negatywnej odpowiedzi nawiązuje połączenie z serwerem plików uruchomionym na zdalnej maszynie. Gdy proces formułuje swoje pierwsze żądanie zdalnego przetwarzania, zdalny serwer potwierdza żądanie, jeśli to konieczne, zapisuje w polach kodów identyfikacyjnych użytkownika i grupy i tworzy proces satelitarny, który będzie działał w imieniu procesu klienta.

Aby spełnić żądania klientów, satelita musi mieć takie same uprawnienia do plików na komputerze zdalnym jak klient. Innymi słowy, użytkownik „mjb” musi mieć takie same prawa dostępu do plików zdalnych i lokalnych. Niestety możliwe jest, że kod identyfikacyjny klienta „mjb” może pokrywać się z kodem identyfikacyjnym innego klienta na zdalnym komputerze. Dlatego administratorzy systemu na maszynach działających w sieci powinni albo upewnić się, że każdemu użytkownikowi przypisano kod identyfikacyjny, który jest unikalny dla całej sieci, albo przeprowadzić konwersję kodu w momencie formułowania żądania usługi sieciowej. Jeśli nie zostanie to zrobione, proces towarzyszący będzie miał prawa innego klienta na zdalnym komputerze.

Bardziej delikatną kwestią jest uzyskanie uprawnień administratora w związku z pracą z plikami zdalnymi. Z jednej strony, klient superużytkownika nie powinien mieć takich samych praw w systemie zdalnym, aby nie wprowadzać w błąd kontroli bezpieczeństwa systemu zdalnego. Z drugiej strony, niektóre programy, jeśli nie otrzymają praw administratora, po prostu nie będą mogły działać. Przykładem takiego programu jest program mkdir (patrz rozdział 7), który tworzy nowy katalog. Zdalny system nie pozwoliłby klientowi na utworzenie nowego katalogu, ponieważ przy usuwaniu nie obowiązują prawa administratora. Problem tworzenia zdalnych katalogów jest poważnym powodem zrewidowania funkcji systemowej mkdir w kierunku rozszerzenia jej możliwości w zakresie automatycznego nawiązywania wszystkich połączeń niezbędnych dla użytkownika. Jednak nadal częstym problemem jest to, że programy z setuid (takie jak program mkdir) uzyskują uprawnienia superużytkownika nad plikami zdalnymi. Być może najlepszym rozwiązaniem tego problemu byłoby ustawienie dodatkowych charakterystyk dla plików, które opisują dostęp do nich przez zdalnych superużytkowników; niestety wymagałoby to zmian w strukturze indeksu dysku (w zakresie dodawania nowych pól) i spowodowałoby zbyt duży bałagan w istniejących systemach.

Jeśli otwarty podprogram się powiedzie, lokalna biblioteka pozostawia odpowiednią notatkę na ten temat w dostępnej dla użytkownika strukturze zawierającej adres węzła sieci, identyfikator procesu satelity, deskryptor pliku i inne podobne informacje. Podprogramy biblioteczne, które czytają i zapisują, określają, na podstawie deskryptora pliku, czy plik jest usunięty, a jeśli tak, wysyłają wiadomość do satelity. Proces klienta współdziała ze swoim towarzyszem we wszystkich przypadkach dostępu do funkcji systemu, które wymagają usług zdalnej maszyny. Jeśli proces uzyskuje dostęp do dwóch plików znajdujących się na tym samym zdalnym komputerze, używa jednego satelity, ale jeśli pliki znajdują się na różnych komputerach, dwa satelity są już używane: po jednym na każdym komputerze. Dwie satelity są również używane, gdy dwa procesy uzyskują dostęp do pliku na zdalnym komputerze. Poprzez wywołanie funkcji systemu za pośrednictwem satelity, proces generuje komunikat zawierający numer funkcji, nazwę ścieżki wyszukiwania i inne niezbędne informacje, podobne do zawartych w strukturze komunikatu w systemie z procesorami peryferyjnymi.

Mechanizm wykonywania operacji na bieżącym katalogu jest bardziej złożony. Kiedy proces wybiera zdalny katalog jako bieżący, procedura biblioteczna wysyła komunikat do satelity, który zmienia bieżący katalog, a procedura pamięta, że ​​katalog został usunięty. We wszystkich przypadkach, w których nazwa ścieżki wyszukiwania zaczyna się od znaku innego niż ukośnik (/), podprogram wysyła nazwę do zdalnej maszyny, gdzie proces satelitarny kieruje ją z bieżącego katalogu. Jeśli bieżący katalog jest lokalny, procedura po prostu przekazuje nazwę ścieżki wyszukiwania do lokalnego jądra systemu. Systemowa funkcja chroot w zdalnym katalogu jest podobna, ale pozostaje niezauważona dla jądra lokalnego; ściśle mówiąc, proces może zignorować tę operację, ponieważ tylko biblioteka rejestruje jej wykonanie.

Kiedy proces wywołuje fork, odpowiednia procedura biblioteczna wysyła komunikaty do każdego satelity. Procesy satelitów rozgałęziają się i wysyłają swoje identyfikatory podrzędne do klienta nadrzędnego. Proces klienta uruchamia funkcję systemu rozwidlenia, która przekazuje kontrolę dziecku, które tworzy; lokalne dziecko prowadzi dialog ze zdalnym dzieckiem satelity, którego adresy są przechowywane przez procedurę biblioteczną. Taka interpretacja funkcji rozwidlenia ułatwia procesom satelity kontrolowanie otwartych plików i bieżących katalogów. Kiedy proces pracujący ze zdalnymi plikami kończy działanie (wywołując funkcję exit), podprogram wysyła komunikaty do wszystkich swoich zdalnych satelitów, aby robiły to samo po otrzymaniu komunikatu. W ćwiczeniach omawiane są niektóre aspekty implementacji funkcji exec i exit systemu.

Zaletą łącza Newcastle jest to, że dostęp procesu do zdalnych plików staje się przezroczysty (niewidoczny dla użytkownika), bez konieczności wprowadzania jakichkolwiek zmian w jądrze systemowym. Ten rozwój ma jednak szereg wad. Przede wszystkim w trakcie jego implementacji możliwy jest spadek wydajności systemu. Dzięki wykorzystaniu rozszerzonej biblioteki C zwiększa się rozmiar pamięci używanej przez każdy proces, nawet jeśli proces nie ma dostępu do zdalnych plików; biblioteka duplikuje funkcje jądra i wymaga więcej miejsca w pamięci. Zwiększenie rozmiaru procesów wydłuża okres uruchamiania i może powodować większą rywalizację o zasoby pamięci, stwarzając warunki do częstszego rozładowywania i stronicowania zadań. Żądania lokalne będą wykonywane wolniej ze względu na wydłużenie czasu trwania każdego wywołania do jądra, a przetwarzanie żądań zdalnych również może zostać spowolnione, wzrasta koszt przesyłania ich przez sieć. Dodatkowe przetwarzanie żądań zdalnych na poziomie użytkownika zwiększa liczbę przełączeń kontekstu, operacji rozładowywania i zamiany. Wreszcie, aby uzyskać dostęp do zdalnych plików, programy muszą zostać ponownie skompilowane przy użyciu nowych bibliotek; stare programy i dostarczone moduły obiektowe nie będą mogły bez niego pracować z plikami zdalnymi. Wszystkie te wady są nieobecne w systemie opisanym w następnej sekcji.

13.3 „PRZEZROCZYSTE” ROZPROSZONE SYSTEMY PLIKÓW

Termin „przejrzysta alokacja” oznacza, że ​​użytkownicy na jednej maszynie mogą uzyskiwać dostęp do plików na innej maszynie, nie zdając sobie sprawy, że przekraczają granice maszyn, tak jak na swojej maszynie, gdy przechodzą z jednego systemu plików na inny, przechodząc przez punkty montowania. Nazwy, za pomocą których procesy odwołują się do plików znajdujących się na zdalnych komputerach, są podobne do nazw plików lokalnych: nie ma w nich znaków wyróżniających. W konfiguracji pokazanej na rysunku 13.10 katalog „/ usr / src” należący do maszyny B jest „zamontowany” w katalogu „/usr / src” należącym do maszyny A. ten sam kod źródłowy systemu, tradycyjnie znajduje się w „/ usr / src”. Użytkownicy działający na komputerze A mogą uzyskać dostęp do plików znajdujących się na komputerze B przy użyciu zwykłej składni zapisywania nazw plików (na przykład: "/usr/src/cmd/login.c"), a jądro samo decyduje, czy plik jest zdalny, czy lokalny . Użytkownicy działający na komputerze B mają dostęp do swoich plików lokalnych (nie wiedząc, że użytkownicy komputera A mogą uzyskać dostęp do tych samych plików), ale z kolei nie mają dostępu do plików znajdujących się na komputerze A. Oczywiście możliwe są inne opcje, w w szczególności te, w których wszystkie systemy zdalne są zamontowane w katalogu głównym systemu lokalnego, dzięki czemu użytkownicy mogą uzyskać dostęp do wszystkich plików we wszystkich systemach.

Rysunek 13.10. Systemy plików po zdalnym montażu

Podobieństwa między montowaniem lokalnych systemów plików a umożliwieniem dostępu do zdalnych systemów plików skłoniły do ​​adaptacji funkcji montowania do zdalnych systemów plików. W tym przypadku jądro ma do dyspozycji tablicę montowań o rozszerzonym formacie. Wykonując funkcję montowania, jądro organizuje połączenie sieciowe ze zdalną maszyną i przechowuje informacje charakteryzujące to połączenie w tabeli montowania.

Interesujący problem dotyczy nazw ścieżek zawierających „..”. Jeśli proces tworzy bieżący katalog ze zdalnego systemu plików, użycie znaków „..” w nazwie z większym prawdopodobieństwem zwróci proces do lokalnego systemu plików, zamiast uzyskać dostęp do plików znajdujących się powyżej bieżącego katalogu. Wracając ponownie do rysunku 13.10, zauważ, że gdy proces należący do komputera A, po wcześniejszym wybraniu bieżącego katalogu „/usr/src/cmd” znajdującego się w zdalnym systemie plików, wykona polecenie

bieżący katalog będzie katalogiem głównym maszyny A, a nie maszyny B. Algorytm namei w jądrze zdalnego systemu po odebraniu ciągu znaków „..” sprawdza, czy proces wywołujący jest agentem procesu klienta , a jeśli tak, ustawia, czy klient traktuje bieżący katalog roboczy jako katalog główny zdalnego systemu plików.

Komunikacja ze zdalną maszyną przybiera jedną z dwóch form: zdalne wywołanie procedury lub zdalne wywołanie funkcji systemowej. W pierwszej postaci każda procedura jądra zajmująca się indeksami sprawdza, czy indeks wskazuje na zdalny plik, a jeśli tak, wysyła żądanie do zdalnej maszyny, aby wykonać określoną operację. Schemat ten w naturalny sposób wpisuje się w abstrakcyjną strukturę obsługi systemów plików różnego typu, opisaną w końcowej części rozdziału 5. Tym samym dostęp do zdalnego pliku może zainicjować transmisję kilku komunikatów przez sieć, których liczba wynosi określana przez liczbę dorozumianych operacji na pliku, z odpowiednim wzrostem czasu odpowiedzi na żądanie, z uwzględnieniem czasu oczekiwania zaakceptowanego w sieci. Każdy zestaw zdalnych operacji zawiera co najmniej akcje blokowania indeksu, zliczania referencji itp. W celu udoskonalenia modelu zaproponowano różne rozwiązania optymalizacyjne związane z łączeniem kilku operacji w jedno zapytanie (wiadomość) i buforowaniem najważniejszych danych (cm). ).

Rysunek 13.11. Otwieranie zdalnego pliku

Rozważ proces, który otwiera zdalny plik „/usr/src/cmd/login.c”, gdzie „src” jest punktem montowania. Analizując nazwę pliku (przy użyciu schematu namei-iget), jądro wykrywa, że ​​plik został usunięty i wysyła do hosta żądanie uzyskania zablokowanego indeksu. Po otrzymaniu żądanej odpowiedzi jądro lokalne tworzy kopię indeksu w pamięci odpowiadającej plikowi zdalnemu. Następnie jądro sprawdza niezbędne prawa dostępu do pliku (na przykład do odczytu), wysyłając kolejną wiadomość do zdalnej maszyny. Otwarty algorytm działa zgodnie z planem przedstawionym w rozdziale 5, wysyłając komunikaty do zdalnej maszyny w razie potrzeby, aż do zakończenia algorytmu i zwolnienia indeksu. Zależność między strukturami danych jądra po zakończeniu otwartego algorytmu pokazano na rysunku 13.11.

Jeśli klient wywołuje funkcję odczytu systemu, jądro klienta blokuje indeks lokalny, blokuje indeks zdalny, żąda odczytu, kopiuje dane do pamięci lokalnej, wysyła żądanie zwolnienia indeksu zdalnego i zwalnia indeks lokalny . Schemat ten jest zgodny z semantyką istniejącego jądra jednoprocesorowego, ale częstotliwość korzystania z sieci (wielokrotne wywołania każdej funkcji systemowej) zmniejsza wydajność całego systemu. Jednak w celu zmniejszenia przepływu komunikatów w sieci można połączyć wiele operacji w jedno żądanie. W przykładzie z funkcją odczytu klient może wysłać do serwera jedno ogólne żądanie „odczytu”, a sam serwer decyduje o przechwyceniu i zwolnieniu indeksu po jego wykonaniu. Zmniejszenie ruchu w sieci można również osiągnąć za pomocą buforów zdalnych (jak omówiliśmy powyżej), ale należy zadbać o to, aby funkcje plików systemowych korzystające z tych buforów były wykonywane prawidłowo.

W drugiej formie komunikacji ze zdalną maszyną (wywołanie zdalnej funkcji systemowej) jądro lokalne wykrywa, że ​​funkcja systemowa jest powiązana ze zdalnym plikiem i wysyła parametry określone w swoim wywołaniu do zdalnego systemu, który wykonuje funkcji i zwraca wyniki do klienta. Maszyna klienta odbiera wyniki wykonania funkcji i wychodzi ze stanu wywołania. Większość funkcji systemu można wykonać za pomocą tylko jednego żądania sieciowego i otrzymać odpowiedź po rozsądnym czasie, ale nie wszystkie funkcje pasują do tego modelu. Na przykład po odebraniu określonych sygnałów jądro tworzy plik dla procesu o nazwie „rdzeń” (rozdział 7). Utworzenie tego pliku nie jest związane z konkretną funkcją systemu, ale kończy się wykonaniem kilku operacji, takich jak tworzenie pliku, sprawdzanie uprawnień i wykonywanie serii zapisów.

W przypadku funkcji systemu otwartego żądanie wykonania funkcji wysyłane do maszyny zdalnej zawiera część nazwy pliku pozostałą po wykluczeniu składników nazwy ścieżki wyszukiwania, które odróżniają plik zdalny, a także różne flagi. We wcześniejszym przykładzie otwarcia pliku "/usr/src/cmd/login.c" jądro wysyła nazwę "cmd/login.c" do maszyny zdalnej. Wiadomość zawiera również dane uwierzytelniające, takie jak kody identyfikacyjne użytkownika i grupy, które są wymagane do weryfikacji uprawnień do plików na zdalnym komputerze. Jeśli ze zdalnego komputera zostanie odebrana odpowiedź wskazująca na pomyślne otwarcie funkcji, lokalne jądro pobiera wolny indeks z pamięci komputera lokalnego i oznacza go jako zdalny indeks pliku, przechowuje informacje o zdalnym komputerze i zdalnym indeksie oraz rutynowo przydziela nowy wpis w tabeli plików. W porównaniu z rzeczywistym indeksem na komputerze zdalnym, indeks należący do komputera lokalnego jest formalny i nie narusza konfiguracji modelu, która jest zasadniczo taka sama, jak konfiguracja używana podczas wywoływania procedury zdalnej (rysunek 13.11). Jeśli funkcja wywołana przez proces uzyskuje dostęp do zdalnego pliku poprzez jego deskryptor, lokalne jądro wie z (lokalnego) indeksu, że plik jest zdalny, formułuje żądanie zawierające wywołaną funkcję i wysyła je do zdalnego komputera. Żądanie zawiera wskaźnik do zdalnego indeksu, za pomocą którego proces satelicki może zidentyfikować sam plik zdalny.

Po otrzymaniu wyniku wykonania dowolnej funkcji systemowej, jądro może skorzystać z usług specjalnego programu do jego przetworzenia (po zakończeniu którego jądro zakończy pracę z funkcją), ponieważ lokalne przetwarzanie wyników wykorzystywane w systemie jednoprocesorowym nie zawsze jest odpowiedni dla systemu z kilkoma procesorami. Dzięki temu możliwe są zmiany w semantyce algorytmów systemowych, mające na celu wsparcie realizacji zdalnych funkcji systemowych. Jednocześnie jednak w sieci krąży minimalny przepływ komunikatów, zapewniając minimalny czas odpowiedzi systemu na przychodzące żądania.

13.4 MODEL ROZPROSZONY BEZ PROCESÓW TRANSFERU

Wykorzystanie procesów transferu (procesów satelitarnych) w przejrzystym systemie rozproszonym ułatwia śledzenie usuniętych plików, ale tabela procesów systemu zdalnego jest przeładowana procesami satelitarnymi, które przez większość czasu są bezczynne. W innych schematach do przetwarzania żądań zdalnych wykorzystywane są specjalne procesy serwera (patrz i). System zdalny ma zestaw (pulę) procesów serwera, które od czasu do czasu przypisuje do przetwarzania przychodzących zdalnych żądań. Po przetworzeniu żądania proces serwera powraca do puli i przechodzi w stan gotowości do przetwarzania innych żądań. Serwer nie zapisuje kontekstu użytkownika między dwoma wywołaniami, ponieważ może przetwarzać żądania z kilku procesów jednocześnie. Dlatego każda wiadomość przychodząca z procesu klienta musi zawierać informacje o środowisku jego wykonania, czyli: kody identyfikujące użytkownika, bieżący katalog, sygnały itp. funkcje.

Kiedy proces otwiera zdalny plik, zdalne jądro przypisuje indeks dla kolejnych dowiązań do pliku. Maszyna lokalna utrzymuje niestandardową tablicę deskryptorów plików, tablicę plików i tablicę indeksu ze zwykłym zestawem rekordów, z wpisem tablicy indeksu identyfikującym zdalny komputer i zdalny indeks. W przypadkach, gdy funkcja systemowa (na przykład odczyt) używa deskryptora pliku, jądro wysyła komunikat wskazujący na wcześniej przypisany zdalny indeks i przekazuje informacje związane z procesem: kod identyfikacyjny użytkownika, maksymalny rozmiar pliku itp. maszyna ma procesu serwera do jego dyspozycji, interakcja z klientem przybiera postać opisaną wcześniej, jednak połączenie pomiędzy klientem a serwerem nawiązywane jest tylko na czas funkcjonowania systemu.

Używanie serwerów zamiast procesów satelitarnych może utrudnić zarządzanie ruchem danych, sygnałami i urządzeniami zdalnymi. Duża liczba żądań do zdalnej maszyny w przypadku braku wystarczającej liczby serwerów powinna być ustawiana w kolejce. Wymaga to protokołu wyższej warstwy niż ten używany w sieci głównej. Z drugiej strony w modelu satelitarnym przesycenie jest eliminowane, ponieważ wszystkie żądania klientów są przetwarzane synchronicznie. Klient może mieć co najwyżej jedno oczekujące żądanie.

Przetwarzanie sygnałów, które przerywają wykonywanie funkcji systemu, jest również skomplikowane w przypadku korzystania z serwerów, ponieważ zdalna maszyna musi szukać odpowiedniego serwera służącego do wykonania funkcji. Możliwe nawet, że ze względu na zajętość wszystkich serwerów żądanie funkcji systemu oczekuje na przetworzenie. Warunki do powstania konkurencji powstają również wtedy, gdy serwer zwraca wynik funkcji systemu do procesu wywołującego, a odpowiedź serwera obejmuje wysłanie przez sieć odpowiedniego komunikatu sygnalizacyjnego. Każda wiadomość musi być oznaczona, aby zdalny system mógł ją rozpoznać i, jeśli to konieczne, zakończyć procesy serwera. W przypadku korzystania z satelitów proces, który obsługuje realizację żądania klienta jest automatycznie identyfikowany, a w przypadku nadejścia sygnału nie jest trudno sprawdzić, czy żądanie zostało przetworzone, czy nie.

Wreszcie, jeśli funkcja systemowa wywołana przez klienta powoduje, że serwer zatrzymuje się na czas nieokreślony (na przykład podczas odczytywania danych ze zdalnego terminala), serwer nie może przetwarzać innych żądań w celu zwolnienia puli serwerów. Jeśli kilka procesów uzyskuje dostęp do zdalnych urządzeń jednocześnie, a liczba serwerów jest ograniczona z góry, powstaje dość namacalne wąskie gardło. Nie dzieje się tak w przypadku satelitów, ponieważ satelita jest przydzielana do każdego procesu klienta. Inny problem związany z używaniem serwerów dla urządzeń zdalnych zostanie omówiony w ćwiczeniu 13.14.

Pomimo korzyści, jakie daje wykorzystanie procesów satelitarnych, potrzeba wolnych wpisów w tablicy procesów w praktyce staje się tak dotkliwa, że ​​w większości przypadków usługi procesów serwerowych są nadal wykorzystywane do obsługi zdalnych żądań.

Rysunek 13.12. Schemat koncepcyjny interakcji z plikami zdalnymi na poziomie jądra

13.5 WNIOSKI

W tym rozdziale rozważyliśmy trzy schematy pracy z plikami znajdującymi się na zdalnych maszynach, traktując zdalne systemy plików jako rozszerzenie lokalnego. Różnice architektoniczne między tymi układami pokazano na rysunku 13.12. Wszystkie one z kolei różnią się od systemów wieloprocesorowych opisanych w poprzednim rozdziale tym, że procesory tutaj nie współdzielą pamięci fizycznej. System procesorów peryferyjnych składa się z ściśle połączonego zestawu procesorów, które współdzielą zasoby plików procesora centralnego. Połączenie typu Newcastle zapewnia ukryty ("przezroczysty") dostęp do zdalnych plików, ale nie za pośrednictwem jądra systemu operacyjnego, ale poprzez użycie specjalnej biblioteki C. Z tego powodu wszystkie programy, które zamierzają używać tego typu łącza, muszą zostać ponownie skompilowane, co ogólnie jest poważną wadą tego schematu. Oddalenie pliku jest wskazywane za pomocą specjalnej sekwencji znaków opisującej maszynę, na której znajduje się plik, i jest to kolejny czynnik ograniczający przenośność programów.

W przezroczystych systemach rozproszonych modyfikacja funkcji systemu montowania służy do uzyskiwania dostępu do zdalnych plików. Indeksy w systemie lokalnym są oznaczane jako pliki zdalne, a jądro lokalne wysyła do systemu zdalnego komunikat opisujący żądaną funkcję systemu, jej parametry i zdalny indeks. Komunikacja w „przejrzystym” systemie rozproszonym obsługiwana jest w dwóch formach: w formie wywołania procedury zdalnej (do zdalnej maszyny wysyłana jest wiadomość zawierająca listę operacji związanych z indeksem) oraz w formie wywołania do zdalnej funkcji systemu (komunikat opisuje żądaną funkcję). W końcowej części rozdziału omówiono zagadnienia związane z przetwarzaniem zdalnych żądań z wykorzystaniem procesów i serwerów satelitarnych.

13.6 ĆWICZENIA

*1. Opisać implementację funkcji systemu wyjścia w systemie z procesorami peryferyjnymi. Jaka jest różnica między tym przypadkiem a zakończeniem procesu po otrzymaniu nieprzechwyconego sygnału? Jak jądro powinno zrzucić zawartość pamięci?

2. Procesy nie mogą ignorować sygnałów SIGKILL; Wyjaśnij, co dzieje się w systemie peryferyjnym, gdy proces otrzyma taki sygnał.

* 3. Opisz implementację funkcji systemu exec w systemie z procesorami peryferyjnymi.

*4. W jaki sposób procesor centralny powinien rozdzielić procesy między procesorami peryferyjnymi, aby zrównoważyć całkowite obciążenie?

*5. Co się stanie, jeśli procesor peryferyjny nie ma wystarczającej ilości pamięci, aby pomieścić wszystkie odciążone na nim procesy? Jak powinno przebiegać rozładowywanie i zamiana procesów w sieci?

6. Rozważ system, w którym żądania do zdalnego serwera plików są wysyłane, jeśli w nazwie pliku znajduje się specjalny prefiks. Niech proces wywoła execl ("/../ sftig / bin / sh", "sh", 0); Plik wykonywalny znajduje się na zdalnym komputerze, ale musi być uruchomiony w systemie lokalnym. Wyjaśnij, w jaki sposób moduł zdalny jest migrowany do systemu lokalnego.

7. Jeśli administrator musi dodać nowe maszyny do istniejącego systemu z połączeniem takim jak Newcastle, to w jaki sposób najlepiej poinformować o tym moduły biblioteki C?

*osiem. Podczas wykonywania funkcji exec jądro nadpisuje przestrzeń adresową procesu, w tym tabele bibliotek używane przez łącze Newcastle do śledzenia łączy do zdalnych plików. Po wykonaniu funkcji proces musi zachować możliwość dostępu do tych plików za pomocą ich starych deskryptorów. Opisz realizację tego punktu.

*dziewięć. Jak pokazano w sekcji 13.2, wywołanie funkcji exit system w systemach z połączeniem Newcastle powoduje wysłanie komunikatu do procesu towarzyszącego, zmuszając go do zakończenia. Odbywa się to na poziomie procedur bibliotecznych. Co się dzieje, gdy proces lokalny otrzyma sygnał, który nakazuje mu wyjście z trybu jądra?

*dziesięć. W systemie z dowiązaniem Newcastle, w którym zdalne pliki są identyfikowane przez poprzedzenie nazwy specjalnym przedrostkiem, w jaki sposób użytkownik, określając ".." (katalog nadrzędny) jako składnik nazwy pliku, może przejść przez zdalny punkt montowania?

11. Wiemy z rozdziału 7, że różne sygnały powodują, że proces zrzuca zawartość pamięci do bieżącego katalogu. Co powinno się stać, jeśli bieżący katalog pochodzi ze zdalnego systemu plików? Jaką odpowiedź byś udzielił, gdyby system używał relacji takich jak Newcastle?

*12. Jakie konsekwencje dla procesów lokalnych miałoby to, gdyby wszystkie procesy satelity lub serwera zostały usunięte z systemu?

*13. Zastanów się, jak zaimplementować algorytm łącza w przezroczystym systemie rozproszonym, którego parametrami mogą być dwie zdalne nazwy plików, a także algorytm exec, związany z wykonywaniem kilku wewnętrznych operacji odczytu. Rozważ dwie formy komunikacji: zdalne wywołanie procedury i zdalne wywołanie funkcji systemowej.

*czternaście. Podczas dostępu do urządzenia proces serwera może wejść w stan wstrzymania, z którego zostanie wyprowadzony przez sterownik urządzenia. Oczywiście, jeśli liczba serwerów jest ograniczona, system nie będzie już w stanie zaspokoić żądań lokalnej maszyny. Wymyśl niezawodny schemat, w którym nie wszystkie procesy serwera są zawieszane podczas oczekiwania na zakończenie operacji we/wy związanych z urządzeniem. Funkcja systemu nie zakończy się, gdy wszystkie serwery są zajęte.

Rysunek 13.13. Konfiguracja serwera terminali

*15. Gdy użytkownik loguje się do systemu, dyscyplina linii terminala przechowuje informację, że terminal jest terminalem operatora kierującym grupą procesów. Z tego powodu, gdy użytkownik naciśnie klawisz „break” na klawiaturze terminala, wszystkie procesy w grupie otrzymują sygnał przerwania. Rozważ konfigurację systemu, w której wszystkie terminale są fizycznie podłączone do jednego komputera, ale rejestracja użytkownika jest logicznie zaimplementowana na innych komputerach (rysunek 13.13). W każdym przypadku system tworzy proces getty dla zdalnego terminala. Jeśli żądania kierowane do systemu zdalnego są przetwarzane przez zestaw procesów serwera, należy zauważyć, że po wykonaniu procedury otwartej serwer przestaje czekać na połączenie. Po zakończeniu funkcji open serwer wraca do puli serwerów, zrywając połączenie z terminalem. W jaki sposób wyzwalany jest sygnał przerwania po naciśnięciu klawisza „break” wysyłany na adresy procesów znajdujących się w tej samej grupie?

*16. Współdzielenie pamięci to funkcja nieodłącznie związana z maszynami lokalnymi. Z logicznego punktu widzenia alokację wspólnego obszaru pamięci fizycznej (lokalnej lub zdalnej) można przeprowadzić dla procesów należących do różnych maszyn. Opisz realizację tego punktu.

* 17. Proces stronicowania i algorytmy stronicowania omówione w rozdziale 9 zakładają użycie lokalnego pagera. Jakie zmiany należy wprowadzić w tych algorytmach, aby móc obsługiwać urządzenia do zdalnego odciążania?

*osiemnaście. Załóżmy, że na zdalnej maszynie (lub sieci) doszło do krytycznej awarii, a protokół warstwy sieci lokalnej rejestruje ten fakt. Opracuj schemat odzyskiwania dla systemu lokalnego, który wysyła żądania do serwera zdalnego. Ponadto opracuj schemat przywracania systemu serwerowego, który utracił kontakt z klientami.

*19. Gdy proces uzyskuje dostęp do pliku zdalnego, możliwe jest, że proces będzie przeszukiwał wiele komputerów w poszukiwaniu pliku. Weźmy jako przykład nazwę „/ usr / src / uts / 3b2 / os”, gdzie „/ usr” to katalog należący do maszyny A, „/ usr / src” to punkt montowania katalogu głównego maszyny B, „ / usr / src / uts / 3b2 " jest punktem montowania katalogu głównego maszyny C. Przejście przez wiele maszyn do miejsca docelowego nazywa się multiskokiem. Jeśli jednak istnieje bezpośrednie połączenie sieciowe między maszynami A i C, wysyłanie danych przez maszynę B byłoby nieefektywne. Opisz cechy implementacji „multizakupów” w systemie z połączeniem Newcastle oraz w „przejrzystym” systemie rozproszonym.

Obecnie wszystkie tworzone dla celów komercyjnych IS mają architekturę rozproszoną, co implikuje wykorzystanie globalnych i/lub lokalnych sieci komputerowych.

Historycznie, architektura serwera plików była pierwszą, która upowszechniła się, ponieważ jej logika jest prosta i najłatwiej jest przenieść do takiej architektury IS, które już są w użyciu. Następnie została przekształcona w architekturę serwer-klient, co można interpretować jako jej logiczną kontynuację. Współczesne systemy stosowane w globalnej sieci INTERNET dotyczą głównie architektury obiektów rozproszonych (patrz rys. III‑15 )

Można sobie wyobrazić, że IS składa się z następujących elementów (rys. III-16)

III.03.2. Aplikacje serwera plików.

Jest to historycznie pierwsza architektura rozproszona (ryc. III-17). Jest zorganizowany bardzo prosto: na serwerze znajdują się tylko dane, a wszystko inne należy do maszyny klienta. Ponieważ sieci lokalne są dość tanie, a także ze względu na to, że przy takiej architekturze oprogramowanie aplikacyjne jest autonomiczne, taka architektura jest dziś często stosowana. Można powiedzieć, że jest to wariant architektury klient-serwer, w której na serwerze znajdują się jedynie pliki danych. Różne komputery osobiste współdziałają tylko za pomocą wspólnego magazynu danych, dlatego programy napisane dla jednego komputera najłatwiej dostosować do takiej architektury.

Plusy:

Zalety architektury serwera plików:

Łatwość organizacji;

Nie jest sprzeczny z niezbędnymi wymaganiami bazy danych, aby zachować integralność i niezawodność.

Przeciążenie sieci;

Nieprzewidywalna odpowiedź na prośbę.

Te wady tłumaczy się tym, że każde żądanie do bazy danych prowadzi do przesyłania znacznych ilości informacji przez sieć. Na przykład, aby wybrać jeden lub kilka wierszy z tabel, cała tabela jest pobierana na komputer klienta, a DBMS już tam wybiera. Duży ruch w sieci jest szczególnie obciążony organizacją zdalnego dostępu do bazy danych.

III.03.2. b Aplikacje klient-serwer.

W tym przypadku następuje podział odpowiedzialności między serwerem a klientem. W zależności od tego, jak są rozdzielone, rozróżnij gruby oraz cienki klient.

W modelu cienkiego klienta cała praca aplikacji i zarządzanie danymi odbywa się na serwerze. Interfejs użytkownika w tych systemach „migruje” do komputera osobistego, a sama aplikacja pełni funkcje serwera, tj. uruchamia wszystkie procesy aplikacyjne i zarządza danymi. Model cienkiego klienta można również zaimplementować tam, gdzie klientami są komputery lub stacje robocze. Na urządzeniach sieciowych uruchomiona jest przeglądarka internetowa oraz zaimplementowany w systemie interfejs użytkownika.

Główny wada modele cienkiego klienta - duże obciążenie serwera i sieci. Wszystkie obliczenia są wykonywane na serwerze, co może prowadzić do znacznego ruchu sieciowego między klientem a serwerem. W nowoczesnych komputerach jest wystarczająca moc obliczeniowa, ale praktycznie nie jest wykorzystywana w modelu/cienkim kliencie banku

Natomiast model grubego klienta wykorzystuje moc obliczeniową maszyn lokalnych: sama aplikacja jest umieszczana na komputerze klienckim. Przykładem tego typu architektury są systemy bankomatów, w których bankomat jest klientem, a serwer centralnym komputerem obsługującym bazę kont klientów.

III.03.2. c Dwu- i trójwarstwowa architektura klient-serwer.

Wszystkie omówione powyżej architektury są dwupoziomowe. Rozróżniają poziom klienta i serwer. Ściśle mówiąc, IC składa się z trzech logicznych poziomów:

· Poziom użytkownika;

Poziom aplikacji:

· Warstwa danych.

Dlatego w modelu dwuwarstwowym, w którym zaangażowane są tylko dwie warstwy, występują problemy ze skalowalnością i wydajnością w przypadku wybrania modelu cienkiego klienta lub problemy z zarządzaniem systemem w przypadku wybrania grubego klienta. Problemów tych można uniknąć, jeśli zastosujemy model składający się z trzech poziomów, z których dwa to serwery (rys. III-21).

Serwer danych

W rzeczywistości serwer aplikacji i serwer danych mogą znajdować się na tej samej maszynie, ale nie mogą wzajemnie pełnić funkcji. Zaletą modelu trójwarstwowego jest to, że logicznie oddziela wykonywanie aplikacji od zarządzania danymi.

Tabela III-5 Zastosowanie różnych typów architektur

Architektura	Podanie
Dwuwarstwowy cienki klient	1 Starsze systemy, w których nie zaleca się oddzielania wykonywania aplikacji od zarządzania danymi. 2 Aplikacje intensywnie korzystające z mocy obliczeniowej przy niewielkim zarządzaniu danymi. 3 Aplikacje z dużą ilością danych, ale z niewielką ilością obliczeń.
Dwupoziomowy gruby klient	1 Aplikacje, w których użytkownik wymaga intensywnego przetwarzania danych, tj. wizualizacji danych. 2 Aplikacje ze stosunkowo stałym zestawem funkcji użytkownika stosowanych w dobrze zarządzanym środowisku systemowym.
Trzywarstwowy serwer-klient	1 Duże aplikacje z komórkami i tysiącami klientów 2 Aplikacje, w których zarówno dane, jak i metody przetwarzania często się zmieniają. 3 Aplikacje integrujące dane z wielu źródeł.

Model ten jest odpowiedni dla wielu typów aplikacji, ale ogranicza programistów IS, którzy muszą decydować, gdzie świadczyć usługi, zapewniać wsparcie dla skalowalności i opracowywać narzędzia do łączenia nowych klientów.

III.03.2. d Rozproszona architektura obiektów.

Bardziej ogólne podejście zapewnia rozproszona architektura obiektów, której głównymi składnikami są obiekty. Dostarczają zestaw usług za pośrednictwem swoich interfejsów. Inne obiekty wysyłają żądania bez rozróżniania między klientem a serwerem. Obiekty mogą znajdować się na różnych komputerach w sieci i współdziałać za pośrednictwem oprogramowania pośredniego, podobnie jak magistrala systemowa, co pozwala na łączenie różnych urządzeń i obsługę komunikacji między urządzeniami sprzętowymi.

…

Menedżer sterowników ODBC

Kierowca 1

Kierowca K

DB 1

DB K

Praca z SQL

…

Architektura ODBC obejmuje komponenty:

1. Aplikacja (np. IS). Wykonuje zadania: żąda połączenia ze źródłem danych, wysyła zapytania SQL do źródła danych, opisuje obszar przechowywania i format zapytań SQL, obsługuje błędy i powiadamia o nich użytkownika, zatwierdza lub wycofuje transakcje, żąda połączenia z źródło danych.

2. Menedżer urządzeń. Ładuje sterowniki na żądanie aplikacji, oferuje jeden interfejs dla wszystkich aplikacji, a interfejs administratora ODBC jest taki sam i niezależnie od tego, z którym DBMS aplikacja będzie współdziałać. Dostarczony przez firmę Microsoft Menedżer sterowników to biblioteka ładowana dynamicznie (DLL).

3. Sterownik zależy od DBMS. Sterownik ODBC to biblioteka dołączana dynamicznie (DLL), która implementuje funkcje ODBC i współdziała ze źródłem danych. Sterownik to program, który przetwarza żądanie funkcji specyficznej dla SZBD (może modyfikować żądania zgodnie z SZBD) i zwraca wynik do aplikacji. Każdy DBMS, który obsługuje technologię ODBC, musi dostarczać programistom aplikacji sterownik dla tego DBMS.

4. Źródło danych zawiera informacje sterujące określone przez użytkownika, informacje o źródle danych i służy do uzyskania dostępu do określonego DBMS. W tym przypadku wykorzystywane są środki systemu operacyjnego i platformy sieciowej.

Model dynamiczny

Model ten zakłada wiele aspektów, dla których w UML wykorzystuje się co najmniej 5 diagramów, zob. 2.04.2- 2.04.5.

Rozważ aspekt zarządzania. Model zarządzania uzupełnia modele strukturalne.

Bez względu na to, jak opisana jest struktura systemu, składa się on z zestawu jednostek strukturalnych (funkcji lub obiektów). Aby mogły funkcjonować jako całość, muszą być sterowane, a na diagramach statycznych nie ma informacji sterujących. Modele sterowania projektują przepływ sterowania między systemami.

Istnieją dwa główne typy kontroli w systemach oprogramowania.

1. Scentralizowane zarządzanie.

2. Zarządzanie oparte na zdarzeniach.

Zarządzanie scentralizowane może być:

· Hierarchiczny- na zasadzie „call-return” (tak najczęściej działają programy edukacyjne)

· Model dyspozytora który jest używany w systemach równoległych.

V modele dyspozytorskie zakłada się, że jednym z elementów systemu jest dyspozytor. Zarządza zarówno uruchamianiem i zamykaniem systemów, jak i koordynacją pozostałych procesów w systemie. Procesy mogą działać równolegle do siebie. Proces odnosi się do programu, podsystemu lub procedury, która jest aktualnie uruchomiona. Model ten może być również zastosowany w systemach sekwencyjnych, gdzie program sterujący wywołuje poszczególne podsystemy w zależności od niektórych zmiennych stanu (poprzez operator Obudowa).

Zarządzanie zdarzeniami zakłada brak podprogramu odpowiedzialnego za zarządzanie. Sterowanie odbywa się poprzez zdarzenia zewnętrzne: naciśnięcie przycisku myszy, naciśnięcie klawiatury, zmiana odczytów czujników, zmiana odczytów timera itp. Każde zdarzenie zewnętrzne jest kodowane i umieszczane w kolejce zdarzeń. Jeżeli podano reakcję na zdarzenie w kolejce, to wywoływana jest procedura (podprogram), która wykonuje reakcję na to zdarzenie. Zdarzenia, na które system reaguje, mogą wystąpić albo w innych podsystemach, albo w zewnętrznym środowisku systemu.

Przykładem takiego zarządzania jest organizacja aplikacji w systemie Windows.

Wszystkie opisane wcześniej modele strukturalne można wdrożyć za pomocą zarządzania scentralizowanego lub zarządzania opartego na zdarzeniach.

Interfejs użytkownika

Opracowując model interfejsu, należy wziąć pod uwagę nie tylko zadania projektowanego oprogramowania, ale także cechy mózgu związane z percepcją informacji.

III.03.4. a Cechy psychofizyczne osoby związane z percepcją i przetwarzaniem informacji.

Część mózgu, którą można umownie nazwać procesorem percepcji, nieustannie, bez udziału świadomości, przetwarza napływające informacje, porównuje je z przeszłymi doświadczeniami i przechowuje je w pamięci.

Kiedy obraz wizualny przyciąga naszą uwagę, wówczas w pamięci krótkotrwałej pojawiają się interesujące nas informacje. Jeśli nasza uwaga nie została przyciągnięta, informacje w magazynie znikają, zastępując je kolejnymi fragmentami.

W każdym momencie skupienie uwagi może być ustawione w jednym punkcie, więc jeśli zajdzie potrzeba jednoczesnego śledzenia kilku sytuacji, wówczas skupienie przenosi się z jednego śledzonego obiektu na drugi. Jednocześnie uwaga jest rozproszona, a niektóre szczegóły mogą zostać przeoczone. Istotne jest również to, że percepcja w dużej mierze opiera się na motywacji.

Po zmianie kadru mózg zostaje na chwilę zablokowany: opanowuje nowy obraz, podkreślając najważniejsze szczegóły. Oznacza to, że jeśli potrzebujesz szybkiej odpowiedzi od użytkownika, nie powinieneś gwałtownie zmieniać zdjęć.

Pamięć krótkotrwała jest wąskim gardłem w systemie przetwarzania informacji danej osoby. Jego pojemność to 7 ± 2 niepołączonych obiektów. Nieodebrane informacje są w nim przechowywane nie dłużej niż 30 sekund. Aby nie zapomnieć o żadnej ważnej dla nas informacji, zwykle powtarzamy ją sobie, aktualizując informacje w pamięci krótkotrwałej. Dlatego projektując interfejsy należy mieć na uwadze, że zdecydowana większość ma trudności np. z zapamiętaniem i wprowadzeniem na innym ekranie liczb zawierających więcej niż pięć cyfr.

Chociaż pojemność i czas przechowywania pamięci długotrwałej są nieograniczone, dostęp do informacji nie jest łatwy. Mechanizm wydobywania informacji z pamięci długotrwałej ma charakter asocjacyjny. Aby usprawnić zapamiętywanie informacji, jest on powiązany z danymi, które pamięć już przechowuje i ułatwia ich uzyskanie. Ponieważ dostęp do pamięci długotrwałej jest utrudniony, należy oczekiwać, że użytkownik nie będzie pamiętał informacji, ale że będzie je rozpoznawał.

III.03.4. b Podstawowe kryteria oceny interfejsów

Liczne ankiety i ankiety przeprowadzone przez wiodące firmy programistyczne wykazały, że użytkownicy cenią sobie interfejs:

1) łatwość opanowania i zapamiętywania – w szczególności oszacować czas opanowania oraz czas przechowywania informacji i pamięci;

2) szybkość uzyskiwania wyników podczas korzystania z systemu, która jest określona przez liczbę poleceń i ustawień wprowadzanych lub wybieranych myszą;

3) subiektywne zadowolenie z działania systemu (łatwość obsługi, zmęczenie itp.).

Co więcej, dla profesjonalnych użytkowników, którzy stale pracują z tym samym pakietem, drugie i trzecie kryterium szybko wysuwają się na pierwsze miejsce, a dla nieprofesjonalnych, którzy pracują z oprogramowaniem okresowo i wykonują stosunkowo proste zadania - pierwsze i trzecie.

Z tego punktu widzenia dziś najlepszą cechą dla użytkowników profesjonalnych są interfejsy ze swobodną nawigacją, a dla użytkowników nieprofesjonalnych - interfejsy do bezpośredniej manipulacji. Od dawna zauważono, że podczas wykonywania operacji kopiowania plików większość profesjonalistów używa powłok takich jak Far, podczas gdy nieprofesjonaliści używają systemu Windows „przeciągnij i upuść”.

III.03.4. c Rodzaje interfejsów użytkownika

Wyróżnia się następujące typy interfejsów użytkownika:

Prymitywny

Darmowa nawigacja

Bezpośrednia manipulacja.

Interfejs jest prymitywny

Prymitywny nazywa się interfejsem, który organizuje interakcję z użytkownikiem i jest używany w trybie konsoli. Jedynym odstępstwem od sekwencyjnego procesu zapewnianego przez dane jest przechodzenie przez wiele zestawów danych.

Interfejs menu.

W przeciwieństwie do prostego interfejsu pozwala użytkownikowi wybrać operację ze specjalnej listy wyświetlanej przez program. Interfejsy te zakładają realizację wielu scenariuszy pracy, których kolejność działań określana jest przez użytkowników. Drzewiasta organizacja menu sugeruje, że znalezienie pozycji w więcej niż dwupoziomowych menu jest trudne.

(Materiał strony http://se.math.spbu.ru)

Wstęp.

Obecnie rozproszone są praktycznie wszystkie duże systemy oprogramowania. System rozproszony- system, w którym przetwarzanie informacji jest skoncentrowane nie na jednym komputerze, ale rozproszone na kilka komputerów. W projektowaniu systemów rozproszonych, które ma wiele wspólnego z projektowaniem oprogramowania w ogóle, wciąż trzeba wziąć pod uwagę pewne szczegóły.

Istnieje sześć głównych cech systemów rozproszonych.

1. Udostępnianie zasobów. Systemy rozproszone umożliwiają współdzielenie zasobów sprzętowych (dyski twarde, drukarki) i programowych (pliki, kompilatory).
2. Otwartość.Jest to możliwość rozbudowy systemu o nowe zasoby.
3. Równoległość.W systemach rozproszonych wiele procesów może działać jednocześnie na różnych komputerach w sieci. Te procesy mogą wchodzić w interakcje podczas działania.
4. Skalowalność . Pod skalowalność rozumie się możliwość dodawania nowych właściwości i metod.
5. Tolerancja błędów. Obecność wielu komputerów pozwala na powielanie informacji i odporność na niektóre błędy sprzętowe i programowe. Systemy rozproszone mogą obsługiwać częściową funkcjonalność w przypadku błędu. Całkowita awaria systemu występuje tylko w przypadku błędów sieciowych.
6. Przezroczystość.Użytkownicy mają zapewniony pełny dostęp do zasobów w systemie, a jednocześnie ukryta jest przed nimi informacja o rozmieszczeniu zasobów w całym systemie.

Systemy rozproszone mają również szereg wad.

1. Złożoność... O wiele trudniej jest ogólnie zrozumieć i ocenić właściwości systemów rozproszonych, a także trudniej je zaprojektować, przetestować i utrzymać. Wydajność systemu zależy również od szybkości sieci, a nie od poszczególnych procesorów. Realokacja zasobów może znacząco zmienić szybkość działania systemu.
2. Bezpieczeństwo... Zazwyczaj do systemu można uzyskać dostęp z kilku różnych maszyn, wiadomości w sieci mogą być monitorowane i przechwytywane. Dlatego w systemie rozproszonym utrzymanie bezpieczeństwa jest znacznie trudniejsze.
3. Sterowalność... System może składać się z różnych typów komputerów, na których można zainstalować różne wersje systemów operacyjnych. Błędy na jednej maszynie mogą rozprzestrzeniać się na inne maszyny w nieprzewidywalny sposób.
4. Nieprzewidywalność ... Reakcja systemów rozproszonych na niektóre zdarzenia jest nieprzewidywalna i zależy od pełnego obciążenia systemu, jego organizacji oraz obciążenia sieci. Ponieważ parametry te mogą się ciągle zmieniać, czas odpowiedzi na żądanie może się znacznie różnić od czasu.

Z tych niedociągnięć widać, że przy projektowaniu systemów rozproszonych pojawia się szereg problemów, które muszą być brane pod uwagę przez programistów.

1. Identyfikacja zasobów ... Zasoby w systemach rozproszonych znajdują się na różnych komputerach, dlatego system nazewnictwa zasobów powinien być tak pomyślany, aby użytkownicy mogli łatwo uzyskać dostęp do potrzebnych im zasobów i odwoływać się do nich. Przykładem jest system URL (Uniform Resource Locator), który definiuje nazwy stron internetowych.
2. Komunikacja... Uniwersalna operacyjność Internetu i sprawna implementacja protokołów TCP/IP w Internecie dla większości systemów rozproszonych to przykłady najefektywniejszego sposobu organizacji komunikacji między komputerami. Jednak w niektórych przypadkach, gdy wymagana jest specjalna wydajność lub niezawodność, możliwe jest użycie specjalistycznych narzędzi.
3. Jakość obsługi systemu ... Ten parametr odzwierciedla wydajność, kondycję i niezawodność. Na jakość usług wpływa szereg czynników: dystrybucja procesów, zasobów, sprzętu oraz adaptacyjność systemu.
4. Architektura oprogramowania ... Architektura oprogramowania opisuje dystrybucję funkcji systemu pomiędzy komponenty systemu, jak również dystrybucję tych komponentów pomiędzy procesorami. Jeśli potrzebujesz utrzymać wysoką jakość usług systemowych, wybór odpowiedniej architektury ma kluczowe znaczenie.

Wyzwaniem dla projektantów systemów rozproszonych jest zaprojektowanie oprogramowania i sprzętu, aby zapewnić wszystkie wymagane cechy systemu rozproszonego. Wymaga to znajomości zalet i wad różnych architektur systemów rozproszonych. Istnieją trzy rodzaje architektur systemów rozproszonych.

1. Architektura klient/serwer ... W tym modelu system można traktować jako zbiór usług świadczonych przez serwery klientom. W takich systemach serwery i klienci znacznie się od siebie różnią.
2. Architektura trójwarstwowa ... W tym modelu serwer nie świadczy usług klientom bezpośrednio, ale za pośrednictwem serwera logiki biznesowej.

O dwóch pierwszych modelach powiedziano więcej niż raz, przyjrzyjmy się bardziej szczegółowo trzeciemu.

1. Rozproszona architektura obiektów ... W tym przypadku nie ma różnic między serwerami i klientami, a system można traktować jako zbiór wzajemnie oddziałujących obiektów, których lokalizacja tak naprawdę nie ma znaczenia. Nie ma rozróżnienia między usługodawcą a jego użytkownikami.

Ta architektura jest dziś szeroko stosowana i jest również nazywana architektura usług internetowych. Serwis internetowy to aplikacja dostępna przez Internet i udostępniająca niektóre usługi, której forma jest niezależna od dostawcy (ponieważ stosowany jest uniwersalny format danych – XML) i platformy działania. Obecnie istnieją trzy różne technologie, które wspierają koncepcję systemów obiektów rozproszonych. Są to technologie EJB, CORBA i DCOM.

Najpierw kilka słów o tym, czym jest XML w ogóle. XML to ogólny format danych używany do świadczenia usług sieci Web. Usługi sieciowe oparte są na otwartych standardach i protokołach: SOAP, UDDI i WSDL.

1. MYDŁO ( Protokół Simple Object Access Protocol, opracowany przez W3C, definiuje format żądań do usług internetowych. Wiadomości pomiędzy usługą sieciową a jej użytkownikiem są pakowane w tak zwane koperty SOAP (czasami nazywane również kopertami XML). Sama wiadomość może zawierać albo żądanie wykonania jakiejś akcji, albo odpowiedź - wynik tej akcji.
2. WSDL (język opisu usług sieci Web).Interfejs usługi sieci Web jest opisany w dokumentach WSDL (a WSDL jest podzbiorem XML). Przed wdrożeniem usługi programista tworzy jej opis w języku WSDL, określa adres usługi sieci Web, obsługiwane protokoły, listę dozwolonych operacji oraz formaty żądań i odpowiedzi.
3. UDDI (uniwersalny opis, wykrywanie i integracja) — Internetowy protokół wyszukiwania usług WWW ( http://www.uddi.org/). Jest to rejestr biznesowy, w którym dostawcy usług internetowych rejestrują usługi, a programiści znajdują usługi, które muszą uwzględnić w swoich aplikacjach.

Z rozmowy może się wydawać, że serwisy WWW są najlepszym i niekwestionowanym rozwiązaniem, a jedyne pytanie to wybór narzędzi programistycznych. Jednak tak nie jest. Istnieje alternatywa dla usług internetowych, Semantic Web, o której twórca WWW Tim Berners-Lee mówił pięć lat temu.

Jeśli celem usług internetowych jest ułatwienie komunikacji między aplikacjami, to Sieć Semantyczna jest przeznaczona do rozwiązania znacznie bardziej złożonego problemu - wykorzystania mechanizmów metadanych do zwiększenia efektywności wartości informacji, które można znaleźć w sieci. Można to zrobić, rezygnując z podejścia zorientowanego na dokument na rzecz zorientowanego obiektowo.

Bibliografia

1. SomervilleI. Inżynieria oprogramowania.
2. Dranitsa A. Java kontra .NET. - „Computerra”, nr 516.
3. Zasoby internetowe.