w oparciu o rekonfigurowalny multi-pipeline środowisko komputerowe L-Sieć

Jednym z pilnych zadań w dziedzinie systemów sterowania jest rozwój oprogramowania dla rozproszonych systemów sterowania odpornych na uszkodzenia. Istniejące dziś w tym obszarze rozwiązania są autorskie, w efekcie drogie i nie zawsze skuteczne.

Rozwiązania te nie zapewniają efektywnego wykorzystania zasobów nadmiarowych baz, technicznych i programowych, co negatywnie wpływa zarówno na odporność na awarie, jak i skalowalność takich rozwiązań. W przypadku naruszenia architektury sieci nie ma możliwości dynamicznej rekonfiguracji zarówno procesów przetwarzania informacji, jak i transmisji strumienia danych (zarówno sterowania jak i informacji). Zastosowanie określonych mikrokontrolerów, zastosowanie DCS/SCADA komplikuje rozwój i obsługę systemów, rozbudowę ich funkcjonalności.

Architektura rozproszonego systemu sterowania

Uogólniona typowa architektura rozproszonego systemu sterowania (DCS) obejmuje trzy hierarchicznie powiązane poziomy: poziom operatora, poziom sterowania i poziom wejścia-wyjścia (patrz rys. 1).

Głównym zadaniem poziomu operatora jest zapewnienie interfejsu człowiek-maszyna (HMI) umożliwiającego konfigurację i sterowanie całym systemem. Poziom sterowania odpowiada za odbieranie i przetwarzanie danych z czujników, przesyłanie danych do poziomu operatora oraz generowanie działań sterujących dla elementów wykonawczych. Poziom wejścia-wyjścia reprezentuje czujniki i aktuatory bezpośrednio połączone z obiektem sterowania.

Zadaniem oprogramowania w ramach uogólnionej architektury DCS jest zapewnienie funkcjonowania poziomu operatorskiego i jego powiązanie z poziomem sterowania systemu. Dlatego podstawowym poziomem w projektowaniu oprogramowania i rozwiązywaniu problemów jego interakcji ze sprzętem jest poziom operatora. Oprogramowanie powinno jak najefektywniej wykorzystywać dostępne zasoby sprzętowe systemu, będąc jednocześnie jak najbardziej niezależnym od wewnętrznej architektury sprzętowej.

Sprzęt zapewnia zasoby obliczeniowe, pamięć i media komunikacyjne między węzłami w systemie. Projektując ogólną architekturę systemu, nie są brane pod uwagę konkretne węzły poziomu I/O, które zostaną z nim połączone podczas jego konkretnej implementacji, dlatego w architekturze uogólnionej brane są pod uwagę poziom operatora i poziom sterowania. Sprzęt musi być rozpowszechniony, spełniać współczesne standardy, posiadać wszystkie właściwości i możliwości niezbędne do wdrożenia architektury.

Wymagania dla DCS

Wymagania DCS odnoszą się nie tylko do systemu jako całości, ale również do jego komponentów sprzętowych i programowych oddzielnie, ponieważ specyficzne podejścia do spełnienia tych wymagań dla tych komponentów mogą się zasadniczo różnić. DCS musi być przede wszystkim odporny na błędy. Najprostszą metodą zwiększenia odporności na uszkodzenia jest nadmiarowość (duplikacja) jednostek funkcjonalnych lub ich kombinacji. Drugą ważną właściwością jest skalowalność. Skalowalność polega na implementacji specjalnych algorytmów w oprogramowaniu oraz sprzętowej zdolności do wymiany i dodawania nowych węzłów lub ich komponentów. Jednocześnie system powinien pozostać prosty w obsłudze, rozbudowie nowych węzłów lub modułów oraz modyfikacji architektury.

Przegląd architektur DCS

Do przeglądu architektur DCS, Siemens SIMATIC PCS 7 DCS został wybrany jako jeden z najpopularniejszych na rynku, a RTS S3 jako DCS zaimplementowany w oparciu o QNX RTOS.

Siemens SIMATIC PCS 7

Architektura systemu posiada wszystkie właściwości uogólnionej architektury DCS. Komputery oparte na architekturze procesorów x86 z systemem operacyjnym Windows oraz pakietem Siemens WinCC dostarczającym HMI pełnią rolę stacji operatorskich. Istnieją serwery z bazami danych. Stacje operatorskie, inżynierskie i serwery są połączone siecią lokalną opartą na sieci Ethernet. Poziom operatora jest połączony z poziomem zarządzania redundantnej sieci Industrial Ethernet. Na poziomie sterowania znajdują się programowalne sterowniki logiczne (PLC) z możliwością redundancji ze względu na powielanie funkcjonalności. Możliwe jest łączenie się z zewnętrznymi systemami i sieciami oraz organizowanie zdalnego dostępu do systemu.

RTS S3

Ta architektura podobnie składa się z poziomów uogólnionej struktury DCS. Stacje operatorskie oparte są na tej samej platformie sprzętowej co SIMATIC DCS, ale mogą działać zarówno w systemach operacyjnych Windows, jak i Linux. Stanowiska inżynierskie połączone są z salami operatorskimi. System zapewnia ujednolicone środowisko tworzenia aplikacji. Sieć Ethernetłączy węzły w warstwie operatora i samą warstwę operatora z warstwą sterowania za pomocą stosu protokołów TCP/IP. Na poziomie sterowania znajdują się komputery przemysłowe z systemem operacyjnym QNX OS z własną bazą danych i możliwością redundancji poprzez zdublowanie funkcjonalności węzła.

Wady opisanych systemów

W opisanych powyżej systemach dla poziomu operatora i poziomu sterowania wykorzystywana jest inna platforma sprzętowa i programowa. W warstwie operatorskiej można zastosować tylko jedną architekturę procesora, a do skonfigurowania i rozwijania warstwy sterowania wymagana jest dedykowana stacja inżynierska. Te usługi DCS oferują tylko nadmiarowość sprzętową z powieleniem funkcjonalności węzła nadmiarowego jako sposób na zwiększenie odporności na uszkodzenia, co jest nieracjonalnym wykorzystaniem nadmiarowego sprzętu.

Charakterystyka i cechy funkcjonalne systemu L-Net

Przy opracowywaniu systemu L-Net zadaniem było stworzenie systemu sterowania, który miałby następujące cechy:

• Dynamiczna rekonfiguracja z pełne wyzdrowienie wydajność przy minimalnych stratach w przypadku awarii hosta lub zakłócenia topologii sieci.
• Sprawne rozłożenie zadań pomiędzy dostępne wydajne węzły sieci.
• Duplikacja kanałów komunikacyjnych pomiędzy węzłami z dynamiczną rekonfiguracją przepływów transmisji danych.
• Łatwość obsługi i skalowania systemu.
• Przenośność i funkcjonalność systemu na dowolnej platformie sprzętowej przeznaczonej do budowy systemów sterowania i systemów wbudowanych.

Do zbudowania systemu o powyższych cechach wymagany jest system operacyjny, który jest przeznaczony przede wszystkim do tworzenia systemów sterowania i systemów wbudowanych. Analiza istniejących systemów operacyjnych wykazała, że ​​najbardziej odpowiednim systemem operacyjnym jest QNX 6 (Neutrino), który ma bardzo wydajną alokację zasobów i możliwości sieciowe. Szeroki możliwości sieciowe udostępniane przez protokół sieciowy Qnet. Rozwiązuje problem niezawodności i dynamicznego równoważenia obciążenia kanałów komunikacyjnych, ale nie rozwiązuje problemu odporności na uszkodzenia systemu jako całości. W rezultacie powstał innowacyjny system sterowania oparty na rozproszonym, rekonfigurowalnym, wielopotokowym środowisku obliczeniowym. Opracowany system ma architekturę peer-to-peer, która obejmuje trzy bloki logiczne: blok wejścia-wyjścia, blok przełącznika ogólnego przeznaczenia oraz blok rekonfigurowalnego środowiska obliczeniowego (RCS) (patrz rys. 2).

Główne zalety tej architektury to:

• Typ równorzędny
• Decentralizacja
• Skalowalność
• Rozkład przestrzenny

Cechy funkcjonalne tej architektury:

• Potokowanie danych
• Redundancja sprzętowa
• Rozkład obciążenia
• Rekonfiguracja w locie

Na pierwszym poziomie architektury znajduje się blok wejścia-wyjścia (I/O), w skład którego wchodzą: węzły wejścia-wyjścia, przełącznik węzła wejścia-wyjścia, interfejs wejścia-wyjścia, czujniki i aktuatory. Blok odpowiada za podstawowe mechanizmy generowania działań sterujących na podstawie danych z lokalnych czujników oraz danych otrzymanych z innych poziomów systemu sterowania. Przydzielone zadania są rozdzielane między sprawne węzły we/wy na podstawie ich bieżącej względnej wydajności lub ręcznie przez operatora. Czujniki i siłowniki są połączone magistralą ze wszystkimi węzłami we/wy w bloku, co pozwala każdemu węzłowi na odpytywanie dowolnego czujnika lub generowanie wpływu na dowolny siłownik. Przełącznik węzłów we/wy zapewnia komunikację między wszystkimi węzłami we/wy w celu wymiany danych między nimi a innymi poziomami architektury systemu w celu uzyskania danych sterujących i informacyjnych. Przy odpowiednich możliwościach sprzętowych węzły komunikują się bezpośrednio ze sobą oraz z węzłami i przełącznikami na innych poziomach systemu, co skraca czas odpowiedzi w sieci. Bezpośrednie połączenie między węzłami i pewnym obciążeniem węzłów w bieżącym trybie pracy bloku I/O pozwala na zorganizowanie w bloku obliczeń potokowych niezbędnych do działania tego bloku bez uciekania się do zewnętrznej mocy obliczeniowej sterowania system (RCS), który pozwala na efektywne wykorzystanie wolnych zasobów przewidzianych dla redundantnych węzłów bloku I/O w momencie awarii.

