1. WYDZIAŁ ELEKTROTECHNIKI, AUTOMATYKI,
INFORMATYKI I INŻYNIERII BIOMEDYCZNEJ
KATEDRA Informatyki Stosowanej
Praca dyplomowa magisterska
Rozproszony system operacyjny
Distributed operating system
Autor: Dariusz Jania
Kierunek studiów: Informatyka
Opiekun pracy: Dr inż. Grzegorz Rogus
Kraków, 2014

2. 2
Oświadczam, świadomy(-a) odpowiedzialności karnej za poświadczenie nieprawdy, że niniejszą
pracę dyplomową wykonałem(-am) osobiście i samodzielnie i że nie korzystałem(-am) ze źródeł innych
niż wymienione w pracy.
….................................

3. 3

4. SpisTre ciś
1 Wprowadzenie.................................................................................................................................................5
1.1 O systemie...................................................................................................................................................5
1.2 Podstawowe elementy systemu....................................................................................................................6
2. Zagadnienia teorytyczne................................................................................................................................7
2.1 Rozproszone systemy operacyjne ze specjalistycznym mikrojądrem............................................................7
2.2 Cloud computing.........................................................................................................................................8
2.4 Wirtualizacja aplikacji.................................................................................................................................9
3 Architektura systemu....................................................................................................................................11
3.1 System plikowy..........................................................................................................................................12
3.2 Węzeł wykonawczy....................................................................................................................................13
3.3 Węzeł nadzorczy........................................................................................................................................14
3.4 Terminal użytkownika...............................................................................................................................15
4 Implementacja elementów systemu...........................................................................................................18
4.1 Konsola użytkownika.................................................................................................................................19
4.2 Węzeł plikowy...........................................................................................................................................21
4.3 Węzeł wykonawczy...................................................................................................................................22
4.4 Węzeł nadzorczy........................................................................................................................................25
4.5 Binarny protokół komunikacji i logi programów.......................................................................................26
4.6 Wydajność wykonywania procesów użytkownika.....................................................................................27
5 Podsumowanie...............................................................................................................................................29
6 Literatura.........................................................................................................................................................30

5. 5
1Wprowadzenie
Praca ma charakter projektowy i polega na zaimplementowaniu rozproszonego systemu
operacyjnego, umożliwiającego uruchamianie i zarządzanie binarnymi programami. To, co odróżnia
ten system od innych, popularnych rozwiązać typu „cloud” jest fakt, iż potrafi on uruchamiać
skompilowane programy, które nigdy nie były napisane z możliwością wykonywania w środowisku
rozproszonym.
Praca składa się z następujących elementów:
1. Zarys wymagań stawianych przed systemem i jego najważniejszych elementów. Poświęcone są
temu rozdziały 1.1 do 1.2
2. Porównanie współczesnych rozwiązań, które nawiązują do tematyki „cloud computing”,
obliczeń rozproszonych oraz wirtualizacji zasobów i procesów. Poświęcony jest temu rozdział 2
3. Opis architektury oraz sposobu realizacji najważniejszych zadań systemu. Poświęcony jest
temu rozdział 3
4. Szczegółowy opis zrealizowanej implementacji w wybranym języku programowania.
Poświęcony jest temu rozdział 4
5. Wnioski z realizacji projektu oraz możliwości jego dalszego rozwoju. Poświęcony jest temu
rozdział 5
1.1 O systemie
Historycznie pierwsze rozproszone systemy operacyjne były realizowane przy pomocy
autorskiego jądra systemu. Przedstawicielem systemów tego typu jest system Amoeba czy Mach.
Systemy z własnym jądrem nie zyskały dużej popularności i zostały wyparte przez systemy „cloud”
oparte o wirtualizacje, bądź systemy udostępniające API, które umożliwiają rozproszone wykonywanie
i skalowanie programów nań uruchamianych.
Wirtualizacja umożliwiła wykorzystanie istniejących jąder systemów operacyjnych - np. GNU
Linux - do realizacji skalowalnych systemów rozproszonych. W przeciwieństwie jednak do systemu z
pojedynczym jądrem, wirtualizacja separuje przestrzeń wykonywanych programów do przestrzeni
pojedynczego systemu operacyjnego na pojedynczym węźle systemu.
Systemy udostępniające API dla programów są zdecydowanie bardziej homogeniczne z
perspektywy uruchamianych programów. Z drugiej strony wymagają specjalnego przystosowania ich
kodu i stosowania się do konwencji platformy, na której mają być uruchamiane. Niejednokrotnie
ograniczony jest także język programowania, w jakim program może być napisany.

6. 6
System operacyjny, zaimplementowany w ramach niniejszej pracy jest logicznie pomiędzy
rozwiązaniami opartymi o wirtualizacje (w tym także wirtualizacje na poziomie aplikacji) oraz
specjalizowanymi systemami umożliwiającymi rozproszone wykonywanie programów.
Rys 1 Logiczne warstwy rozproszonego systemu operacyjnego
Można wyróżnić trzy warstwy logiczne systemu:
1. System operacyjny – jest to klasyczny system operacyjny np. GNU Linux, który zarządza
sprzętowymi elementami komputera oraz lokalnymi procesami.
2. Warstwa zarządzająca – są to klasyczne, lokalne procesy w trybie „userland”. Realizują one
funkcje rozproszonego systemu operacyjnego poprzez zarządzanie procesami użytkownika.
3. Proces użytkownika – są to także klasyczne, lokalne procesy w trybie „userland”. Są one
śledzone i nadzorowane przez procesy rozproszonego systemu operacyjnego.
1.2 Podstawowe elementy systemu
W ramach systemu można wyróżnić cztery, podstawowe elementy systemu, których współpraca
umożliwia realizacje zadań stawianych przed systemem:
1. Węzły wykonawcze – są to podstawowe węzły systemu, uruchamiają one programy
użytkownika i nimi zarządzają.
2. Węzły zarządzające – w ramach tej pracy zaimplementowany został pojedynczy węzeł
zarządzający (rozproszony system z topologią gwiazdy). Służy on do autoryzacji
użytkowników oraz jest punktem centralnym, w którym rejestrują się pozostałe węzły systemu.
3. Węzły plikowe – w ramach tej pracy zaimplementowany został rozproszony, płaski system
plikowy (bez katalogów i podkatalogów).
4. Terminal użytkownika – jest to podstawowy interfejs użytkownika, dzięki któremu komunikuje
się on z systemem. Terminal łączy się bezpośrednio z pozostałymi węzłami systemu, dzięki
czemu cały system widziany jest z perspektywy użytkownika jako pojedynczy byt.
Proces użytkownika
Warstwa zarządzająca
System operacyjny
Proces użytkownika