Blok przełączników ogólnego przeznaczenia, znajdujący się na drugim poziomie architektury, organizuje linie komunikacyjne pomiędzy blokami I/O a RCS i systemami zewnętrznymi. Każdy przełącznik może łączyć różne węzły i przełączniki w całym systemie sterowania. Liczba linii komunikacyjnych jest określona przez możliwości sprzętowe węzłów i przełączników zawartych w blokach. Ponieważ sieć Qnet umożliwia dynamiczną dystrybucję przepływów transmisji danych, skalowanie tego bloku odbywa się poprzez proste podłączenie nowych urządzeń i nie wymaga konfiguracji, a w przypadku awarii jednego z przełączników transmisja danych między węzłami nie zostanie przerwana, jeśli inny przełącznik zapewni podobne połączenie między węzłami lub połączone bezpośrednio. Jednocześnie należy zadbać o wystarczającą przepustowość sieci wymaganą do utworzenia kopii zapasowej uszkodzonego przełącznika.

Możliwość rekonfiguracji bloku śieć komputerowa(RSS), zlokalizowany na trzecim poziomie architektury, zapewnia wysokowydajny system sterowania do rozwiązywania złożonych problemów przetwarzania informacji, podejmowania decyzji, rozpoznawania itp. Blok odpowiada za inicjalizację całego systemu sterowania: sprawdzenie działania przełączników i węzłów, integralność sieci, budowanie grafów sieciowych całego systemu, ustawienie parametrów startowych dla działania bloków I/O. Węzły tego bloku zapewniają archiwizację zarówno własnych danych, jak i danych z bloków we/wy. Każdy węzeł tego bloku może pełnić rolę maszyny operatorskiej przeznaczonej do monitorowania pracy systemu i dokonywania korekt programów pracy zarówno tego węzła, jak i wszystkich węzłów systemu, a także wykonywania rekonfiguracji na żądanie.

Rozkład obciążenia

Jednym z głównych zadań systemu L-Net jest rozkład obciążenia obliczeniowego na węzłach sieci. Rozwiązanie tego problemu opiera się na budowie rurociągów obliczeniowych. Aby zbudować potok obliczeniowy, budowany jest wstępnie graf zadań - schemat wymiany przepływów danych od źródła do odbiorcy. Czujniki działają jako źródło, a siłowniki jako odbiornik. Sam potok obliczeniowy jest odwzorowaniem grafu zadania (patrz rys. 3) na graf sieci komputerowej (patrz rys. 4), z uwzględnieniem wymagań zadania do zasobów obliczeniowych systemu i jego aktualnego stanu.

Rozwiązaniem jest skorzystanie z usługi, która dostarcza odbiorcy kompleksową informację o aktualnym sprzęcie, jego stanie i dostępnych źródłach danych, wykonuje pracę z wykresami sieci i zadaniami. W rezultacie wydajność wzrasta ze względu na potokowanie obliczeń i racjonalne wykorzystanie wszystkich dostępne dla systemu zasoby obliczeniowe.

tolerancja błędów

Główny problem funkcjonowania podobny system to całkowite zakłócenie wydajności potoków obliczeniowych w przypadku awarii dowolnego węzła tego potoku lub w przypadku zakłócenia przesyłania danych między nimi. Podstawowym sposobem protokołu Qnet jest przywrócenie łączy między węzłami w przypadku ich częściowego przerwania ze względu na linie zapasowe zapewniane przez architekturę. System L-Net rozwiązuje problem przywrócenia sprawności w przypadku całkowitej awarii hosta system komputerowy poprzez dynamiczną rekonfigurację potoku obliczeniowego, tj. wykorzystanie zasobów roboczych do zastąpienia uszkodzonego bloku. System przewiduje trzy scenariusze odtwarzania (rekonfiguracji) różniące się czasem reakcji na awarię, czasem odtwarzania oraz wykorzystanymi zasobami sprzętowymi: po awarii, z gotowością pasywną, z gotowością aktywną.

• Ponowna konfiguracja w przypadku niepowodzenia– po wykryciu awarii wyszukiwany jest dostępny sprzęt i umieszczany na wykresie zadania.
• Rekonfiguracja z pasywną gotowością- rezerwacja Sprzęt komputerowy jest z góry określony, uruchamiany jest proces zapewniający implementację wierzchołka grafu zadań na węźle, nawiązywane są połączenia, ale proces nie przetwarza danych, chyba że główny węzeł ulegnie awarii.
• Aktywna rekonfiguracja gotowości– górna część grafu zadań jest zaimplementowana na kilku węzłach, które równolegle przetwarzają dane i przekazują wynik.

Dzięki temu system zapewnia elastyczną gotowość na awarie zarówno na poziomie oprogramowania, jak i sprzętu, możliwość zmiany konfiguracji węzłów bez zatrzymywania działania i utraty wydajności, niezależnie od implementacji sieci, potoku obliczeniowego i węzła.

Wniosek

Opracowany system L-Net, w przeciwieństwie do dotychczasowych analogów, zakłada wykorzystanie szerokiej gamy charakterystyk sprzętowych węzłów DCS przy ich pełnej kompatybilności programowej. Uruchamiając węzły pod kontrolą jednego systemu operacyjnego (QNX Neutrino), można je budować na różnych architekturach procesorów (x86, ARM, MIPS itp.) z różnymi zestawami interfejsów i urządzeń peryferyjnych. Wdrażanie węzłów jest możliwe w postaci komputerów stacjonarnych, komputerów przemysłowych, komputerów ubieralnych i komputerów jednopłytkowych. Wszystkie komponenty kompleksu oprogramowania opracowanego systemu DCS można uruchomić na dowolnym jego węźle z systemem operacyjnym QNX, przy czym nadal możliwe jest korzystanie z węzłów z innym systemem operacyjnym. Takie podejście umożliwia wykorzystanie każdego węzła do rozwiązywania problemów zarówno na poziomie operatora, jak i na poziomie sterowania. Dlatego istnieje elastyczny system interakcje między węzłami peer-to-peer bez sztywnej hierarchii poziomów nieodłącznie związanej z uogólnioną architekturą DCS i systemami wykorzystującymi tę architekturę jako podstawową. Sieć peer-to-peer upraszcza proces wdrażania, obsługi, skalowania i debugowania systemu.

Aby zrealizować potencjał obliczeniowy redundantnego sprzętu w opracowanym systemie, zaproponowano algorytmy dynamicznej konfiguracji i rekonfiguracji oparte na protokole sieciowym Qnet i oprogramowaniu sieciowym L-Net. Algorytm konfiguracji dynamicznej opiera się na rozłożeniu obciążenia obliczeniowego na wszystkie węzły poprzez potokowanie i zrównoleglanie zadań oraz dynamiczne równoważenie obciążenia kanałów transmisji danych pomiędzy węzłami. Algorytm rekonfiguracji systemu zakłada występowanie trzech scenariuszy przywrócenia sprawności w przypadku awarii, w zależności od dostępnego sprzętu, priorytetów i zadań przypisanych do systemu: w momencie awarii, z gotowością pasywną (alokacja zasobów) oraz z gotowością aktywną (wykorzystanie zasobów) . Algorytmy dynamicznej konfiguracji i rekonfiguracji pozwalają na zwiększenie wydajności i niezawodności ze względu na dostępne w systemie rezerwy sprzętowe.

Niewątpliwą zaletą systemu jest maksymalna przejrzystość zarówno sprzętu, jak i technologie oprogramowania, co pozwala na znaczne uproszczenie obsługi technicznej systemu i opracowanie dla niego nowych modułów.

Wniosek

Opracowane rozwiązania architektoniczne umożliwiają poprawę takich wskaźników rozproszonych systemów sterowania jak niezawodność, wydajność, koszt, skalowalność i prostota dzięki możliwości wykorzystania szerokiej gamy sprzętowej, implementacji algorytmów dynamicznej konfiguracji oraz racjonalnego wykorzystania zasobów systemu.

1. http://kazanets.narod.ru/DCSIntro.htm .
2. http://kazanets.narod.ru/PCS7Overview.htm .
3. http://www.rts.ua/rus/news/678/0/409 .
4. Zyl S. QNX Momentics: Podstawy aplikacji. - Petersburg: BHV-Petersburg, 2005.
5. Krten R. Wprowadzenie do QNX Neutrino. Przewodnik po tworzeniu aplikacji czasu rzeczywistego. - Petersburg: BHV-Petersburg, 2011.

Słowa kluczowe: rozproszony system sterowania, Wsparcie informacyjne systemy sterowania, rozproszone systemy rekonfigurowalne.

Architektura rozproszonego systemu sterowania opartego na rekonfigurowalnym wielopotokowym środowisku obliczeniowym L-Net

Siergiej Yu. Potomskiy, adiunkt National Research University „Wyższa Szkoła Ekonomiczna”.

Nikita A. Poloyko, student V roku National Research University „Wyższa Szkoła Ekonomiczna”. asystent naukowy. programista. Kierunek szkolenia: „Sterowanie i informatyka w systemach technicznych”.

abstrakcyjny. Artykuł poświęcony jest rozproszonemu systemowi sterowania opartemu na rekonfigurowalnym wielopotokowym środowisku obliczeniowym. Podana jest architektura systemu. Podano również podstawowe cechy i właściwości funkcjonalne systemu. W artykule przedstawiono uzasadnienie wyboru system operacyjny. W artykule przedstawiono podstawowe zalety systemu w porównaniu z istniejącymi podobnymi rozwiązaniami.

słowa kluczowe: rozproszony system sterowania, wsparcie oprogramowania systemowego, rozproszony rekonfigurowalny.

W kontakcie z