7. 7
2.Zagadnieniateorytyczne
Tematyka rozproszonych systemów operacyjnych i rozproszonego modelu obliczeniowego jest
dojrzała i obecna w publikacjach naukowych od kilkudziesięciu lat [Tan07] [Tan95]. Możliwość
lepszego wykorzystania zasobów komputerowych od zawsze była atrakcyjną opcją, stąd nie dziwi
eksplozja ilości rozwiązań utylizujących współbieżne i rozproszone obliczenia. Sposób realizacji
rozproszonych obliczeń jest jednak skrajnie różny. Istniejące systemy wspierają rozproszenie na wielu,
skrajnie różnych płaszczyznach [apt11] :
1. Implementacja specjalistycznego mikrojądra rozproszonego systemu operacyjnego np. Amoeba.
2. Rozproszone aplikacje, działające w ramach tradycyjnych systemów operacyjnych. Często
oparte o języki programowania, które wspierają rozproszone obliczenia np. Erlang.
3. Specjalistyczne aplikacje działające w ramach platform software-owych np. Google App
Engine.
4. Zarządcy dla maszyn wirtualnych, działających w ramach tradycyjnych systemów
operacyjnych, bądź specjalistycznych systemów operacyjnych (np. vmware ESXi).
5. Zarządcy dla procesów, które działają w ramach tradycyjnych systemów operacyjnych,
przechwytując wybrane wywołania systemowe procesów [zsz10] np. Microsoft App-V. System
zaimplementowany w ramach tej pracy jest właśnie przykładem systemu tego typu.
2.1 Rozproszone systemy operacyjne ze specjalistycznym mikroj dremą
Rys 2 Węzły systemu w systemie operacyjnym z rozproszonym mikrojądrem
kernel
procesy
sprzęt
kernel
procesy
sprzęt
kernel
procesy
sprzęt

8. 8
Klasyczne, rozproszone systemy operacyjne używają rozproszonego mikrojądra na potrzeby
implementacji. Jądro to zajmuje się zarządzaniem zasobami sprzętowymi na wszystkich węzłach
systemu oraz zarządzaniem procesami.
Systemy oparte o rozproszone mikrojądro mają największe możliwości optymalizacji
wykorzystania zasobów sprzętowych węzłów oraz optymalizacji wykonywania procesów
użytkowników i wywołań systemowych. Systemy te mogą też transparentnie dla aplikacji realizować
współdzielenie zasobów czy komunikacje międzyprocesową [fpa10].
Znaczącą wadą tych systemów jest ich bardzo duży stopień skomplikowania. W historii
oprogramowania co najmniej jeden system operacyjny okazał się być zbyt skomplikowany do
zrealizowania – multics. System ten był przykładem systemu z pojedynczym węzłem, zaś rozproszone
systemy operacyjne muszą uwzględnić szereg innych problemów, które nie występują w systemach z
pojedynczym węzłem. Stąd nie dziwi fakt, iż żadna implementacja rozproszonego systemu
operacyjnego nie zyskała szerszej popularności i nie znalazła komercyjnego zastosowania.
Inną wadą tych systemów jest to, iż wymagają przystosowania aplikacji użytkownika do
uruchamiania na nich, bądź emulowania ABI klasycznych systemów operacyjnych.
2.2 Cloud computing
W komercyjnych produktach, obecnych na rynku, funkcjonalność specjalistycznych mikrojąder
rozproszonych systemów operacyjnych została rozbita na kilka komponentów i zaimplementowana w
ramach oddzielnych kategorii programów. Zwyczajowo w ramach modelu biznesowego i spełnianych
funkcji dzieli się je na dwie kategorie:
1. PaaS – „Platform as a Service”, oprogramowanie zarządzające zasobami sprzętowymi i ich
przydziałem.
2. SaaS – „Software as a Service”, oprogramowanie zarządzające wykonywaniem i skalowaniem
aplikacji.
Oprogramowanie typu PaaS najczęściej zajmuje się zarządzaniem maszynami wirtualnymi, które
działają w ramach klasycznych systemów operacyjnych. Oprogramowanie to najczęściej potrafi
migrować całe maszyny wirtualne na mniej obciążone węzły w systemie, lecz zwykle nie zarządza
samymi procesami użytkowników.

9. 9
Rys 3 Typowa hierachia oprogramowania typu PaaS
Oprogramowanie typu SaaS z kolei jest najczęściej usługą ze ściśle określonym API,
wspierające określone języki programowania np. Windows Azure, bądź narzucające określoną
konwencje programistyczną np. Hadoop MapReduce.
2.4 Wirtualizacja aplikacji
Technika wirtualizacji aplikacji polega na przechwytywaniu wybranych wywołań systemowych
procesów użytkowników w celu ich nadpisania i zastąpienia logiką zarządcy. W literaturze istnieje
szereg technik przechwytywania wywołań systemowych i kontrolowania wykonywania aplikacji,
zwyczajowo nazywane „hooking” bądź „spoofing” [Hog05] [Blun09]. Są one wykorzystywane od
dziesięcioleci przez twórców oprogramowania typu „malware” oraz oprogramowania antywirusowego.
kernel
VM
kernel
VM
kernel
VM
kernel
procesy
VM
kernel
VM
kernel
kernel
zarządca
zarządca
zarządca
sprzęt
sprzęt
procesy
procesy procesy procesy

10. 10
Rys 4 Przykładowe dwa węzły systemu z zarządcą, wykorzystującym wirtualizacje aplikacji
Rys 5 Przechwytywanie wywołań systemowych przez zarządce
sprzęt
kernel
zarządca
procesy
sprzęt
kernel
zarządca
procesy
proces zarządca kernel
syscall
emulowany rezultat