Obecnie wszystkie IS tworzone do celów komercyjnych mają architekturę rozproszoną, co wiąże się z wykorzystaniem sieci globalnych i/lub lokalnych.

Historycznie, architektura serwera plików była pierwszą szeroko wykorzystywaną, ponieważ jej logika jest prosta i najłatwiej jest przenieść już działający IS na taką architekturę. Następnie została przekształcona w architekturę serwer-klient, co można interpretować jako jej logiczną kontynuację. Nowoczesne systemy używane w globalnym Sieci INTERNETOWE odnoszą się głównie do architektury obiektów rozproszonych (patrz rys. III‑15 )

IS można przedstawić jako składający się z następujących elementów (rys. III-16)

III.03.2. Aplikacje serwera plików.

Jest to historycznie pierwsza architektura rozproszona (rysunek III-17). Jest zorganizowany niezwykle prosto: tylko dane znajdują się na serwerze, 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ą ze sobą tylko za pomocą wspólnego przechowywania danych, więc programy napisane dla jednego komputera najłatwiej dostosować do takiej architektury.

Plusy:

Zalety architektury serwerowo-plikowej:

Ł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 niedociągnięcia tłumaczy się tym, że każde zapytanie do bazy danych prowadzi do przesyłania znacznych ilości informacji przez sieć. Na przykład, aby wybrać jeden lub więcej wierszy z tabel, cała tabela jest pobierana na komputer klienta, a DBMS dokonuje tam wyboru. Znaczny ruch w sieci jest szczególnie obciążony organizacją zdalny dostęp do DB.

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ą podzielone 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 „przenosi się” na komputer osobisty, a aplikacja oprogramowania pełni rolę 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 cienkich klientów - duże obciążenie serwera i sieci. Wszystkie obliczenia są wykonywane na serwerze, co może skutkować znacznym ruchem sieciowym między klientem a serwerem. W nowoczesnych komputerach jest wystarczająca moc obliczeniowa, ale praktycznie nie jest wykorzystywana w modelu bankowym/cienkim kliencie

Wręcz przeciwnie, model grubego klienta wykorzystuje moc obliczeniową lokalnych maszyn: sama aplikacja jest umieszczana na komputer kliencki. Przykładem tego typu architektury mogą być systemy ATM, w których bankomat jest klientem, a serwer - komputer centralny, który prowadzi bazę danych do rozliczeń z klientami

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

Wszystkie omówione powyżej architektury są dwupoziomowe. Różnią się poziomem klienta i poziomem serwera. Ściśle mówiąc, IS 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, pojawia się problem ze skalowalnością i wydajnością w przypadku wyboru modelu cienkiego klienta lub problemy związane z zarządzaniem systemem w przypadku modelu grubego klienta. Problemów tych można uniknąć, stosując model składający się z trzech poziomów, z których dwa to serwery (rys. III-21).

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

Model ten jest odpowiedni dla wielu typów aplikacji, ale ogranicza deweloperó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 Architektura obiektów rozproszonych.

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 i nie ma rozróżnienia między klientem a serwerem. Obiekty mogą znajdować się na różne komputery w sieci i wchodzić w interakcje za pośrednictwem oprogramowania pośredniczącego, podobnego do magistrali systemowej, co pozwala na połączenie różne urządzenia i obsługują komunikację między urządzeniami sprzętowymi.

Architektura ODBC obejmuje następujące komponenty:

1. Aplikacja (na przykład 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żny od tego, z którym DBMS aplikacja będzie współdziałać. Driver Manager dostarczany przez firmę Microsoft to dynamicznie ładowana biblioteka DLL.

3. Sterownik zależy od DBMS. Sterownik ODBC jest dynamiczny DLL Implementuje funkcje ODBC i współdziała ze źródłem danych. Sterownik to program, który przetwarza żądanie jakiejś funkcji specyficznej dla SZBD (może modyfikować zapytania 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 jest używane w celu uzyskania dostępu do określonego DBMS. W tym przypadku używane są narzędzia systemu operacyjnego i platformy sieciowej.

Model dynamiczny

Model ten zakłada wiele aspektów, do reprezentacji których w języku UML wykorzystuje się co najmniej 5 diagramów, patrz paragrafy. 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ć zarządzane, a informacje o zarządzaniu nie są dostępne na diagramach statycznych. Modele sterowania projektują przepływ sterowania między systemami.

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

1. Scentralizowane zarządzanie.

2. Sterowanie oparte na zdarzeniach.

Zarządzanie scentralizowane może być:

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

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

W 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 systemowych. Procesy mogą działać równolegle do siebie. Proces to program, podsystem lub procedura, która jest aktualnie uruchomiona. Model ten może być również stosowany w systemach sekwencyjnych, gdzie program sterujący wywołuje poszczególne podsystemy w zależności od niektórych zmiennych stanu (poprzez operator walizka).

Zarządzanie zdarzeniami zakłada brak jakiegokolwiek podprogramu odpowiedzialnego za zarządzanie. Sterowanie odbywa się za pomocą zdarzeń zewnętrznych: kliknięcia myszką, kliknięcia klawiatury, zmiany odczytu czujnika, zmiany odczytu timera itp. Każde zdarzenie zewnętrzne jest kodowane i umieszczane w kolejce zdarzeń. Jeżeli podana jest reakcja na zdarzenie w kolejce, to wywoływana jest procedura (podprocedura), 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 takiej kontroli jest organizacja aplikacji w systemie operacyjnym Windows.

Wszystkie opisane wcześniej modele strukturalne można wdrożyć za pomocą sterowania scentralizowanego lub sterowania 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 warunkowo 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 interesujące nas informacje trafiają do pamięci krótkotrwałej. Jeśli nasza uwaga nie została przyciągnięta, informacje w repozytorium znikają, zastępując je kolejnymi fragmentami.

W każdym momencie skupienie uwagi może być ustawione w jednym punkcie, więc jeśli konieczne jest jednoczesne śledzenie kilku sytuacji, skupienie przenosi się z jednego śledzonego obiektu na drugi. Jednocześnie uwaga jest rozproszona, a niektóre szczegóły mogą zostać pominięte. Nie bez znaczenia 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 reakcji użytkownika, nie powinieneś drastycznie zmieniać zdjęć.

Pamięć krótkotrwała to wąskie gardło w ludzkim systemie przetwarzania informacji. Jego pojemność to 7±2 niepowiązanych ze sobą obiektów. Nieodebrane informacje są w nim przechowywane nie dłużej niż 30 sekund. Aby nie zapomnieć o jakiejś 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 zdecydowanej większości trudno jest np. zapamiętać i wprowadzić na innym ekranie liczby zawierające 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 skojarzeniowy. 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, wskazane jest, aby nie polegać na tym, że użytkownik zapamięta informacje, ale na fakcie, że użytkownik je rozpozna.

III.03.4. b Podstawowe kryteria oceny interfejsów

Liczne ankiety i ankiety przeprowadzone przez wiodące firmy programistyczne wykazały, co użytkownicy cenią w interfejsie:

1) łatwość opracowywania i zapamiętywania – w szczególności ocenić czas rozwoju 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 podczas pracy systemu (łatwość obsługi, zmęczenie itp.).

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

Z tego punktu widzenia dzisiaj Najlepsza wydajność dla użytkowników profesjonalnych mają interfejsy ze swobodną nawigacją, a dla użytkowników nieprofesjonalnych - interfejsy 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, a nieprofesjonaliści używają metody „przeciągnij i upuść” systemu Windows.

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

Istnieją następujące typy interfejsy użytkownika:

Prymitywny

Z bezpłatną nawigacją

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, jaki zapewniają dane, jest organizacja cyklu przetwarzania kilku zestawów danych.

Menu interfejsu.

W przeciwieństwie do prymitywnego interfejsu pozwala użytkownikowi wybrać operację ze specjalnej listy wyświetlanej mu przez program. Interfejsy te wiążą się z realizacją wielu scenariuszy pracy, których kolejność działań określają użytkownicy. Drzewiasta organizacja menu sprawia, że ​​wyszukiwanie pozycji na więcej niż dwóch poziomach menu jest nie lada wyzwaniem.

Rozproszony AIS stał się teraz powszechną rzeczywistoś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” oraz architekturę warstwy pośredniej.

Architektury mobilne zaczynają być wprowadzane w życie. 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 (Peer-to-Peer), w którym, w przeciwieństwie do dominującej obecnie w systemach rozproszonych architektury „klient-serwer”, role stron wchodzących w interakcje sieć nie jest ustalona. 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 rozwijają się mobilne AIS. Opracowano środki techniczne i oprogramowanie aby je stworzyć. Dzięki temu zaczęły się rozwijać mobilne systemy bazodanowe. Wiele zespołów naukowych 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.

Utworzono standard protokołu dostęp bezprzewodowy aplikacje w sieci (Wireless Application Protocol - WAP), który jest już obsługiwany przez niektóre modele telefony komórkowe. W oparciu o WAP i XML, W3C opracowało język znaczników WML (Wireless Markup Language) do komunikacji bezprzewodowej.

W rozwoju AIS zwrócono większą uwagę na metadane. Podejmowane są tutaj kroki w dwóch kierunkach - ujednolicenie prezentacji metadanych i zapewnienie ich obsługi w systemie.

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

Aby przezwyciężyć te trudności, opracowanie standardów metadanych skoncentrowało się na różnych Technologia informacyjna. 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. Ograniczamy się tutaj do wymienienia tylko najważniejszych z nich.

Prawdopodobnie pierwszym de facto standardem w tej kategorii był język opisu danych CODASYL dla baz danych. struktura sieci. Z późniejszych standardów należy wymienić: standard języka zapytań SQL dla relacyjnych baz danych, zawierający definicję tzw. schematu informacyjnego – zbioru reprezentacji schematów relacyjnych baz danych; komponent standardu bazy danych obiektów ODMG opisujący 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.

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

Nowa platforma technologiczna XML for Web obejmuje również standardy reprezentacji metadanych. Obsługa metadanych to jedna z najważniejszych innowacji w sieci, radykalnie zmieniająca sposób jej zarządzania. zasoby informacji. Chociaż technologia baz danych była pierwotnie wymagana do obsługi metadanych, pierwsza generacja sieci Web nie obsługiwała metadanych.

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 RDF (Resource Definition Framework) definiuje prosty język reprezentacji wiedzy do opisu zawartości dokumentów XML. Wreszcie, nadchodzący standard OWL (Ontology Web Language) definiuje formalny język opisu ontologii dla Sieci Semantycznej.

Konsorcjum OMG opracowało standard języka UML (Unified Modeling Language), który zapewnia reprezentację metadanych narzędzi CASE do analizy i projektowania obiektów wizualnych. Ten język jest obsługiwany w wielu produkty oprogramowania walizka. Konsorcjum OMG stworzyło również standard XMI (XML Metadata Interchange) do wymiany metadanych między narzędziami CASE opartymi na UML.

W tym miejscu należy również wspomnieć o standardzie Dublin Core (DC), czyli zbiorze elementów metadanych służących do opisu treści dokumentów o różnym charakterze. Norma ta szybko zyskała popularność i znalazła w szczególności szerokie zastosowanie w: Środowisko internetowe(patrz rozdział 3.3).

Trwają prace nad rozwojem istniejących i tworzeniem nowych standardów prezentacji metadanych dla AIS. Więcej Detale o rozważanych standardach można znaleźć w encyklopedii.

Obecnie dystrybuowane są prawie wszystkie duże systemy oprogramowania. System rozproszony to taki system, w którym przetwarzanie informacji nie jest skoncentrowane na jednym komputerze, ale jest rozproszone na kilka komputerów. Projektując systemy rozproszone, które mają wiele wspólnego z projektowaniem jakiegokolwiek innego oprogramowania, należy wziąć pod uwagę szereg specyficznych cech. Niektóre z nich zostały już wspomniane we wstępie do Rozdziału 10 przy omawianiu architektury klient/serwer i są one omówione bardziej szczegółowo tutaj.

Ponieważ systemy rozproszone są obecnie tak rozpowszechnione, twórcy oprogramowania muszą znać ich funkcje projektowe. Do niedawna wszystkie duże systemy były w większości scentralizowane, czyli działały na jednym komputerze głównym (mainframe) z podłączonymi do niego terminalami. Terminale praktycznie nie przetwarzały informacji - wszystkie obliczenia zostały wykonane na głównej maszynie. Twórcy takich systemów nie musieli myśleć o problemach przetwarzania rozproszonego.

Wszystkie nowoczesne systemy oprogramowania można podzielić na trzy duże klasy.

1. Systemy oprogramowania aplikacyjnego zaprojektowane do działania tylko na jednym komputerze osobistym lub stacji roboczej. Obejmują one edytory tekstu, arkusze kalkulacyjne, systemy graficzne itp.

2. Systemy wbudowane zaprojektowane do pracy na pojedynczym procesorze lub na zintegrowanej grupie procesorów. Należą do nich systemy sterowania sprzętem AGD, różnymi urządzeniami itp.

3. Systemy rozproszone, w których oprogramowanie działa na luźno zintegrowanej grupie procesorów równoległych połączonych siecią. Należą do nich systemy bankomatowe należące do banku, systemy wydawnicze, systemy oprogramowania do użytku zbiorowego itp.

Obecnie istnieją wyraźne granice między wymienionymi klasami systemów oprogramowania, które w przyszłości będą coraz bardziej zacierane. Z biegiem czasu, gdy szybkie sieci bezprzewodowe staną się powszechnie dostępne, możliwe będzie dynamiczne integrowanie urządzeń z wbudowanymi systemami oprogramowania, takimi jak elektroniczne organizery, z bardziej ogólnymi systemami.

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

1. Udostępnianie zasobów. Systemy rozproszone umożliwiają współdzielenie zasobów sprzętowych i programowych, takich jak: dyski twarde, drukarki, pliki, kompilatory itp. połączone przez sieć. Oczywiście współdzielenie zasobów jest również możliwe w systemach wieloużytkownikowych, ale w tym przypadku za zapewnienie zasobów i zarządzanie nimi powinien odpowiadać komputer centralny.

2. Otwartość. Jest to możliwość rozbudowy systemu o nowe zasoby. Systemy rozproszone są systemy otwarte, do którego podłączony jest sprzęt i oprogramowanie różnych producentów.

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ą (ale nie muszą) wchodzić ze sobą w interakcje podczas działania.

4. Skalowalność. W zasadzie wszystkie systemy rozproszone są skalowalne: aby system spełniał nowe wymagania, można go skalować, dodając nowe zasoby obliczeniowe. Jednak w praktyce wzrost może ograniczać się do sieci łączącej poszczególne komputery w systemie. Jeśli podłączysz wiele nowych maszyn, wydajność sieć może być niewystarczająca.

5. Tolerancja błędów. Obecność wielu komputerów i możliwość powielania informacji sprawia, że ​​rozproszone systemy są odporne na pewne błędy sprzętowe i programowe. Większość systemów rozproszonych zazwyczaj zachowuje przynajmniej częściową funkcjonalność w przypadku wystąpienia błędu. Całkowita awaria systemu następuje tylko w przypadku błędów sieci.

6. Przezroczystość. Właściwość ta oznacza, że ​​użytkownicy mają całkowicie przejrzysty dostęp do zasobów, a jednocześnie są przed nimi ukryte informacje o rozmieszczeniu zasobów w systemie. Jednak w wielu przypadkach konkretna wiedza na temat organizacji systemu pomaga użytkownikowi lepiej wykorzystać zasoby.

Oczywiście systemy rozproszone mają szereg wad.

Złożoność. Systemy rozproszone są bardziej złożone niż systemy scentralizowane. O wiele trudniej jest ogólnie zrozumieć i ocenić właściwości systemów rozproszonych, a także przetestować te systemy. Na przykład tutaj wydajność systemu nie zależy od szybkości jednego procesora, ale od przepustowości sieci i szybkości różnych procesorów. Przenoszenie zasobów z jednej części systemu do drugiej może drastycznie wpłynąć na wydajność systemu.

Bezpieczeństwo. Zwykle do systemu można uzyskać dostęp z kilku różnych maszyn, wiadomości w sieci można przeglądać lub przechwytywać. W związku z tym utrzymanie bezpieczeństwa w systemie rozproszonym jest znacznie trudniejsze.

Sterowalność. System może składać się z różnych typów komputerów, na których: różne wersje system operacyjny. Błędy na jednej maszynie mogą rozprzestrzeniać się na inne maszyny z nieprzewidywalnymi konsekwencjami. W związku z tym zarządzanie systemem i utrzymanie go w stanie sprawności wymaga znacznie więcej wysiłku.

Nieprzewidywalność. Jak wszyscy użytkownicy sieci wiedzą, reakcja systemów rozproszonych na określone zdarzenia jest nieprzewidywalna i zależy od pełnego obciążenia systemu, jego organizacji oraz obciążenia sieci. Ponieważ wszystkie te parametry mogą się stale zmieniać, czas potrzebny na ukończenie żądania użytkownika może się znacznie różnić w tym czy innym czasie.

Omawiając zalety i wady systemów rozproszonych, identyfikuje się szereg krytycznych problemów projektowych takich systemów (tabela 9.1).

Tabela 9.1. Problemy projektowania systemów rozproszonych

Zadaniem twórców systemów rozproszonych jest zaprojektowanie oprogramowania lub sprzętu, aby zapewnić wszystkie niezbędne cechy systemu rozproszonego. A do tego trzeba znać zalety i wady różne architektury systemy rozproszone. Istnieją dwa powiązane typy 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 obiektów rozproszonych. 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 nie ma tak naprawdę znaczenia. Nie ma różnicy między usługodawcą a jego użytkownikami.

W systemie rozproszonym różne komponenty systemu mogą być zaimplementowane w różnych językach programowania i działać na różnych typach procesorów. Modele danych, reprezentacja informacji i protokoły interakcji - wszystko to niekoniecznie będzie tego samego typu w systemie rozproszonym. Dlatego systemy rozproszone wymagają oprogramowania, które może zarządzać tymi heterogenicznymi częściami i gwarantować interakcję i wymianę danych między nimi. Oprogramowanie pośredniczące należy do tej klasy oprogramowania. Znajduje się niejako pośrodku pomiędzy różnymi częściami rozproszonych komponentów systemu.

Systemy rozproszone są zwykle opracowywane przy użyciu podejścia obiektowego. Systemy te są tworzone z luźno zintegrowanych części, z których każda może bezpośrednio wchodzić w interakcje zarówno z użytkownikiem, jak i innymi częściami systemu. Te części powinny reagować na niezależne zdarzenia, gdy tylko jest to możliwe. Obiekty oprogramowania zbudowane na takich zasadach są naturalnymi składnikami systemów rozproszonych. Jeśli nie znasz jeszcze pojęcia przedmiotów.

W poprzednim rozdziale rozważaliśmy silnie sprzężone systemy wieloprocesorowe z pamięcią współdzieloną, wspólne struktury dane jądra i wspólną pulę, z której procesy są wywoływane do wykonania. Często jednak jest to pożądane, aby zapewnić: dzielenie się zasoby do dystrybucji procesorów w taki sposób, aby były niezależne od środowiska operacyjnego i warunków pracy. 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 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, o ile użytkownik wie, że pracuje w sieci. Ponadto należy zauważyć, że programy takie jak edytory tekstu, z usuniętymi plikami, tak jak w przypadku zwykłych, nie działają. Użytkownicy powinni mieć standardowy zestaw funkcji systemu UNIX i, z wyjątkiem możliwej utraty wydajności, nie powinni mieć ochoty na przekraczanie granic maszyn. Czyli na przykład praca funkcji systemowych otwiera się i odczytuje z włączonymi plikami zdalne maszyny nie powinny różnić się od ich pracy z plikami należącymi do systemów lokalnych.

Architektura systemu rozproszonego została 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. Zgodność modelu nie zostaje naruszona, nawet jeśli 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 uruchomionych na innych maszynach. Ta cecha odróżnia systemy rozproszone 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 o architekturze rozproszonej

Systemy rozproszone, dobrze opisane w literaturze, tradycyjnie dzieli 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 przekierowują do niego wszystkie wywołania systemu operacyjnego. Celem systemu peryferyjnego jest zwiększenie Całkowita wydajność sieci oraz w zapewnieniu możliwości przydzielenia procesora do pojedynczego procesu w środowisku operacyjnym UNIX. System zaczyna się jako osobny moduł; w przeciwieństwie do innych modeli systemów rozproszonych, systemy brzegowe nie mają rzeczywistej autonomii, z wyjątkiem przypadków związanych z planowaniem 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). Pliki zdalne mają specyfikację (nazwę złożoną), która zawiera znaki specjalne lub dodatkowy składnik nazwy w specyfikacji ścieżki wyszukiwania, która poprzedza katalog główny systemu plików. Implementacja tej metody nie wiąże się z wprowadzaniem zmian w jądrze systemu, dlatego jest prostsza niż pozostałe metody omówione w tym rozdziale, ale mniej elastyczna.