11. 11
3Architekturasystemu
System składa się z kilku rodzajów węzłów - terminal, plikowy, wykonawczy i nadzorczy.
Pojedynczy węzeł to standardowy proces w klasycznym systemie operacyjnym, działającym w ramach
„userland”. Węzły komunikują się przy pomocy gniazd sieciowych TCP, używając wewnętrznego,
binarnego protokołu. Wszystkie węzły mogą znajdować się w tym samym systemie operacyjnym, bądź
mogą zostać rozproszone geograficznie na kilka komputerów. Nie istnieje odgórne ograniczenie ilości
węzłów w systemie, lecz w praktyce ograniczeniem będzie maksymalna ilość równoległych połączeń
TCP IP do węzła nadzorczego. Przewidywalna maksymalna ilość takich połączeń powinna wynosić
kilka bądź kilkanaście tysięcy.
Każdy węzeł w systemie jest identyfikowany przez identyfikator „SID”, który jest unikalną w
całym systemie 64-bitową liczbą. Generowana jest ona na potrzeby każdego nowego węzła, który jest
rejestrowany w systemie – zarówno terminala jak i węzłów systemowych. Następnie ten klucz sesji jest
używany do przyznawania, bądź odmawiania uprawnień do wykonywania operacji w systemie.
Rys 6 Przykładowe połączenia internetowe pomiędzy węzłami systemu
Terminal łączy się z każdym węzłem systemu z osobna. Dzięki temu unikana jest
nadmiarowość jaka miałaby miejsce, gdyby we wszystkich operacjach pośredniczył węzeł nadzorczy.
Nadmiarowość ta miałaby charakter zarówno zduplikowanych operacji logicznych wykonywanych na
węzłach, jak i opóźnień sieciowych i znacząco obniżyłaby wydajność systemu (zwłaszcza w
przypadków węzłów rozproszonych geograficznie). Dzięki użyciu terminala jako intefejsu
użytkownika, rozproszenie i kompleksowość operacji jest niewidoczna, zaś system jest widziany z
węzeł
wykonawczy
węzeł
wykonawczy
węzeł
nadzorczy
terminal
węzeł
plikowy
węzeł
plikowy

12. 12
perspektywy użytkownika jako pojedynczy system operacyjny.
3.1 System plikowy
W ramach niniejszej pracy zaimplementowany został płaski, rozproszony system plikowy.
Służy on do przechowywania plików wykonywalnych, uruchamianych programów oraz plików przez
nie uruchamianych.
System plikowy został maksymalnie uproszczony tak, aby jego implementacja nie była główną
częścią tej pracy. Pliki są identyfikowane po ich nazwie zaś widoczne przestrzenie plikowe są
odseparowane między użytkownikami. Oznacza to, że pojedynczy użytkownik nie może posiadać w
systemie dwóch plików o tej samej nazwie. Kilku użytkowników może posiadać pliki o tej samej
nazwie, lecz są one wzajemnie dla siebie niedostępne (dla uproszczenia zrezygnowano z implementacji
systemu uprawnień między użytkownikami).
Każdy plik w systemie posiada unikalny identyfikator „FID”, który jest 64-bitową liczbą.
Identyfikator jest unikalny w całym systemie (nie może się powtórzyć na żadnym węźle) i jest losowo
generowany dla każdego, nowego pliku.
Dostęp do plików jest kontrolowany przez węzeł nadzorczy. Dostępu do pliku może zarządać
węzeł wykonawczy (na potrzeby odczytu pliku w celu uruchomienia programu) oraz terminal. W
danym momencie tylko jeden węzeł systemu może korzystać z pliku. Pojedynczy węzeł plikowy nie
posiada informacji o tym, który użytkownik jest właścicielem pliku. System uprawnień jest
realizowany przez węzeł zarządzający
Dostęp do pliku jest realizowany dwuetapowo. W pierwszym etapie węzeł łączy się do węzła
zarządzającego i prosi o dostęp do pliku użytkownika o identyfikatorze „UID” i określonej nazwie np.
„program.exe”. W odpowiedzi uzyskuje identyfikator „FID” pliku oraz informacje o węźle plikowym,
który przechowuje ten plik. Węzeł nadzorczy informuje w międzyczasie także wskazany węzeł
plikowy o tym, że wskazany węzeł systemu może się do niego połączyć i uzyskać dostęp do pliku o
identyfikatorze „FID”. W drugim etapie węzeł systemu łączy się z węzłem plikowym i wykonuje jeden
lub więcej operacji na pliku.
Węzeł plikowy implementuje następujące operacje:
1. Otwarcie pliku – plik zostaje zarezerwowany i żaden inny węzeł nie może z niego skorzystać.
2. Odczyt fragmentu pliku – okreslona porcja pliku zostaje odczytana i zwrócona do węzła
systemowego.
3. Zapis fragmentu pliku – określona porcja danych zostaje zapisana do pliku.

13. 13
4. Zamknięcie pliku – wszystkie bufory zostają opróżnione i plik staje się dostępny dla innych
węzłów systemu.
5. Usunięcie pliku – plik zostaje fizycznie usunięty z węzła plikowego, zostaje o tym
poinformowany także węzeł zarządzający.
Podczas uruchamiania węzła plikowego bez argumentów, wyświetla on spodziewane argumenty:
./storagenode
Usage: ./storagenode <port> <dir> <ctl_addr>:<ctl_port>
<port> - port for this node
<dir> - path to the directory, used to store all the files
<ctl_addr>:<ctl_port> - address and port of the control node
Program spodziewa się trzech argumentów:
1. <port> - numer portu, pod którym będą nasłuchiwane połączenia przychodzące do tego węzła.
2. <dir> - ścieżka do katalogu roboczego węzła, jest on używany do przechowywania plików
użytkowników.
3. <ctl_addr>:<ctl_port> - adres i numer portu węzła nadzorczego systemu.
Przykładowe, poprawne wywołanie programu węzła plikowego:
./storagenode 55347 storagedir/ 127.0.0.1:55346
3.2 W ze wykonawczyę ł
W ramach tej pracy został zaimplementowany prosty węzeł wykonawczy, który uruchamia
programy użytkownika, śledzi i przechwytuje ich wywołania systemowe.
Implementacja węzłów wykonawczych systemu jest w dużej mierze zależna od lokalnego
systemu operacyjnego, który ma być wspierany przez te węzły. Generalnie, w ramach tej pracy
zaimplementowane węzły są niezależne od rodzaju systemu, w którym są uruchamiane z wyjątkiem
węzłów wykonawczych, które wspierają tylko i wyłącznie system GNU Linux x64. Węzły zostały
zaimplementowane z użyciem kompilowanego języka programowania D, więc naturalnym
ograniczeniem jest także platforma, na którą mogą zostać skompilowane programy. W chwili realizacji
tej pracy wspieranymi platformami dla języka D były: Windows i386, MacOSX x64 oraz
FreeBSD/GNU Linux w obu wersjach bitowych (i386 oraz x64).
Przechwytywane wywołania systemowe są generalnie ignorowane (mogą być podstawą do
dalszego rozwoju systemu) z wyjątkiem zapisu na standardowe wyjście programu, które jest
przekazywane do konsoli użytkownika, który uruchomił wskazany proces. Podobnie jak w przypadku
węzła plikowego, węzeł wykonawczy jest zależny od wezła nadzorczego, który implementuje system