Całkowicie „przejrzyste” systemy rozproszone, w których, aby uzyskać dostęp do plików znajdujących się na innych maszynach, wystarczy wskazać ich standardowe nazwy złożone; za rozpoznanie tych plików jako usuniętych odpowiada jądro. Ś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 podczas montowania systemów plików 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 adresowanie, routing, kontrola przepływu oraz wykrywanie i korekcja błędów są obsługiwane przez moduły protokołów i sterowniki urządzeń, innymi słowy, że każdy model jest niezależny od używanej sieci. Przykłady użycia funkcji systemowych podane w następnej sekcji dla systemów peryferyjnych działają podobnie dla systemów takich jak Newcastle i dla systemów całkowicie „przezroczystych”, które zostaną omówione później; dlatego omówimy je 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.

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

Gdy system jest inicjowany na centralnym procesorze, jądro ł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, którego właścicielem jest procesor(cm. ); Gdy proces działający na procesorze peryferyjnym wywołuje funkcję systemową, która potrzebuje tylko usług procesora, proces peryferyjny kontaktuje się ze swoim towarzyszem, a żądanie jest wysyłane do procesora w celu przetworzenia. Proces satelitarny wykonuje funkcję systemową i wysyła wyniki z powrotem do procesora peryferyjnego. Relacja procesu peryferyjnego z jego towarzyszem jest podobna do relacji klient-serwer, którą szczegółowo omówiliśmy w rozdziale 11.: proces peryferyjny działa jak klient dla swojego towarzysza, który obsługuje funkcje systemu plików. W takim przypadku proces serwera zdalnego ma tylko jednego klienta. W sekcji 13.4 przyjrzymy się procesom serwera, które mają wielu klientów.

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 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 satelickiego (Rysunek 13.3). Komunikat zawiera znak wskazujący, że funkcja systemu jest wykonywana przez proces satelitarny w imieniu klienta, parametry przekazywane do funkcji oraz dane dotyczące środowiska wykonywania procesu (na przykład 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 (takie jak ścieżka do pliku lub dane, które mają zostać zapisane przez funkcję write).

Proces satelitarny czeka na żądania z procesu peryferyjnego; po otrzymaniu żądania dekoduje komunikat, określa typ funkcji systemu, 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 czasu otrzymania odpowiedzi, po jej otrzymaniu odszyfrowuje i przekazuje wyniki użytkownikowi. Jest to ogólny schemat przetwarzania 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ż jest związana z prostymi formularzami żądań i odpowiedzi wymienianymi między urządzeniem peryferyjnym a procesorem. Jądro na procesorze peryferyjnym generuje komunikat, który wskazuje, że żądaną funkcją jest funkcja getppid, i wysyła żądanie do centralnego procesora. Proces satelitarny na procesorze odczytuje wiadomość z urządzenia peryferyjnego, dekoduje typ funkcji systemowej, wykonuje ją i otrzymuje identyfikator swojego rodzica. Następnie konstruuje odpowiedź i wysyła ją do oczekującego procesu peryferyjnego na drugim końcu łącza. Gdy procesor peryferyjny otrzyma odpowiedź, przekazuje ją do procesu, który wywołał wywołanie systemowe getppid. Jeśli proces peryferyjny przechowuje dane (takie jak identyfikator procesu rodzica) w pamięci lokalnej, nie będzie w ogóle musiał komunikować się ze swoim towarzyszem.

Jeśli wywołanie systemu otwartego zostanie wykonane, proces peryferyjny wysyła odpowiednią wiadomość do swojego towarzysza, która zawiera nazwę pliku i inne parametry. Jeśli się powiedzie, proces satelicki alokuje i-węzeł i punkt wejścia do tablicy plików, alokuje w swojej przestrzeni wpis tablicy deskryptorów plików użytkownika 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; uchwyt zwrócony przez funkcję open jest wskaźnikiem do wpisu w tablicy deskryptorów pliku użytkownika towarzyszącego. Wyniki wykonania funkcji przedstawiono na rysunku 13.4.

Rysunek 13.4. Wywołanie funkcji otwartej z procesu peryferyjnego

W przypadku wywołania systemowej funkcji zapisu, procesor peryferyjny generuje komunikat składający się z atrybutu funkcji zapisu, deskryptora pliku i ilości zapisywanych danych. Następnie z przestrzeni procesu peryferyjnego kopiuje dane do procesu satelitarnego wzdłuż linii komunikacyjnej. 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 wpisu o którym w tabeli plików); wszystkie te działania są wykonywane na procesorze centralnym. Pod koniec swojej pracy proces satelitarny wysyła do procesu peryferyjnego komunikat potwierdzający odebranie komunikatu i zawierający liczbę bajtów danych pomyślnie zapisanych do pliku. operacja odczytu wykonywane podobnie; satelita informuje proces peryferyjny o liczbie faktycznie odczytanych bajtów (w przypadku odczytu danych z terminala lub z kanału liczba ta nie zawsze jest zgodna z liczbą określoną w żądaniu). Do realizacji obu funkcji może być konieczne wielokrotne wysyłanie wiadomości informacyjnych przez sieć, co jest określane przez ilość przesyłanych danych i rozmiar pakietów sieciowych.

Jedyną funkcją, którą należy zmienić podczas pracy na procesorze, jest wywołanie systemowe fork. Kiedy proces wykonuje tę funkcję na procesorze, jądro wybiera dla niego procesor peryferyjny i wysyła wiadomość do specjalnego procesu, serwera, informując ten ostatni, że rozpoczyna się rozładowywanie bieżącego procesu. Zakładając, że serwer zaakceptował żądanie, rozwidlenie jądra tworzy nowy proces peryferyjny, przydzielając wpis w tablicy procesów i przestrzeń adresową. Procesor rozładowuje kopię procesu, który wywołał funkcję rozwidlenia, do procesora peryferyjnego, nadpisując nowo przydzieloną przestrzeń adresową, tworzy lokalnego satelitę do komunikacji z nowym procesem peryferyjnym i wysyła wiadomość do urządzenia peryferyjnego o potrzebie zainicjowania licznik programu dla nowego procesu. Proces satelity (na procesorze) jest dzieckiem procesu, który nazwał funkcję fork; proces peryferyjny jest technicznie dzieckiem procesu serwera, ale logicznie rzecz biorąc, jest dzieckiem procesu, który nazwał funkcję fork. Proces serwera nie ma logicznego połączenia z dzieckiem na końcu rozwidlenia; jedynym zadaniem serwera jest pomoc w wyładowaniu dziecka. Ze względu na silne sprzężenie między komponentami systemu (procesory peryferyjne nie mają autonomii), proces peryferyjny i proces satelitarny mają ten sam kod identyfikacyjny. Zależność między procesami pokazano na rysunku 13.5: linia ciągła pokazuje relację rodzic-dziecko, linia przerywana pokazuje relację między rówieśnikami.

Rysunek 13.5. Wykonywanie funkcji wideł na procesorze

Gdy proces wykonuje funkcję rozwidlenia na procesorze peryferyjnym, wysyła komunikat do swojego towarzysza 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óre transmisja żądanych danych rozpoczyna się na drugim końcu kanału komunikacji. Satelita odczytuje przesłany obraz i przepisuje go do dziecka peryferyjnego. Kiedy obraz zakończy się rozładowywać, proces satelity rozwidla się, tworząc swój element potomny na procesorze i przekazuje wartość licznika programu do elementu potomnego urządzenia peryferyjnego, aby dziecko urządzenia peryferyjnego wiedziało, gdzie rozpocząć wykonywanie. Oczywiście byłoby lepiej, gdyby potomek procesu satelitarnego był przypisany do dziecka peryferyjnego jako rodzica, ale w naszym przypadku procesy potomne mają możliwość uruchamiania na innych procesorach peryferyjnych, a nie tylko na tym, na którym są zostały stworzone. Zależność między procesami po zakończeniu funkcji fork pokazano na rysunku 13.6. Kiedy proces peryferyjny zakończy swoją pracę, wysyła odpowiednią wiadomość do procesu satelitarnego, który również się kończy. Proces satelitarny 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 reagować 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 działanie systemu, jeśli jest to zgodne z priorytetem, z jakim został zawieszony. Ponieważ proces towarzyszący wykonuje funkcje systemowe w imieniu procesu peryferyjnego, musi odpowiadać na sygnały w sposób zgodny z tym ostatnim. Jeśli sygnał powoduje, że proces przerywa wykonywanie funkcji w systemie jednoprocesorowym, proces towarzyszący w systemie wieloprocesorowym POWINIEN zrobić to samo. To samo można powiedzieć o przypadku, gdy sygnał powoduje zakończenie pracy procesu za pomocą funkcji wyjścia: proces peryferyjny kończy działanie i wysyła odpowiednią wiadomość do procesu satelity, który oczywiście również się kończy.

Gdy proces peryferyjny wywołuje wywołanie systemowe sygnału, przechowuje bieżące informacje w lokalnych tabelach i wysyła komunikat do swojego towarzysza, informując go, czy określony sygnał powinien zostać zaakceptowany, czy zignorowany. Proces satelitarny nie ma znaczenia, czy wykonać przechwytywanie sygnału, czy czynność domyślną. Reakcja procesu na sygnał zależy od trzech czynników (Rysunek 13.7): czy sygnał jest odbierany, gdy proces wykonuje funkcję systemową, czy sygnał ma ignorować sygnał oraz czy sygnał występuje na tym samym urządzeniu peryferyjnym procesor lub na innym. Przyjrzyjmy się różnym możliwościom.

algorytm sighandle /* algorytm przetwarzania sygnału */

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

jeśli (sygnał zignorowany)

if (sygnał odebrany podczas wykonywania funkcji systemu)

umieścić 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;

Satellite_end_of_syscall algorytm /* funkcja zakończenia systemu wywoływana przez proces peryferyjny */

informacje wejściowe: brak

informacje wyjściowe: brak

if (odebrano przerwanie podczas wykonywania funkcji systemowej)

wysłać wiadomość przerwania, sygnał, do procesu peryferyjnego;

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

wyślij odpowiedź: włącz flagę informującą o nadejściu sygnału;

Rysunek 13.7. Przetwarzanie sygnału w systemie peryferyjnym

Załóżmy, że proces peryferyjny jest zawieszony, podczas gdy proces satelitarny wykonuje funkcję systemową w jego imieniu. Jeśli sygnał pojawi się gdzie indziej, proces satelitarny wykryje go przed procesem peryferyjnym. Możliwe są trzy przypadki.

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

2. Jeśli proces poinstruował, aby zignorować sygnał tego typu, satelita kontynuuje działanie algorytmu wykonywania funkcji systemu bez wychodzenia ze stanu zawieszenia przez longjmp. Odpowiedź wysłana do procesu peryferyjnego nie będzie zawierać wiadomości o otrzymaniu sygnału.

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

Proces peryferyjny wyszukuje odebraną odpowiedź w poszukiwaniu informacji o odebraniu sygnałów i, jeśli takie istnieją, przetwarza sygnały przed wyjściem z funkcji systemu. Zatem zachowanie procesu w systemie wieloprocesorowym jest dokładnie takie samo, jak jego zachowanie w systemie jednoprocesorowym: albo kończy działanie bez wychodzenia z trybu jądra, albo wywołuje funkcję obsługi sygnału zdefiniowaną przez użytkownika, albo ignoruje sygnał i pomyślnie wychodzi z systemu funkcjonować.

Rysunek 13.8. Przerwij podczas wykonywania funkcji systemowej

Załóżmy na przykład, że proces peryferyjny wywołuje funkcję do odczytu z terminala powiązanego z procesorem i zawiesza swoją pracę, podczas gdy proces satelity wykonuje tę funkcję (rysunek 13.8). Jeśli użytkownik naciśnie klawisz przerwy, rdzeń procesora wyśle ​​odpowiedni sygnał do procesu satelitarnego. Jeśli satelita znajdował się w stanie zawieszenia, czekając na wprowadzenie danych z terminala, natychmiast wychodzi z tego stanu i przestaje wykonywać funkcję odczytu. W odpowiedzi na żądanie procesu peryferyjnego satelita zgłasza kod błędu i numer sygnału odpowiadający przerwaniu. Proces peryferyjny analizuje odpowiedź i, ponieważ komunikat wskazuje na sygnał przerwania, wysyła go do siebie. Przed wyjściem z funkcji read jądro peryferyjne sprawdza sygnały, wykrywa sygnał przerwania z procesu towarzyszącego i obsługuje go w normalny sposób. Jeżeli w wyniku odebrania sygnału przerwania proces peryferyjny zakończy swoją pracę funkcją exit, funkcja ta zajmie się zabiciem procesu satelity. Jeśli proces peryferyjny przechwyci sygnały przerwań, wywoła funkcja niestandardowa przetwarzanie sygnału i po wyjściu z funkcji read zwraca użytkownikowi kod błędu. 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żdego zawieszenia, ponieważ ma ograniczony czas oczekiwania na zasoby ). Satelita kończy funkcję i zwraca numer sygnału do procesu peryferyjnego. Proces peryferyjny wysyła do siebie sygnał i odbiera go przy wyjściu z funkcji systemu.

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

Odnosząc się do przykładu odczytu, proces peryferyjny nie ma pojęcia, czy jego towarzysz czeka na dane wejściowe z terminala, czy robi coś innego. 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 Inaczej wykonanie funkcji jest doprowadzone do pomyślnego zakończenia.

Rozważmy na koniec przypadek sygnału nadchodzącego w czasie niezwiązanym z wykonaniem funkcji systemowej. Jeśli sygnał pojawia się na innym procesorze, 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. Jądro peryferyjne odszyfrowuje wiadomość i wysyła sygnał do procesu, który odpowiada w normalny 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żeli niektóre z procesów, do których przeznaczony jest sygnał, znajdują się na innych procesorach peryferyjnych, ich satelity odbiorą sygnał (i zareagują na odbiór w sposób opisany powyżej).

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 występują na procesorze peryferyjnym do zdalnego (centralnego) procesora. Przejdźmy teraz do mniej sprzężonych systemów, które składają się z maszyn, które uzyskują dostęp do plików znajdujących się na innych maszynach. W sieci komputery osobiste i stacji roboczych, na przykład użytkownicy często uzyskują dostęp do plików znajdujących się na duży samochód. W następnych dwóch sekcjach przyjrzymy się konfiguracjom systemu, w których wszystkie funkcje systemowe są wykonywane w podsystemach lokalnych, ale możliwy jest dostęp do plików (poprzez funkcje podsystemu zarządzania plikami) znajdujących się na innych komputerach.

Systemy te wykorzystują jedną z dwóch następujących ścieżek do identyfikacji usuniętych plików. Niektóre systemy dodają znak specjalny do nazwy pliku złożonego: składnik nazwy poprzedzający ten znak identyfikuje maszynę, reszta nazwy to plik znajdujący się na tej maszynie. Na przykład nazwa złożona

„sftig!/fs1/mjb/rje”

identyfikuje plik "/fs1/mjb/rje" znajdujący się na maszynie "sftig". Ten schemat identyfikacji pliku jest zgodny z konwencją zainstalowany przez program uucp do przesyłania plików pomiędzy systemami typu UNIX. W innym schemacie, usunięte pliki identyfikowane są poprzez dodanie do nazwy specjalnego prefiksu, np.:

/../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 używa znanej składni nazw plików UNIX, więc w przeciwieństwie do pierwszego schematu tutaj programy użytkownika nie ma potrzeby uwzględniania użycia nazw o nietypowej konstrukcji (patrz ).

Rysunek 13.9. Formułowanie zapytań do serwera plików (procesora)

Resztę tej sekcji spędzimy przyglądając się modelowi systemu korzystającemu z łącza Newcastle, w którym jądro nie rozpoznaje zdalnych 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ę interfejs systemowy. Te podprogramy analizują pierwszy składnik nazwy pliku, który w obu opisanych metodach identyfikacji zawiera funkcję 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 zapytań do serwera plików. Jeśli plik jest lokalny, jądro system lokalny przetwarza żądanie w zwykły sposób. Rozważ przypadek odwrotny:

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

Otwarty podprogram z biblioteki C analizuje dwa pierwsze składniki ścieżki do pliku i dowiaduje się, że plik powinien być wyszukany na zdalnej maszynie „sftig”. W celu uzyskania informacji o tym, czy proces miał wcześniej połączenie z tą maszyną, podprogram tworzy specjalną strukturę, w której zapamiętuje ten fakt, a w przypadku negatywnej odpowiedzi nawiązuje połączenie z serwerem plików działającym na zdalna maszyna. Gdy proces formułuje swoje pierwsze żądanie zdalnego przetwarzania, zdalny serwer potwierdza żądanie, zapisuje pola identyfikatora użytkownika i identyfikatora grupy, jeśli to konieczne, i tworzy proces satelitarny działający 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 identyfikator klienta „mjb” może być taki sam, jak identyfikator innego klienta na zdalnej maszynie. Dlatego administratorzy systemów na komputerach w sieci powinni albo upewnić się, że każdemu użytkownikowi przypisano kod identyfikacyjny, który jest unikalny w całej sieci, albo przeprowadzić konwersję kodu w momencie zgłaszania żądania usługi sieciowej. Jeśli nie zostanie to zrobione, proces satelicki będzie miał inne prawa 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 pomylić kontroli bezpieczeństwa systemu zdalnego. Z drugiej strony, niektóre programy, jeśli nie mają praw administratora, po prostu nie mogą 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ż prawa administratora nie dotyczą usuwania. Problem tworzenia zdalnych katalogów jest poważnym powodem zrewidowania funkcji systemu mkdir w kierunku rozszerzenia jego możliwości w zakresie automatycznego nawiązywania wszystkich połączeń niezbędnych dla użytkownika. Jednak programy setuid (w tym program mkdir) uzyskujące prawa administratora do zdalnych plików nadal są powszechnym problemem, który należy rozwiązać. 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że zamieszanie w istniejących systemach.