14. 14
uprawnień.
Węzeł nadzorczy przechowuje informacje i jest informowany o statusie wszystkich procesów
we wszystkich węzłach wykonawczych. Uruchomienie programu składa się z kilku etapów. W
pierwszym etapie terminal rząda uruchomienia programu użytkownika „UID”. W odpowiedzi uzyskuje
identyfikator procesu „PID” oraz informacje o węźle wykonawczym, w którym proces zostanie
uruchomiony. W tym momencie proces pojawia się w systemie ze statusem „NEW_PENDING”. Status ten
oznacza, że węzeł wykonawczy uzyskał polecenie przygotowania do uruchomienia programu od węzła
nadzorczego i zaczął przygotowywać wszystkie potrzebne pliki. W tym momencie węzeł wykonawczy
łączy się z węzłem plikowym (wcześniej prosząc węzeł nadzorczy o uprawnienia) i pobiera plik
wykonywalny programu. W chwili, gdy wszystko zostanie przygotowane do uruchomienia programu,
proces zmienia status na „NEW_READY”. Teraz terminal może zarządać od węzła wykonawczego
uruchomienia programu. Proces zmienia swój status w systemie na „RUNNING”,a po ukończeniu
procesu jego status zmienia się na „FINISHED”.
Podczas uruchamiania węzła wykonawczego bez argumentów, wyświetla on spodziewane argumenty:
./execnode
Usage: ./execnode <port> <dir> <ctl_addr>:<ctl_port>
<port> - port for this node
<dir> - directory, used to store all temporary files of user processes
<ctl_addr>:<ctl_port> - address and port of the control node
Program spodziewa się trzech argumentów:
4. <port> - numer portu, pod którym będą nasłuchiwane połączenia przychodzące do tego węzła.
5. <dir> - ścieżka do katalogu roboczego węzła, jest on używany do przechowywania plików
programów, uruchamianych przez ten węzeł.
6. <ctl_addr>:<ctl_port> - adres i numer portu węzła nadzorczego systemu.
Przykładowe, poprawne wywołanie programu węzła wykonawczego:
./execnode 55348 execdir/ 127.0.0.1:55346
3.3 W ze nadzorczyę ł
Węzeł nadzorczy jest centralnym elementem systemu, który zapewnia spójność i
jednoznaczność stanów pozostałych elementów systemu. Implementuje on system uprawnień
użytkowników, zarządza węzłami systemu, plikami oraz procesami. Pośredniczy on w czasie
przydzielania zasobów systemu (węzłów plikowych oraz wykonawczych) dla użytkowników. Realizuje
on następujące akcje:
1. Rejestracja nowych węzłów w systemie.

15. 15
2. Uwierzytelnianie użytkowników.
3. Przydzielanie dostępu do plików na określonych węzłach plikowych i do procesów na
określonych węzłach wykonawczych.
4. Zmiana uprawnień plików na pliki wykonywalne.
5. Uzyskiwanie informacji o plikach w systemie oraz plikach wykonywalnych.
6. Uzyskiwanie informacji o procesach w systemie.
Podczas uruchamiania węzła nadzorczego bez argumentów, wyświetla on spodziewane argumenty:
./controlnode
Usage: ./controlnode <port> - port for this node
Program spodziewa się jednego argumentu: <port> - numer portu, pod którym będą nasłuchiwane
połączenia przychodzące do tego węzła.
Przykładowe, poprawne wywołanie programu węzła wykonawczego:
./controlnode 55346
Rys 7 Komunikacja między węzłami w czasie rejestracji nowego węzła w systemie
3.4 Terminal u ytkownikaż
W ramach pracy została zaimplementowana konsola sterująca, która służy jako interfejs
użytkownika do sterowania systemem. Terminal tworzy warstwe abstrakcji, dzięki której system jest
widoczny dla użytkownika jako pojedynczy system operacyjny z pojedynczym węzłem.
Logicznie polecenia terminala można podzielić na trzy grupy:
terminal
węzeł
nadzorczy
węzeł
wykonawczy
węzeł
plikowy
IP terminala
SID terminala
login / hasło
SID terminala
IP terminala
SID terminala

16. 16
1. Wbudowane polecenia, realizowane wewnętrznie przez terminal. Poleceniem tego typu jest
przykładowo polecenie wyświetlające pliki użytkownika w systemie, które jest realizowane
jako żądanie wysłane do węzła nadzorczego.
2. Lokalne polecenia, uruchamiające programy na lokalnym komputerze. Są one poprzedzone
wykrzyknikiem na początku polecenia. Przykładowe polecenie wyświetlające lokalne pliki
komputera w korzeniu lokalnego systemu plików: „!ls /”.
3. Polecenia uruchamiające procesy na węzłach wykonawczych.
Następujące polecenia zostały implementowane w terminalu użytkownika:
• connect 127.0.0.1:55346 - łączy się z węzłem nadzorczym systemu, dostępnym pod adresem
127.0.0.1 oraz porcie 55346, a następnie pyta użytkownika o login oraz hasło do systemu.
Obecnie zaimplementowane jest tylko jedno konto użytkownika o loginie „user” oraz
dowolnym haśle (hasło jest ignorowane).
• exit – zamyka wszystkie aktywne połączenia internetowe z węzłami systemu oraz wychodzi z
programu.
• ps – wyświetla liste wszystkich procesów we wszystkich węzłach w systemie. Lista jest postaci:
3143969404512509832 127.0.0.1:55348 FINISHED sample
7443299484318509704 127.0.0.1:55348 NEW_PENDING sample_progr2
gdzie kolejne kolumny oznaczają:
1. PID – unikalny, globalny identyfikator procesu.
2. Adres i port jednostki wykonawczej, która została przydzielona do procesu przez węzeł
nadzorczy.
3. Status procesu w systemie.
4. Nazwa pliku wykonywalnego programu oraz argumenty, użyte do uruchomienia
programu.
• put <plik_lokalny> <plik_zdalny> - wysyła plik lokalny w aktualnym katalogu roboczym
konsoli do węzła plikowego, przydzielonego przez węzeł nadzorczy. <plik_zdalny> jest nazwą,
pod jaką ma być on identyfikowany w systemie.
• get <plik_zdalny> <plik_lokalny> - pobiera plik zdalny systemu z węzła plikowego do
aktualnego katalogu roboczego konsoli.
• rm <nazwa_pliku> - usuwa zdalny plik z systemu.

17. 17
• lsf – wyświetla wszystkie pliki użytkownika w systemie we wszystkich węzłach plikowych.
• exec <nazwa_pliku> - przydziela uprawnienia do wykonywania dla pliku.
• lse – wyświetla wszystkie pliki wykonywalne użytkownika w systemie.
• <nazwa_pliku> <argumenty> - uruchamia zdalny program o wskazanej nazwie w systemie,
przekazując do niego określone argumenty.
• !<nazwa_pliku> <argumenty> - uruchamia lokalny program o wskazanej nazwie w lokalnym
systemie użytkownika, przekazując do niego określone argumenty.

18. 18
4Implementacjaelementówsystemu
Jak już wspomniano w poprzednich rozdziałach węzły systemu są programami,
zaimplementowanymi z języku programowania D. Język ten jest kompilowalnym językiem wysokiego
poziomu o sile ekspresji bliższej skryptowym językom programowania, jak python, niż tradycyjnym
wieloparadygmatowym językom, jak C++. Język ten jest rozwijany już od kilkunastu lat i doczekał się
dojrzałego kompilatora, wspierającego popularne systemy operacyjne. W odczuciu autora tej pracy,
praca z tym językiem programowania nie nastręczała problemów, w szczególności komunikaty o
błędach kompilacji były czytelne i intuicyjne.
Język programowania D domyślnie nie posiada systemu budowania, więc do budowy projektu
został użyty język programowania Ruby wraz z narzędziem automatyzującym proces budowy
projektów Ruby Rake. Do śledzenia programów został użyty pomocniczy program w języku
programowania C, który komunikuje się bezpośrednio z węzłem wykonawczym. Do pracy nad kodem
systemu został użyty IDE Eclipse DDT, oferujący podstawowe wsparcie dla języka programowania D
tj. kolorowanie składni języka czy proste sprawdzanie błędów składni.
Projekt składa się z około (nie licząc komentarzy):
• 4000 linii kodu języka D
• 100 linii kodu języka C
• 40 linii kodu Ruby Rake
Struktura katalogów projektu jest następująca:
AUTHORS - informacje o autorach projektu
bin/ - wynikowe pliki kompilacji
build/ - pośrednie pliki kompilacji
commonutils/ - kod źródłowy, współdzielony przez wszystkie węzły systemu
controlnode/ - kod źródłowy węzła nadzorczego
COPYING - tekst licencji
execnode/ - kod źródłowy węzła wykonawczego
Rakefile - kod źródłowy Ruby Rake
storagenode/ - kod źródłowy węzła plikowego
terminal/ - kod źródłowy terminala sterującego
W celu kompilacji projektu w głównym katalogu projektu należy wykonać polecenie „rake”,
bądź „rake build”. System, na którym odbywa się kompilacja musi posiadać kompilator języka D,
uruchamiany poleceniem „dmd” oraz kompilator języka C, uruchamiany poleceniem „gcc”.
W katalogu „commonutils/” znajdują się następujące pliki:
• bufStream.d – implementacja strumienia danych „BufStream”, który serializuje i deserializuje
struktury danych w sposób niezależny od platformy. Strumień ten jest używany do serializacji

19. 19
danych w celu przesłania ich przez sieć.
• commonData.d – definicje struktur danych i typów, które są używane globalnie w projekcie w
pozostałych plikach.
• connection.d – implementacja wątku, który odczytuje i wysyła pojedyncze jednostki danych
systemu. Jest on używany przez wszystkie węzły systemu.
• logger.d – implementacja klasy logującej komunikaty węzłów do pliku oraz na standardowe
wyjście procesów, logowanie odbywa się zawsze w osobny wątku programu.
• nodeServer.d – implementacja serwera, który nasłuchuje przychodzących połączeń na
wskazanym porcie oraz tworzy wątki, dla każdego nowego połączenia. Serwer ten przekazuje
jednostki danych z wątków roboczych połączeń do głównej logiki programów. Jest on używany
przez węzeł wykonawczy, plikowy oraz nadzorczy. W węźle wykonawczym przekazuje on
także porcje danych z wątków śledzących procesy użytkownika do głównej logiki węzła.
• request.d – podstawowa jednostka danych, używana w binarnym protokole komunikacji
między węzłami systemu. Szczegóły protokołu komunikacji są opisane w rozdziale 4.5
• sysNode.d – implementacja klasy abstrakcyjnej „SysNode”, która jest klasą bazową dla
pozostałych węzłów systemu.
• sysSignal.d – implementacja przechwytywania sygnałów SIGTERM oraz SIGINT systemu
GNU Linux. Dzięki temu kombinacja klawiszy Ctrl+C pozwala zakończyć działanie węzła bez
ryzyka przerwania aktualnie wykonywanych operacji.
4.1 Konsola u ytkownikaż
W katalogu „terminal/” znajdują się następujące pliki:
• commandParser.d – implementacja parsera poleceń konsoli
• main.d – główny plik programu, przekierowywuje on sterowanie do głównej logiki programu
w zależności od wpisanego polecenia oraz w zależności od otrzymanej porcji danych z
połączonych węzłów. W tym pliku wywoływany jest parser wpisywanych poleceń oraz czytane
jest standardowe wejście programu w osobnym wątku, aby nie blokować obsługi połączeń
internetowych.
• terminal.d – implementacja głównej logiki terminala. Uruchamia lokalne programy, przekazuje
polecenia do węzłów systemu oraz obsługuje zwracane komunikaty z węzłów. Tutaj
zaimplementowane są także wbudowane polecenia konsoli.