Jeśli otwarty podprogram się powiedzie, lokalna biblioteka pozostawia ślad w dostępnej dla użytkownika strukturze zawierającej adres hosta sieciowego, identyfikator procesu satelitarnego, deskryptor pliku i inne podobne informacje. Podprogramy biblioteki odczytu i zapisu określają na podstawie deskryptora, czy plik jest zdalny, a jeśli tak, wysyła 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 tej samej zdalnej maszynie, używa jednego satelity, ale jeśli pliki znajdują się na różnych maszynach, 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. Podczas wywoływania funkcji systemowej przez satelitę 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 katalog zdalny jako katalog bieżący, procedura biblioteczna wysyła odpowiedni komunikat do satelity, który zmienia bieżący katalog, podczas gdy procedura pamięta, że ​​katalog jest zdalny. Za każdym razem, gdy nazwa ścieżki wyszukiwania zaczyna się od znaku innego niż ukośnik (/), podprogram wysyła nazwę do zdalnej maszyny, gdzie proces satelitarny śledzi ścieżkę, zaczynając od bieżącego katalogu. Jeśli bieżący katalog jest lokalny, podprogram po prostu przekazuje nazwę ścieżki wyszukiwania do lokalnego jądra systemu. Funkcja systemu chroot na zdalnym katalogu jest podobny, ale jego wykonanie na lokalnym jądrze systemu pozostaje niezauważone; ściśle mówiąc, proces może pozostawić tę operację bez nadzoru, ponieważ tylko biblioteka przechwytuje jej wykonanie.

Kiedy proces wywołuje funkcję rozwidlenia, odpowiednia procedura biblioteczna wysyła komunikaty do każdego satelity. Procesy satelitarne wykonują operację rozwidlenia i wysyłają identyfikatory swoich dzieci do klienta nadrzędnego. Proces klienta wywołuje wywołanie systemowe rozwidlenia, które przekazuje kontrolę do zrodzonego dziecka; lokalne dziecko komunikuje się ze zdalnym satelitą potomnym, którego adresy są przechowywane przez podprogram biblioteki. Taka interpretacja funkcji wideł ułatwia sterowanie procesami satelitarnymi Otwórz pliki i aktualne katalogi. Kiedy proces, który pracuje na zdalnych plikach kończy działanie (wywołując funkcję exit), procedura wysyła komunikaty do wszystkich swoich zdalnych towarzyszy, aby zrobili to samo po otrzymaniu komunikatu. W ćwiczeniach omawiane są poszczególne aspekty implementacji funkcji exec i exit systemu.

Zaletą połączenia Newcastle jest to, że dostęp procesu do zdalnych plików staje się „przezroczysty” (niewidoczny dla użytkownika) i nie trzeba wprowadzać żadnych zmian w jądrze systemu. Jednak rozwój ten ma również szereg wad. Przede wszystkim jego wdrożenie może obniżyć wydajność systemu. Dzięki użyciu rozszerzonej biblioteki C ilość pamięci używanej przez każdy proces wzrasta, nawet jeśli proces nie ma dostępu do zdalnych plików; biblioteka powiela funkcje jądra i wymaga dla siebie więcej miejsca w pamięci. Zwiększenie rozmiaru procesów prowadzi do dłuższego okresu uruchamiania i może powodować większą rywalizację o zasoby pamięci, tworząc warunki do częstszego rozładowywania i wymiany zadań. Żądania lokalne będą wykonywane wolniej ze względu na wydłużenie czasu trwania każdego dostępu do jądra, spowolnienie może również zagrozić przetwarzaniu żądań zdalnych, wzrasta koszt przesyłania ich przez sieć. Dodatkowe przetwarzanie żądań zdalnych na poziomie użytkownika zwiększa liczbę przełączeń kontekstu, procesów rozładowywania i zamiany. Wreszcie, aby uzyskać dostęp do zdalnych plików, programy muszą zostać ponownie skompilowane przy użyciu nowych bibliotek; bez tego stare programy i zainstalowane moduły obiektowe nie będą mogły pracować z plikami zdalnymi. Wszystkie te niedociągnięcia są nieobecne w systemie opisanym w następnym rozdziale.

Termin „przejrzysta alokacja” oznacza, że ​​użytkownicy na jednym komputerze mogą uzyskiwać dostęp do plików na innym komputerze, nie zdając sobie sprawy, że przekraczają granice komputera w taki sam sposób, jak na własnym komputerze, gdy przełączają się 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 odróżniających. W konfiguracji pokazanej na rysunku 13.10 katalog "/usr/src" na maszynie B jest "podłączony" do katalogu "/usr/src" na maszynie A. różne systemy przeznaczone do korzystania z tego samego źródło system, tradycyjnie umieszczony w katalogu "/usr/src". Użytkownicy pracujący na komputerze A mogą uzyskać dostęp do plików znajdujących się na komputerze B przy użyciu zwykłej składni nazw plików (na przykład: "/usr/src/cmd/login.c"), a jądro samo decyduje, czy plik jest zdalny, czy lokalny. Użytkownicy pracują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, takie jak jako montowanie wszystkich systemów zdalnych w katalogu głównym systemu lokalnego, dając użytkownikom dostęp do wszystkich plików we wszystkich systemach.

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

Podobieństwo między montowaniem lokalnych systemów plików a ujawnianiem zdalnych systemów plików doprowadziło 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 nawiązuje połączenie sieciowe ze zdalną maszyną i przechowuje informacje w tabeli montowania, które charakteryzują to połączenie.

Ciekawym problemem są nazwy ścieżek zawierające „..”. Jeśli proces ustawia katalog ze zdalnego systemu plików jako katalog bieżący, użycie znaków „..” w nazwie zwróci proces do lokalnego systemu plików, zamiast uzyskiwać dostęp do plików znajdujących się powyżej bieżącego katalogu. Wracając ponownie do rysunku 13.10, zauważamy, że gdy proces należący do maszyny A, po uprzednim wybraniu katalogu „/usr/src/cmd” znajdującego się w zdalnym systemie plików, jako katalogu bieżącego, wykonuje polecenie

bieżący katalog będzie katalogiem głównym maszyny A, a nie maszyny B. Algorytm namei działający w jądrze zdalnego systemu, mając ciąg znaków „..”, sprawdza, czy proces wywołujący jest agentem procesu klienta, a jeśli tak, określa, 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 formie każda procedura jądra zajmująca się i-węzłami sprawdza, czy i-węzeł wskazuje na zdalny plik, a jeśli tak, wysyła żądanie wykonania określonej operacji do zdalnej maszyny. Ten schemat naturalnie pasuje do abstrakcyjnej struktury obsługi systemów plików różne rodzaje opisane w końcowej części rozdziału 5. Odnosząc się zatem do: plik zdalny może zainicjować transmisję kilku komunikatów przez sieć, których liczba jest określona przez liczbę dorozumianych operacji na pliku, z odpowiednim wzrostem czasu odpowiedzi na żądanie, z uwzględnieniem limitu czasu akceptowanego 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 żądanie do maszyny, na której się on znajduje, aby uzyskać zablokowany i-węzeł. Po otrzymaniu żądanej odpowiedzi jądro lokalne tworzy w pamięci kopię indeksu odpowiadającego plikowi zdalnemu. Jądro następnie sprawdza niezbędne prawa dostęp do pliku (na przykład do odczytu) poprzez wysłanie kolejnej wiadomości do zdalnej maszyny. Wydajność otwarty algorytm kontynuuje w pełni zgodnie z planem podanym w rozdziale 5, wysyłając komunikaty do zdalnej maszyny w razie potrzeby, aż algorytm zostanie całkowicie zakończony i indeks zostanie zwolniony. 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, wysyła żądanie zdalnej blokady indeksu, żądanie odczytu danych, kopiuje dane do pamięci lokalnej, wysyła żądanie zwolnienia indeksu zdalnego i zwalnia indeks lokalny. Ten schemat odpowiada semantyce istniejącego jądra jednoprocesorowego, ale częstotliwość korzystania z sieci (kilka wywołań na funkcję systemu) zmniejsza wydajność całego systemu. Jednak w celu zmniejszenia przepływu wiadomości w sieci, kilka operacji można połączyć w jedno żądanie. W przykładzie z funkcją odczytu, klient może wysłać do serwera jedno ogólne żądanie „odczytu”, a serwer po jego wykonaniu decyduje, czy pobrać i zwolnić indeks. Zmniejszenie ruchu w sieci można również osiągnąć za pomocą buforów zdalnych (jak omówiono powyżej), ale należy zadbać o to, aby funkcje plików systemowych korzystające z tych buforów działały poprawnie.

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 jej wywołaniu do system zdalny, który wykonuje funkcję i zwraca wyniki do klienta. Maszyna klienta odbiera wyniki funkcji i wychodzi ze stanu wywołania. Większość funkcji systemowych można wykonać za pomocą tylko jednego żądania sieciowego z odpowiedzią po rozsądnym czasie, ale nie wszystkie funkcje pasują do takiego modelu. Na przykład po odebraniu pewnych sygnałów jądro tworzy plik dla procesu o nazwie „core” (rozdział 7). Utworzenie tego pliku nie jest związane z konkretną funkcją systemu, ale kończy kilka operacji, takich jak tworzenie pliku, sprawdzanie uprawnień i wykonywanie wielu operacji zapisu.

W przypadku funkcji systemu otwartego żądanie wykonania funkcji wysyłane do maszyny zdalnej zawiera część nazwy pliku, która pozostaje po pominięciu składnika nazwy ścieżki wyszukiwania, który odróżnia zdalny plik, a także różne flagi. We wcześniejszym przykładzie otwierania 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, potrzebne do weryfikacji uprawnień do plików na zdalnym komputerze. Jeśli ze zdalnej maszyny zostanie odebrana odpowiedź, że funkcja otwierania się powiodła, lokalne jądro wybiera wolny i-węzeł w pamięci lokalnej maszyny i oznacza go jako i-węzeł zdalnego pliku, zapisuje informacje o zdalnym komputerze i zdalnym i-węźle i przydziela go w rutynowy sposób. nowy rekord 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 ta używana podczas wywoływania procedury zdalnej (rysunek 13.11). Jeśli funkcja zwana procesem uzyskuje dostęp do zdalnego pliku za pomocą swojego uchwytu, lokalne jądro uczy się z (lokalnego) indeksu, że plik jest zdalny, formułuje zapytanie zawierające wywołaną funkcję i wysyła je do zdalnego komputera. Żądanie zawiera wskaźnik do zdalnego i-węzła, za pomocą którego proces satelicki może zidentyfikować sam zdalny plik.

Po otrzymaniu wyniku wykonania dowolnej funkcji systemowej jądro może skorzystać z usług specjalnego programu do jego przetworzenia (po czym jądro zakończy pracę z funkcją), ponieważ przetwarzanie lokalne wyników stosowane w systemie jednoprocesorowym jest nie zawsze nadaje się do 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, co zapewnia minimalny czas odpowiedzi systemu na przychodzące żądania.

Używanie procesów satelitarnych w „przezroczystym” systemie rozproszonym ułatwia śledzenie plików zdalnych, ale tabela procesów systemu zdalnego jest przeciążona 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 obsługi przychodzących żądań zdalnych. Po przetworzeniu żądania proces serwera powraca do puli i staje się gotowy do przetwarzania innych żądań. Serwer nie zapisuje kontekstu użytkownika między dwoma żądaniami, 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, a mianowicie: kody identyfikujące użytkownika, aktualny katalog, sygnały itp. Procesy satelitarne otrzymują te dane w momencie ich pojawienia się lub podczas wykonywania funkcji systemu.

Kiedy proces otwiera zdalny plik, jądro w zdalnym systemie przypisuje i-węzeł dla kolejnych odwołań do pliku. Maszyna lokalna ma tablicę deskryptorów plików użytkownika, tablicę plików i tablicę indeksu ze zwykłym zestawem wpisów, z wpisem w tablicy indeksu identyfikującym zdalny komputer i zdalny węzeł. W przypadkach, gdy funkcja systemowa (taka jak read) korzysta z deskryptora pliku, jądro wysyła komunikat wskazujący na wcześniej przypisany zdalny węzeł i przekazuje informacje związane z procesem: kod identyfikacyjny użytkownika, maksymalny rozmiar pliku itd. procesu serwerowego, który ma do dyspozycji, interakcja z klientem przybiera postać opisaną wcześniej, jednak połączenie między klientem a serwerem nawiązywane jest tylko na czas funkcjonowania systemu.

Jeśli używasz serwerów zamiast procesów satelitarnych, zarządzanie przepływem danych, sygnałów i urządzeń zdalnych może stać się trudniejsze. Wnioskodawcy do w dużych ilościachżądania do zdalnej maszyny w przypadku braku wystarczającej liczby serwerów powinny być umieszczane w kolejce. Wymaga to protokołu na wyższym poziomie niż ten używany w sieci głównej. Z drugiej strony w modelu satelickim przeciążenie żądań jest eliminowane, ponieważ wszystkie żądania klientów są przetwarzane synchronicznie. Klient może mieć maksymalnie jedno oczekujące żądanie.

Obsługa sygnałów, które przerywają wykonywanie funkcji systemu, jest również bardziej skomplikowana w przypadku korzystania z serwerów, ponieważ zdalna maszyna musi wtedy szukać odpowiedniego serwera obsługującego tę funkcję. Nie wyklucza się nawet, że ze względu na zajętość wszystkich serwerów żądanie wykonania funkcji systemu znajduje się w stanie przetwarzania w toku. Warunki zaistnienia rywalizacji dodawane są również wtedy, gdy serwer zwraca procesowi wywołującemu wynik wykonania funkcji systemowej, a odpowiedź serwera obejmuje przesłanie przez sieć odpowiedniego komunikatu sygnałowego. Każda wiadomość musi być oznaczona w taki sposób, aby zdalny system mógł ją rozpoznać iw razie potrzeby przerwać procesy serwera. W przypadku korzystania z satelitów proces, który służy do realizacji żądania klienta jest automatycznie identyfikowany, aw przypadku sygnału sprawdzenie, czy przetwarzanie żądania zostało zakończone, nie jest trudne.

Wreszcie, jeśli funkcja systemowa wywołana przez klienta powoduje zatrzymanie serwera na czas nieokreślony (na przykład podczas odczytu 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ść zauważalne wąskie gardło. Nie dotyczy to satelitów, ponieważ satelita jest przypisywany 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 płynących z używania procesów satelitarnych, potrzeba wolnych wpisów w tabeli procesów staje się w praktyce tak dotkliwa, że ​​w większości przypadków procesy serwera są nadal używane do obsługi zdalnych żądań.

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

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 obwodami pokazano na rysunku 13.12. Wszystkie te z kolei różnią się od systemów wieloprocesorowych opisanych w poprzednim rozdziale tym, że procesory 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. Łącze typu Newcastle zapewnia ukryty ("przezroczysty") dostęp do zdalnych plików, ale nie za pomocą 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 przez specjalną sekwencję znaków, która opisuje 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 jest używana 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 zdalnego wywołania procedury (wiadomość zawierająca listę operacji związanych z indeksem wysyłana jest do maszyny zdalnej) oraz w formie funkcji zdalnego systemu wywołanie (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.

*jeden. 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 takich jak SIGKILL; Wyjaśnij, co dzieje się w systemie peryferyjnym, gdy proces odbiera taki sygnał.

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

*cztery. Jak procesor powinien rozdzielić procesy między procesorami peryferyjnymi, aby zrównoważyć ogólne 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? W jaki sposób procesy powinny być rozładowywane i wymieniane 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 funkcję execl("/../sftig/bin/sh", "sh", 0); Plik wykonywalny znajduje się na zdalnym komputerze, ale musi być wykonywany w systemie lokalnym. Wyjaśnij, w jaki sposób moduł zdalny jest migrowany do systemu lokalnego.

7. Jeśli administrator musi dodać do istniejący system z linkiem Newcastle do nowych maszyn, jaki jest najlepszy sposób poinformowania o tym modułów biblioteki C?

*osiem. Podczas funkcji exec jądro nadpisuje przestrzeń adresową procesu, w tym tabele bibliotek używane przez łącze Newcastle do śledzenia odwołań 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 momentu.

*9. Jak pokazano w rozdziale 13.2, wywołanie funkcji wyjścia systemu w systemach z łączem Newcastle skutkuje wysłaniem wiadomości do procesu satelity, powodując zakończenie procesu satelity. Odbywa się to na poziomie procedur bibliotecznych. Co się dzieje, gdy proces lokalny otrzyma sygnał wzywający go do wyjścia z trybu jądra?

*dziesięć. W systemie z łączem Newcastle, gdzie zdalne pliki są identyfikowane przez dodanie specjalnego przedrostka do nazwy, jak użytkownik może, określając ".." (katalog nadrzędny) jako składnik nazwy pliku, przemierzać zdalny punkt montowania ?

11. Z rozdziału 7 wiemy, ż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 korzystał z łącza do Newcastle?

*12. Jakie byłyby konsekwencje dla procesów lokalnych, gdyby wszystkie procesy satelitarne lub serwerowe zostały usunięte z systemu?

*13. Zastanów się, jak „przejrzysty” system rozproszony powinien implementować algorytm łączenia, który może przyjmować dwie zdalne nazwy plików jako parametry, a także algorytm exec, który obejmuje kilka wewnętrznych odczytów. Rozważ dwie formy komunikacji: zdalne wywołanie procedury i zdalne wywołanie funkcji systemowej.

*czternaście. Podczas uzyskiwania dostępu do urządzenia proces serwera może przejść 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. Opracuj 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 systemowa nie przestanie działać, dopóki wszystkie serwery nie będą zajęte.

Rysunek 13.13. Konfiguracja serwera terminali

*piętnaście. Gdy użytkownik loguje się do systemu, dyscyplina linii terminala przechowuje informację, że terminal jest terminalem operatora prowadzącym grupę procesów. Z tego powodu, gdy użytkownik naciśnie klawisz „break” na klawiaturze terminala, wszystkie procesy w grupie otrzymują sygnał przerwy. 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ą obsługiwane przez zestaw procesów serwera, należy zauważyć, że po wykonaniu procedury otwierania serwer przestaje czekać na połączenie. Po zakończeniu funkcji open serwer wraca z powrotem do puli serwerów, przerywając połączenie z terminalem. W jaki sposób sygnał przerwania jest wysyłany po naciśnięciu klawisza „break” na adresy procesów należących do tej samej grupy?

*16. Współdzielenie pamięci to funkcja natywna dla komputerów lokalnych. 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 momentu.

*17. Algorytmy rozładowywania procesu i 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 przesyłania?

*osiemnaście. Załóżmy, że na zdalnej maszynie (lub w sieci) wystąpiła krytyczna awaria, a protokół warstwy sieci lokalnej zarejestrował ten fakt. Opracuj schemat przywracania systemu lokalnego uzyskującego dostęp do zdalnego serwera z żądaniami. Opracuj również plan naprawy system serwerowy stracił kontakt z klientami.

*19. Gdy proces uzyskuje dostęp do pliku zdalnego, możliwe jest, że proces będzie przechodził przez wiele komputerów w poszukiwaniu pliku. Jako przykład weźmy 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" to punkt montowania katalogu głównego maszyny C. Przejście przez kilka maszyn do miejsca docelowego nazywa się "wieloskokiem". 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 „multihop” w systemie z połączeniem Newcastle oraz w „przejrzystym” systemie rozproszonym.