20. 20
Rys 8 Wątki w procesie terminala użytkownika i kierunki komunikacji między nimi
Przykładowa sesja terminala, w której uruchomiony zostaje program użytkownika, który wypisuje na
swoje standardowe wyjście komunikat „Hello!”:
$> ./terminal <--- uruchom terminal
$> connect 127.0.0.1:55346 <--- polącz się z węzłem nadzorczym
username: user
password:
$> INFO| Authorisation successful
$> !ls <--- uruchom lokalne polecenie „ls”
controlnode controlnode.log execdir execnode execnode.log sample sample.c storagedir
storagenode storagenode.log terminal terminal.log traceWrapper
$> put sample myProgram <--- wyślij plik „sample” do systemu
INFO| remote file sample uploaded successfully
$> lsf <--- wyświetl pliki w systemie
myProgram
( 1 files )
$> lse <--- wyświetl pliki wykonywalne w systemie
( 0 executables )
$> myProgram <--- spróbuj uruchomić plik wykonywalny „myProgram”
$> ERROR| Request exec failed: File 'myProgram' is not an executable
ERROR| Failed to request exec resource for subcommand 'myProgram'
$> exec myProgram <--- przyznaj uprawnienia do wykonywania dla pliku „myProgram”
główny wątek
wątek połączenia
wątek połączenia
wątek logowania wątek stdin

21. 21
$> lse
myProgram
( 1 executables )
$> myProgram <--- uruchom plik wykonywalny „myProgram”
$> Hello! <--- standardowe wyjście procesu „myProgram”, zwrócone przez węzeł wykonawczy
$> ps <--- wyświetl status wszystkich procesów użytkownika w systemie
6536767514343214268 127.0.0.1:55348 FINISHED myProgram
( 1 processes )
$> exit <--- wyloguj się z systemu, zakończ program terminala
INFO| Exiting...
4.2 W ze plikowyę ł
W katalogu „storagenode/” znajdują się następujące pliki:
• main.d – główny plik pogramu, obsługuje argumenty przekazane do programu z linii poleceń,
łączy się z węzłem nadzorczym, uruchamia wątek logujący komunikaty oraz tworzy serwer
nasłuchujący i obsługujący przychodzące połączenia internetowe.
• storageCommonData.d – definicje struktur danych i typów, które są używane w pozostałych
plikach węzła plikowego.
• storageNode.d – implementacja głównej logiki węzła plikowego. Obsługuje polecenia
pozostałych węzłów systemu – otwiera, odczytuje i zapisuje pliki.
Rys 9 Wątki w procesie węzła plikowego i kierunki komunikacji między nimi
główny wątek
wątek połączenia
wątek połączenia
wątek logowania

22. 22
Węzeł plikowy przechowuje pliki użytkowników w katalogu roboczym, przekazanym w
argumencie w linii poleceń. W tym katalogu tworzone są nowe podkatalogi dla każdego nowego pliku i
w nich są trzymane pliki użytkowników. Nazwy tworzonych podkatalogów są takie same jak unikalne
identyfikatory FID plików. Przykładowa zawartość katalogu roboczego węzła, przechowującego dwa
pliki:
$> ls storagedir/
2890572740485538829/
4819999864899655587/
Kolejne dwie liczby oznaczają kolejne dwa identyfikatory FID plików użytkowników.
Rys 10 Komunikacja między węzłami podczas wysyłania pliku do systemu
4.3 W ze wykonawczyę ł
W katalogu „execnode/” znajdują się następujące pliki:
• execCommonData.d – definicje struktur danych i typów, które są używane w pozostałych
plikach węzła wykonawczego.
• execNode.d – implementacja głównej logiki węzła wykonawczego. Pobiera pliki programów z
węzłów plikowych, uruchamia i śledzi procesy użytkowników, przekazuje standardowe wyjście
procesów do terminali użytkowników, informuje węzeł nadzorczy o zmianie statusu procesów.
• main.d – główny plik pogramu, obsługuje argumenty przekazane do programu z linii poleceń,
łączy się z węzłem nadzorczym, uruchamia wątek logujący komunikaty oraz tworzy serwer
nasłuchujący i obsługujący przychodzące połączenia internetowe.
terminal
węzeł
nadzorczy
węzeł
plikowy
żąda dostępu FID pliku, SID terminalażąda dostępu do pliku
FID pliku, SID węzła plikowego
SID terminala, FID pliku, otwórz plik
FID pliku, zapisz 40 bajtów danych
FID pliku, zamknij plik

23. 23
• procTracer.d – implementacja wątka roboczego, który czeka na dane od procesu śledzącego w
celu przekazania ich do głównej logiki programu.
• traceWrapper.c – implementacja programu języka C, śledzącego wywołania systemowe
programów użytkowników przy pomocy funkcji systemowej ptrace(). Standardowe wyjście z
tego programu jest śledzone i interpretowane przez wątek roboczy z pliku procTracer.d
Rys 11 Wątki w procesie węzła wykonawczego i kierunki komunikacji między nimi
Węzeł wykonawczy przechowuje tymczasowe pliki uruchamianych programów w katalogu roboczym,
przekazanym w argumencie w linii poleceń. W tym katalogu tworzone są nowe podkatalogi dla
każdego nowego procesu i w nim są trzymane wszystkie pliki danego procesu. Nazwa utworzonego
podkatalogu jest taka sama jak unikalny identyfikator PID procesu. Przykładowa zawartość katalogu
roboczego węzła z uruchomionymi trzema procesami użytkownika:
$> ls execdir/
2909333461947129461/
3143969404512509832/
5544610717937339437/
Kolejne trzy liczby oznaczają kolejne trzy identyfikatory PID procesów użytkowników.
główny wątek
wątek połączenia
wątek połączenia
wątek logowania
wątek śledzący
wątek śledzący
pomocniczy
proces śledzący
pomocniczy
proces śledzący

24. 24
Rys 12 Komunikacja między węzłami podczas uruchamiania procesu
terminal węzeł
nadzorczy
węzeł
wykonawczy
węzeł
plikowy
PID procesu,
nazwa pliku
żąda dostępu do procesu
PID procesu,
SID w. wykonawczego
żąda dostępu do pliku
FID pliku, SID w. wykonawczego
FID pliku, SID węzła plikowego
SID w. wykonawczego,
FID pliku, otwórz plik
FID pliku, odczytaj 40 bajtów
FID pliku, zamknij plik
PID procesu,
NEW_READY
PID procesu, uruchom proces
PID procesu,
RUNNING
PID procesu, STDOUT procesu
PID procesu,
FINISHED

25. 25
Implementacja węzła wykonawczego wykorzystuje pomocniczy program w języku C do
śledzenia wywołań systemowych procesów użytkownika przy pomocy funkcji systemowej ptrace().
Rozwiązanie to zostało zastosowane by uprościć implementacje, gdyż język programowania D
umożliwia bezpośrednie wywołanie funkcji języka C, bez potrzeby stosowania pośrednich programów.
W tym celu wymagana jest odpowiednia deklaracja wywoływanych funkcji w plikach programu. W
celu uproszczenia tego zadania, twórca języka stworzył prosty program, który parsuje pliki
nagłówkowe *.h języka C i generuje deklaracje struktur i prototypów funkcji w języku D. Szczegóły są
dostępne na stronie twórcy języka D pod adresem: http://dlang.org/htod.html
4.4 W ze nadzorczyę ł
W katalogu „controlnode/” znajduja się następujące pliki:
• controlCommonData.d – definicje struktur danych i typów, które są używane w pozostałych
plikach węzła nadzorczego.
• controlNode.d – implementacja głównej logiki węzła nadzorczego. Obsługuje autoryzacje i
klucze sesyjne w systemie, przydziela węzły plikowe i wykonawcze, przekazuje informacje o
aktualnym stanie systemu i zarejestrowanych węzłach.
• main.d – główny plik pogramu, obsługuje argumenty przekazane do programu z linii poleceń,
uruchamia wątek logujący komunikaty oraz tworzy serwer nasłuchujący i obsługujący
przychodzące połączenia internetowe.
Rys 13 Wątki w procesie węzła nadzorczego i kierunki komunikacji między nimi
główny wątek
wątek połączenia
wątek połączenia
wątek logowania

26. 26
4.5 Binarny protokó komunikacji i logi programówł
Komunikacja między węzłami systemu odbywa się przy pomocy binarnego protokołu i gniazd
TCP IP. Komunikaty są przekazywane przy pomocy pojedynczej jednostki danych zwanej „Request”.
Struktura takiej porcji danych jest następująca:
int32 rozmiar całego pakietu danych
int32 typ pakietu danych, możliwe wartości są zadeklarowane przez „enum RequestType”
int32 id pakietu danych, możliwe wartości są zadeklarowane przez typy:
„enum RequestGenericId”, „enum RequestStorageId”, „enum RequestControlId”,
„enum RequestTerminalId”, „enum RequestExecId”, „enum RequestExecWorkerId”
int64 unikalny identyfikator pakietu, używany do informacji zwrotnych o błędnych argumentach
int32 ilość argumentów w pakiecie
<argumenty>
Argumenty mają następujący format:
int8 typ argumentu, możliwe wartości są zadeklarowane przez typ „enum ReqArgTypes”
<dane argumentu>
Dane argumentu mogą przyjmować jedną z następujących wartości:
dla liczby jednobajtowej:
int8
dla liczby dwubajtowej:
int16
dla liczby czterobajtowej:
int32
dla liczby ośmiobajtowej:
int64
dla łańcucha znakowego char[]:
<wewnętrzna implementacja, zależna od użytego kompilatora języka D>
dla tablicy bajtów uint8[]:
int32 rozmiar tablicy
int8 * rozmiar dane tablicy
Debugowanie programów jest utrudnione z uwagi na wielowątkową naturę procesów węzłów systemu
oraz intesywną, asynchroniczną komunikację sieciową między wezłami. Dlatego bardzo istotną rolę w
pracy na kodem systemu odgrywają logi programów. Każdy węzeł systemu tworzy plik o nazwie
<nazwa_węzła>.log, gdzie wędrują wszystkie komunikaty diagnostyczne oraz komunikaty o błędach
systemu. Przykładowy fragment pliku logu dla węzła plikowego, po uruchomieniu programu
„myProgram” z rozdziału 4.1 :
2014-Jun-22 21:08:37.3780514Z DEBUG| storagenode: [ 4837359113842351648 ] [ 8 ]
hCtrlFileGrantAccess, FID: 3253554305478078538, filename: 'myProgram', sid: 2112842788847146420
2014-Jun-22 21:08:37.4254866Z DEBUG| sysnode: [ 2112842788847146420 ] [ 5 ] hGenAuthorise,
sessionKey: 2112842788847146420, address: 127.0.0.1:55076
2014-Jun-22 21:08:37.4255601Z DEBUG| connection: [ 2112842788847146420 ] [ 5 ] send Request
type: 1, id: 4, size: 31
2014-Jun-22 21:08:37.5259984Z DEBUG| storagenode: [ 2112842788847146420 ] [ 6 ] hstOpen, FID:
3253554305478078538, mode: wb
2014-Jun-22 21:08:37.5261137Z DEBUG| storagenode: [ 2112842788847146420 ] [ 6 ] successfully

27. 27
opened file 'myProgram'
2014-Jun-22 21:08:37.5261997Z DEBUG| connection: [ 2112842788847146420 ] [ 6 ] send Request
type: 4, id: 1, size: 67
2014-Jun-22 21:08:37.92832Z DEBUG| storagenode: [ 2112842788847146420 ] [ 7 ] hStWrite, FID:
3253554305478078538, data.length: 6760
2014-Jun-22 21:08:37.9284215Z DEBUG| storagenode: [ 2112842788847146420 ] [ 7 ] Write success
2014-Jun-22 21:08:37.9285514Z DEBUG| connection: [ 2112842788847146420 ] [ 7 ] send Request
type: 4, id: 3, size: 44
2014-Jun-22 21:08:38.028845Z DEBUG| storagenode: [ 2112842788847146420 ] [ 8 ] hStClose, FID:
3253554305478078538
2014-Jun-22 21:08:38.0289358Z DEBUG| storagenode: [ 2112842788847146420 ] [ 8 ] successfully
closed file 'myProgram'
Typowy komunikat w logu zawiera:
1. Dokładną date każdego zalogowanego komunikatu np.”2014-Jun-22 21:08:37.92832Z”
2. Typ komunikaty, który może przyjmować wartości „DEBUG”, „INFO”, „WARNING” oraz
„ERROR”.
3. Identyfikator miejsca w kodzie, w którym komunikat został wysłany np. „storagenode” dla
komunikatów w głównej logice węzła plikowego.
4. Identyfikator sesji węzła SID, którego obsługa spowodowała zalogowanie komunikatu,
przykładowo wartość „[ 2112842788847146420 ]” jest identyfikatorem sesji terminala, zaś
wartość „[ 4837359113842351648 ]” jest identyfikatorem sesji węzła zarządzającego.
5. Identyfikator pakietu danych, którego obsługa spowodowała zalogowanie komunikatu – zwykle
są to kolejne liczby dla kolejnych pakietów danych z danego węzła.
6. Treść komunikatu np. „Write success”.
4.6 Wydajno wykonywania procesów u ytkownikaść ż
Procesy wykonywane w zaimplementowanym systemie operacyjnym wykonują się wolniej niż
w tradycyjnych systemach operacyjnych. Spowodowane jest to dwoma czynnikami. Pierwszym
narzutem wydajnościowym jest śledzenie wszystkich wywołań systemowych. Proces jest
zatrzymywany dwukrotnie dla każdej operacji „syscall” – pierwszy raz przed obsłużeniem „syscall”
przez jądro, a drugi raz po obsłużeniu przerwania przez jądro systemu. Narzut w tym wypadku zależy
od charakteru aplikacji i jest proporcjonany do ilości wywoływanych systemowych. Wynosi typowo
kilka procent dla popularnych aplikacji użytkowych [mll08], lecz dla aplikacji intensywnie
korzystających z wywołań systemowych (np. polecenie „find”) wydajność aplikacji może spaść nawet
dziesięciokrotnie.

28. 28
Podobnie, kolejnym narzutem jest komunikacja sieciowa, jaka musi mieć miejsce w celu
obsłużenia np. dostępu do zasobów plikowych. W tym przypadku spadek wydajności jest
proporcjonalny do ilości wywołań systemowych oraz opóźnień sieciowych, które zależą od topologii
sieci oraz geolokalizacji węzłów systemowych. Najbardziej pesymistyczny przypadek to aplikacje
intensywnie korzystające z wywołań systemowych (np. polecenie „find”), realizowanych przez
komunikacje sieciową między węzłami, które są rozmieszczone w odległych geolokalizacyjne
miejscach. W takim przypadku, spodziewany spadek wydajności może być nawet kilkusetkrotny.

29. 29
5Podsumowanie
Praca miała na celu zaimplementowanie prototypowego systemu operacyjnego, działającego w
trybie „userland” tradycyjnego systemu operacyjnego. Praca nad kodem systemu i jego debugowanie
okazało się być utrudnione ze względu na wielowątkową naturę węzłów i intesywną, asynchroniczną
komunikację sieciową. Praca dowiodła, iż możliwe jest skontruowanie rozproszonego systemu
operacyjnego, działającego w ramach istniejących systemów operacyjnych typu GNU Linux w trybie
„userland”, który umożliwia wykonywanie w rozproszonym środowisku programów binarnych, które
nigdy nie zostały napisane, ani dostosowane do wykonywania w systemach typu „cloud”.
Wykonywanie procesów użytkownika wiąże się z narzutem wydajnościowym, lecz okazuje się, że
narzut ten jest akceptowalny dla procesów intensywnych obliczeniowo, z niską ilością wywołań
systemowych.
Dalszy rozwój implementacji systemu w krótkiej perspektywie powinien uwzględnić:
1. Dokończenie systemu uprawnień i autoryzacji kont użytkowników.
2. Wprowadzenie szyfrowanych połączeń internetowych.
3. Zastąpienie pomocniczego programu śledzącego przez bezpośrednie wywołania funkcji języka
C.
4. Rozbudowanie ilości śledzonych wywołań systemowych.
5. Dodanie możliwości potokowania procesów użytkowników.
6. Wsparcie dla większej ilości systemów operacyjnych np. Windows
7. Implementacji konsoli użytkownika w przeglądarce z użyciem języka JavaScript oraz
technologii WebSocket.
Rozwój implementacji w dalszej perspektywie powinien uwzględnić analize problematyki:
1. Skalowalności oraz niezawodności w przypadku awarii węzłów.
2. Sieci wirtualnych i problematyki NAT Traversal.
3. Kontroli zasobów systemowych, wykorzystywanych przez procesy użytkownika na danym
węźle.
4. Graficznego interfejsu użytkownika uruchamianych procesów użytkownika.

30. 30
6Literatura
[Tan07] Andrew S. Tanenbaum, Maarten Van Steen: „Distributed Systems Principles and Paradigms”,
Upper Saddle River, NJ: Prentice Hall, 2nd
ed., 2007
[Tan95] Andrew S. Tanenbaum: „Distributed Operating Systems”, Upper Saddle River, NJ: Prentice
Hall, 1995.
[mll08] Mohd Fadzli Marhusin, Henry Larkin, Chris Lokan, David Cornforth „An Evaluation of API
Calls Hooking Performance”, 8 International Conference on Computational Intelligence and Security,
2008
[fpa10] Fabio Pianese, Peter Bosh, Alessandro Duminuco, Nico Janssens, Thanos Stathopoulus, Moritz
Steiner: „Toward a cloud operating system”, Network Operations and Management Symposium
Workshops, 2010
[afg09] Michael Armbrust, Armando Fox, Rean Griffith, Anthony D. Joseph, Randy Katz, Andy
Konwinski, Gunho Lee, David Patterson, Ariel Rabkin, Ion Stoica, and Matei Zaharia: „Above the
Clouds: A Berkeley View of Cloud Computing”, Communications of the AC, 2009
[apt11] Andreas Polze, Peter Tröger: „Trends and challenges in operating systems—from parallel
computing to cloud computing”, Concurrency and computation: practice and experience, 2011
[sav11] Sanil C. Savale: „Trends in cloud operating system”, International Conference on Recent
Trends in Information Technology and Computer Science (IRCTITCS), 2011
[zsz10] Youhui Zhang, Gelin Su, Weimin Zheng: „Streaming legacy desktop software from the cloud”,
ADVCOMP, 2010
[Hog05] Greg Hoglund, James Butler: „Rootkits: Subverting the Windows Kernel”, Addison Wesley
Professional, 2005
[Blun09] Bill Blunden: „The Rootkit Arsenal: Escape and Evasion in the Dark Corners of the System”,
Jones and Bartlett Publishers, 2009