Mechanizmy komunikacyjne w systemach Windows i

Mechanizmy komunikacyjne w systemach Windows i

Mechanizmy komunikacyjne w systemach Windows
i Windows XP.
Przemysław Musiał, Artur Zezula
14 grudnia 2002
Spis treści
1 Wstep
˛
3
1.1 Mechanizmy systemów Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Mechanizmy proste
4
5
2.1 Schowek (Clipboard) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.1.1 Formaty i ich rejestracja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.1.2 Operacje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.1.2.1
Kopiowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.1.2.2
Wklejanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.1.2.3
Właściciel schowka . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.1.2.4
Podglad
˛ schowka . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.1.2.5
Generowanie na żadanie
˛
. . . . . . . . . . . . . . . . . . . . . . . . .
9
2.1.2.6
Pami˛eć . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.2 Data Copy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.3 File Mapping (Pami˛eć współdzielona)
. . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.3.1 Obiekt mapowania pliku . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.3.2 Widoku pliku
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.4 Mailslots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.5 Potoki (Pipes) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.5.1 Named Pipes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.5.1.1
Nazwa potoku . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.5.1.2
Synchronizacja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.5.2 Anonymous Pipes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.6 NetBIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3 Mechanizmy rozbudowane
17
3.1 COM (COM+) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.1.1 COM od podszewki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.1.1.1
Kompatybilność binarna . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.1.2 Dost˛epność . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.1.3 Object Linking and Embedding (OLE) . . . . . . . . . . . . . . . . . . . . . .
20
3.2 DDE (DDEML)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
3.2.1 Ogólnie o DDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
1
SPIS TREŚCI
SPIS TREŚCI
3.2.2 DDEML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.2.2.1
Inicjalizacja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.2.2.2
Funkcja zwrotna DdeCallback . . . . . . . . . . . . . . . . . . . . .
23
3.2.2.3
Wykorzystanie stringów . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.2.2.4
Nawiazywanie
˛
połaczenia
˛
- konwersacje
. . . . . . . . . . . . . . .
23
3.2.2.5
Zarzadzanie
˛
danymi . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.2.2.6
Transakcje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.3 RPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.4 Windows Sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
3.4.1 Windows Sockets 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
4 Podsumowanie
31
5 Bibliografia
34
2
Rozdział 1
Wstep
˛
Wi˛ekszość obecnie używanych systemów posiada mechanizmy ułatwiajace
˛ komunikacj˛e i wymian˛e danych mi˛edzy programami. Zespół wszystkich tych mechanizmów określany jest mianem
Interprocess Communication w skrócie IPC. Zakres użycia każdego z mechanizmów jest
odmienny - jedne specjalizowane sa˛ do wymiany danych lokalnie, pomi˛edzy procesami, inne
natomiast pomi˛edzy komputerami w sieci.
Aplikacje używajace
˛ IPC podlegaja˛ hierarchii klient-serwer w przypadku pojedynczego
połaczenia.
˛
Aplikacja nadrz˛edna serwer udost˛epnia zasób/serwis, przetwarza żadania,
˛
a aplikacja podrz˛edna klient - korzystaja˛ z zasobu/serwisu, przekazuje własne żadania.
˛
Aplikacja może korzystać z wielu mechanizmów i wyst˛epować w każdej z ról.
Różnorodność mechanizmów IPC powoduje, iż cz˛esto trudno wybrać jest ta˛ właściwa.
˛ W
wielu przypadkach b˛edziemy zmuszeni do wykorzystania kilku mechanizmów celem uzyskania
jak najlepszego efektu. Przed wyborem mechanizmu warto odpowiedzieć sobie na nast˛epujace
˛
pytania:
• Czy aplikacja b˛edzie komunikowała si˛e tylko z lokalnymi aplikacjami, czy również b˛edzie
zachodziła konieczność wymiany danych przez sieć?
• Czy w przypadku wymiany danych przez sieć komputery sa˛ pod kontrola˛ tych samych czy
różnych systemów operacyjnych?
• Czy użytkownik b˛edzie miał możliwość wyboru z którymi aplikacjami ma zajść wymiana
danych, czy raczej aplikacja b˛edzie miała określona˛ z góry grup˛e kooperantów?
• Czy komunikacja ma odbywać si˛e mi˛edzy wieloma różnymi aplikacjami w ogólnej formie
(n.p. kopiowanie), czy raczej b˛edzie to wymiana konkretnych danych ograniczajaca
˛ si˛e do
określonego zbioru wzajemnych interakcji?
• Jak ważna jest wydajność?
• Czy używane aplikacje maja˛ GUI? - cześć mechanizmów pracuje tylko z takimi.
3
ROZDZIAŁ 1. WSTEP
˛
1.1. MECHANIZMY SYSTEMÓW WINDOWS
1.1 Mechanizmy systemów Windows
Systemy operacyjne firmy Microsoft kryjace
˛ si˛e pod nazwa˛ Windows oferuja˛ szeroka˛ gam˛e mechanizmów komunikacyjnych. Do dyspozycji mamy:
• Schowek (Clipboard)
• COM
• Data Copy
• DDE
• File Mapping
• Mailslots
• Potoki (Pipes)
• RPC
• Windows Sockets
W dalszej cz˛eści przybliżymy kolejno każdy z mechanizmów.
4
Rozdział 2
Mechanizmy proste
2.1 Schowek (Clipboard)
Na pierwszy rzut oka, możemy być zdziwieni, ale schowek jest właśnie mechanizmem komunikacji mi˛edzy aplikacjami. Obecnie bez jego funkcjonalności nie wyobrażamy sobie pracy z komputerem. Idea działania jest bardzo prosta. W systemie istnieje magazyn do, którego możemy
skopiować dane w wybranych przez siebie formatach, zarówno ogólnych jak i własnych. Aplikacja, która chce z nich skorzystać po prostu wybiera format, który zna i obsługuje. Poniższy
rysunek właśnie to obrazuje.
Rysunek 2.1: Wklejanie arkusza kalkulacyjnego do edytora tekstów
Jak już wspomnieliśmy dane moga˛ być w dowolnym formacie. Każdy format jest identyfikowany przez liczb˛e całkowita,
˛ a standardowe (predefiniowane) formaty sa˛ zdefiniowane w
pliku nagłówkowym Winuser.h. W przypadku formatów własnych, ich identyfikator zwracany
jest podczas rejestracji. Oprócz rejestracji typów danych schowka, wi˛ekszość operacji na schowku
wykonuja˛ pojedyncze okna. Przeważnie procedura okna pobiera lub umieszcza informacje jak
5
ROZDZIAŁ 2. MECHANIZMY PROSTE
2.1. SCHOWEK (CLIPBOARD)
wynik komunikatu WM_COMMAND. Schowek powinien być sterowany poprzez użytkownika,
tzn. wszelkie operacje na danych winny odbywać si˛e polecenie użytkownika.
Podgląd
schowka
Zmiana
zawartośći
Akceptowalny format
Schowek
Rejestracja formatów
Lista dostępnych
formatów
Aplikacja A
Format F1
Okno
aplikacji A
Format F2
Eksport
w formatach
Aplikacja B
Dane
w wybranym
formacie
Okno
aplikacji B
Format F3
Kopiuj
Wklej
Użytkownik
Rysunek 2.2: Użycie i działanie schowka
W aplikacjach systemu Windows schowek powiazany
˛
jest z nast˛epujacymi
˛
operacjami powiazanymi
˛
z aktywnym oknem:
• kopiowanie / wycinanie zaznaczonego obszaru do schowka
• wklejanie zawartości schowka w formacie wybieranym automatycznie
• wklejanie z możliwościa˛ wyboru formatu (jak na rysunku 2.1)
W przypadku schowka istnieje również możliwości dołaczenia
˛
specjalnej aplikacji do podgladu
˛
zawartości. W momencie zmiany zawartości schowka jest ona o tym zawiadamiana.
2.1.1
Formaty i ich rejestracja
Aplikacja kopiujac
˛ dane do schowka może umieścić je w kilku formatach. Schowek ma określone
standardowe formaty obsługujace
˛ tekst, grafik˛e i dźwi˛ek. Pełny ich wykaz można znaleźć na
6
ROZDZIAŁ 2. MECHANIZMY PROSTE
2.1. SCHOWEK (CLIPBOARD)
stronach MSDN i przytaczanie całego spisu tutaj jest zb˛edne. W Windows 2000/XP wprowadzono
jedynie obsług˛e UNICODE’u oraz jeden typ graficzny. Ciekawszym aspektem jest rejestracja
własnych formatów, gdyż wi˛ekszość aplikacji właśnie korzysta z tej możliwości, aby uniknać
˛
utraty informacji przy zmianie formatu. Nowe formaty rejestrowane sa˛ przy pomocy funkcji
RegisterClipboardFormat. Nowy format identyfikowany jest przez nazw˛e, po rejestracji przydzielany jest wolny numer identyfikacyjny. W przypadku gdy dwie aplikacje używaja˛ formatu
o tej samej nazwie, rejestrowany jest tylko jeden i o ile sa˛ zgodne aplikacje moga˛ wymieniać
mi˛edzy soba˛ dane.
Aplikacja może również umieścić dane w schowku oznaczajac
˛ je wartościa˛ formatu
od CF_PRIVATEFIRST do CF_PRIVATELAST. Identyfikatory z wyżej wymienionego
przedziału oznaczaja˛ dane prywatne aplikacji i ich typ nie musi być rejestrowany. Pami˛eć
zajmowana przez dane w formacie prywatnym nie jest zwalniania automatycznie.
Po
otrzymaniu komunikatu WM_DESTROYCLIPBOARD właściciel danych powinien uwolnić
zajmowana˛ pami˛eć.
Podobne zastosowanie ma również przedział identyfikatorów od CF_GDIOBJFIRST do
CF_GDIOBJLAST. Powyższy przedział zarezerwowany jest dla formatów obiektów Microsoft
Windows Graphics Device Interface (GDI). W tym przypadku nie mamy bezpośredniego
wskaźnika na obiekt ale uchwyt zwracany przez funkcje GlobalAlloc z ustawiona˛ flaga˛
GMEM_MOVEABLE. Pami˛eć zajmowana przez obiekt jest automatycznie uwalniania przy
opróżnianiu schowka.
Chcac
˛ wstawić dane w kilku formatach należy przeprowadzić ta˛ operacji w kolejności malejacej
˛ pod katem
˛
ilości posiadanej informacji. Formaty w schowku porzadkowane
˛
sa˛ według kolejności wstawiania i aplikacja chcaca
˛ wstawić obiekt ze schowka przeszukuje list˛e dost˛epnych
formatów dopóki nie napotka jej znanego.
W ostatnich wersjach systemu poszerzono również list˛e wewn˛etrznych konwersji mi˛edzy formatami. Dzi˛eki temu, o ile istnieje taka możliwość, odpytujac
˛ schowek o dost˛epne formaty
listowane sa˛ również te do których możliwa jest konwersja zaraz po formacie, który wstawiła
aplikacja.
Dodatkowa˛ cecha˛ schowka jest specjalna, rozszerzona obsługa danych w HTML’u, które sa˛
przechowywane w formacie CF_HTML. Służy on do przechowywania fragmentów dokumentów
w HTML, który oprócz żadanego
˛
przez użytkownika fragmentu zawiera jego otocznie. Aplikacja
wstawiajaca
˛ dane w tym formacie ma do dyspozycji wi˛eksza˛ ilość informacji, na przykład o formatowaniu i może sama zdecydować jak wstawić dane.
2.1.2
Operacje
Każda operacja na schowku rozpoczyna si˛e otwarciem go poprzez wywołanie OpenClipboard,
a kończy zamkni˛eciem CloseClipboard. Tylko jedna aplikacja może mieć otwarty schowek. Na
okno, które otwarło schowek wskazuje wartość zwracana przez GetOpenClipboardWindow.
7
ROZDZIAŁ 2. MECHANIZMY PROSTE
2.1. SCHOWEK (CLIPBOARD)
2.1.2.1 Kopiowanie
Po otwarciu schowka możemy zaczać
˛ z niego korzystać. Proces wstawiania rozpoczyna si˛e od
opróżnienia poprzedniej zawartości EmptyClipboard. Wywołanie funkcji powoduje wysłanie
komunikatu WM_DESTROYCLIPBOARD do poprzedniego właściciela, usuni˛ecie zawartości
schowka i przypisanie okna, które wywołało funkcj˛e jako nowego właściciela. O aktualnego
właściciela można zawsze zapytać funkcja˛ GetClipboardWindow. Nast˛epnie można już kolejno umieszczać dane w pożadanych
˛
formatach, pami˛etajac,
˛ że kolejność gra rol˛e. Dodawanie
zawartości przeprowadza si˛e funkcja˛ SetClipboardData podajac
˛ jako format identyfikator formatu i wskaźnik do danych. Można również nie podawać tego wskaźnika przy określeniu, iż
dane w tym formacie generowane sa˛ na żadanie.
˛
Wtedy dane sa˛ przygotowywane i wstawiane
do schowka dopiero gdy jakaś aplikacja chce wstawić te dane.
2.1.2.2 Wklejanie
Dost˛epność wielu formatów tych samych danych w schowku powoduje, że należy przed ich
wstawieniem wybrać najbardziej odpowiedni format. Dost˛epne formaty można uzyskać poprzez
kolejne wywołania funkcji EnumClipboardFormats, a stosowanymi metodami wyboru sa:
˛
• pierwszy rozpoznany format (dlatego kolejność wstawiania jest ważna) przy wykorzystaniu
wyżej wspomnianej funkcji
• wybranie najlepszego dost˛epnego formatu na podstawie listy priorytetowej GetPriorityClipboardFormat
• zapytanie o pojedynczy format IsClipboardFormatAvailable
Po określeniu w jakim formacie mamy zamiar uzyskać dane korzystamy z funkcji GetClipboardData podajac
˛ jako parametr identyfikator formatu. Jako rezultat otrzymujemy wskaźnik
do danych. W tym momencie należy wykonać kopie danych, tak aby w miar˛e jak najszybciej
odblokować obiekt. Okno nie b˛edace
˛ właścicielem danych nie powinno zwalniać pami˛eci zaalokowanej na obiekt.
2.1.2.3 Właściciel schowka
Jak wspominaliśmy okno po wywołaniu EmptyClipboard staje si˛e właścicielem okna i pozostaje nim dopóki innego okno nie opróżni schowka lub do zamkni˛ecia. Funkcja wysyła do
poprzedniego właściciela komunikat WM_DESTROYCLIPBOARD. O ile okno wstawiło dane
w formacie, w którym pami˛eć nie jest zwalniania automatycznie lub posiada dane generowane na
żadanie
˛
powinno obsłużyć komunikat i wykonać odpowiednie akcje - zwolnić pami˛eć zajmowana˛
przez dane powiazane
˛
ze schowkiem.
2.1.2.4 Podglad
˛ schowka
Schowek ma możliwość dołaczeniabonifikowana
˛
aplikacji podgladaj
˛ acej
˛
aktualna˛ zawartość,
która przy każdej zmianie b˛edzie o tym notyfikowana.
8
Aplikacje te tworza˛ łańcuch, wi˛ec
ROZDZIAŁ 2. MECHANIZMY PROSTE
2.2. DATA COPY
ważne jest, aby każda z nich przekazywała informacj˛e dalej. Informacj˛e o tym gdzie mamy
przekazać komunikat zwraca funkcja rejestrujaca
˛ SetClipboardViewer. Takie rozwiazanie
˛
obliguje jednocześnie aplikacje do naprawiania łańcucha podczas wyrejestrowania si˛e jednego
z elementów (funkcja˛ ChangeClipboardChain(okno_zamykane,
okno_nast˛epne)) okna
b˛edace
˛ w łańcuchu powinny przekazywać sobie komunikat WM_CHANGECBCHAIN dopóki
jedno z nich nie stwierdzi, że to jego nast˛epnik jest zamykany. W tym momencie dane okno
powinno zaktualizować informacje o własnym nast˛epniku (informacja o nast˛epniku zamykane
okna podawana jest w komunikacie).
Podobnie spraw ma si˛e w przypadku komunikatu
WM_DRAWCLIPBOARD notyfikujacym
˛
o zmian˛e zawartości.
W tym przypadku również
należy przekazać komunikat do swego nast˛epnika, wcześniej wykonujac
˛ pożadane
˛
operacje
odczytu na schowku.
2.1.2.5 Generowanie na żadanie
˛
W schowku może zostać umieszczona również informacja, że dane zostana˛ wygenerowane
na żadanie.
˛
Konieczność takiego rozwiazania
˛
może być różna:
przygotowania.
Stosujac
˛ takie rozwiazania,
˛
wielkość danych, czas
okno (dopóki nie dostanie komunikatu
WM_DESTROYCLIPBOARD) musi być gotowe przygotować i udost˛epnić dane o których
umieściło informacje w schowku. Po otrzymaniu komunikatu WM_RENDERFORMAT okno
powinno umieścić w schowku za pomoca˛ SetClipboardData dane w żadanym
˛
formacie. W
przypadku otrzymania takie komunikatu nie otwieramy schowka. W przypadku niszczenia
właściciela schowka otrzymuje on komunikat WM_RENDERALLFORMATS po którym
powinien umieścić w schowku dane w formatach, które miały być generowane na żadanie,
˛
tak
aby były dost˛epne po zamkni˛eciu okna. Jeżeli format nie został umieszczony w schowku, a
właściciel nie jest już dost˛epny to taki format nie b˛edzie widoczny dla oknien sprawdzajacych
˛
dost˛epne formaty.
2.1.2.6 Pamie˛ ć
Wszystkie dane przekazywane do schowka powinny być zapisane w pami˛eci alokowanej przy
użyciu GlobalAlloc z flaga˛ GMEM_MOVEABLE. Po umieszczeniu ich w schowku system
staje si˛e właścicielem tych obszarów pami˛eci i może je samodzielnie zwolnić przy użyciu funkcji
przewidzianej dla danego formatu. W samej dokumentacji Microsoftu pozostaja˛ jednak pewne
nieścisłości co do zarzadzania
˛
pami˛ecia.
˛ Tyczy si˛e to głównie formatów rejestrowanych: prywatnych i GDI.
2.2
Data Copy
Data Copy jest prostych mechanizmem pozwalajacym
˛
w komunikacie od okna do okna przesłać
dane. Okno umieszcza dane w strukturze COPYDATASTRUCT i wysyła je komunikatem
WM_COPYDATA. Okno odbierajace
˛ komunikat może rozpoznać typ po polu dwData. Okno
wysyłajace
˛ musi znać uchwyt do okna do którego chce wysłać komunikat.
9
ROZDZIAŁ 2. MECHANIZMY PROSTE 2.3. FILE MAPPING (PAMIE˛Ć WSPÓŁDZIELONA)
2.3 File Mapping (Pamie˛ ć współdzielona)
Windowsowy mechanizm o nazwie File Mapping jest odpowiednikiem Unixowej pami˛eci
współdzielonej. Zasada działania polega na udost˛epnieniu zawartości pliku jako bloku pami˛eci
procesu. Proces za pomoca˛ wskaźnika może czytać i zmieniać zawartość, tak jak w przypadku
zmiennych dynamicznych i tak też realizowane sa˛ te operacje. Mechanizm sam nie zwiera
synchronizacji, tak wi˛ec korzystajac
˛ w kilku procesach z tego mechanizmu należy zapewnić
synchronizacj˛e. Zależnie od nadania nazwy danemu przypisaniu dodaje si˛e określenie nazwany
/ nienazwany.
Sam mechanizm jest stosunkowo wydajny,
a ponadto zapewnia pewien poziom
bezpieczeństwa, zabezpieczajac
˛ przed uszkodzeniem danych do których proces nie powinien
mieć dost˛epu. Mechanizm działa wyłacznie
˛
lokalnie, także komunikacja poprzez sieć przy jego
użyciu nie jest możliwa.
Pamięć wirtualna
procesu A
File View 1
File View 2
Pamięć fizyczna
Pamięć wirtualna
procesu B
Obiekt
File Mapping
Plik
na dysku
File View 1
Rysunek 2.3: Zasada działania File Mapping
Powyższy rysunek przedstawia schematycznie sposób realizacji. System tworzy obiekt file
mapping, który odpowiada za połaczenie
˛
wirtualnej przestrzeni adresowej procesu z zawartościa˛
pliku, natomiast File View jest ta˛ cz˛eścia˛ pami˛eci współdzielonej procesu używanej do dost˛epu
do pliku (można nim manipulować przy użyciu funkcji VirtualProtect.
Głównymi zaletami mapowania pliku sa:
˛
• Szybszy i łatwiejszy dost˛ep do plików
• Działanie podobne do pami˛eci współdzielonej dla wielu aplikacji
10
ROZDZIAŁ 2. MECHANIZMY PROSTE 2.3. FILE MAPPING (PAMIE˛Ć WSPÓŁDZIELONA)
Te zalety kształtuja˛ zakres zastosowania mechanizmu. Szczególnie godny polecenia jest tam
gdzie konieczny jest szybki dost˛ep do plików, zarówno sekwencyjny jak i losowy - czyli n.p.
wszelkie aplikacje operujace
˛ na danych przechowywanych w plikach. Proces nie musi posiadać
widoku obejmujacego
˛
cały plik, ale także dowolnie wybrany ciagły
˛
fragment pliku. Chca˛ mieć
dost˛ep do innych danych niż aktualnie dost˛epne w File View może utworzyć nowy opcjonalnie
zwalniajac
˛ wcześniej bieżacy
˛ widok. Proces może posiadać wiele widoków. System zwolniony
obszar, do którego nie odwołuje si˛e żaden widok może zapisać do pliku i zwolnić pami˛eć, a ża˛
dany obszar pliku wczytać, o ile nie jest od dost˛epny. Przy pomocy File Mapping można uzyskać
dost˛ep do dowolnego pliku łacznie
˛
z systemowym plikiem wymiany. Obiekt systemowy zapewnia
spójność danych, także wszystkie procesy korzystajace
˛ z pliku poprzez widok wskazujacy
˛ na ten
sam obiekt posiadaja˛ te same dane.
Windows NT/2000/XP: Widoki każdego procesu należa˛ do jego przestrzeni adresowej
Windows 95/98/Me: Wszystkie widoki należa˛ do współdzielonej przestrzeni adresowej
(pomi˛edzy 2 a 3 GB wirtualnej przestrzeni adresowej, gdzie oprócz widoków jest 16-bitowy stos
jak i współdzielone systemowe biblioteki DLL).
2.3.1
Obiekt mapowania pliku
Mechanizm może udost˛epnić dowolny plik, jednym wymogiem jest, aby miał do niego wyłaczny
˛
i ciagły
˛
dost˛ep do momentu usuni˛ecia mapowania. Wybrany plik należy otworzyć przy użyciu funkcji CreateFile przy zachowaniu poprzednio wspomnianych wymagań. Otwierajac
˛ plik
należy otworzyć go z takimi samymi atrybutami dost˛epu z jakimi chce si˛e do niego mieć dost˛ep z
obiektu mapowania. W przeciwnym wypadku może wystapić
˛ bład.
˛ Otrzymany uchwyt w wyniku
działania funkcji b˛edzie parametrem przy wywołaniu CreateFileMapping.
Ważne do odnotowania jest, że tworzac
˛ obiekt mapowania nie ma konieczności ograniczania
rozmiarów dost˛epnego obszaru pliku, gdyż nie wypływa to na ilość dost˛epnych zasobów systemowych. Najlepiej wi˛ec jako parametry dwMaximumSizeHigh i dwMaximumSizeLow przy
tworzeniu obiektu podać wartość 0. Zasoby systemowe zajmowane sa˛ dopiero przy tworzeniu
widoków, ale tutaj dost˛epny obszar może być dowolnie wybrany z pliku (dowolnie wybrane bloki
danych na dysku). W przypadku gdy chcemy jednak udost˛epnić tylko fragment, należy pami˛etać,
iż specyfikujemy jedynie udost˛epniana˛ wielkość, bez offsetu, a wi˛ec musimy i tak udost˛epnić plik
od poczatku
˛
do końca żadanego
˛
fragmentu (uwzgl˛edniajac
˛ położenie na dysku i rozmieszczenie
w klastrach).
Jako parametr do funkcji CreateFileMapping podaje si˛e również nazwe˛ dla tworzonego
obiektu.
Gdy obiekt o takiej nazwie istnieje podejmowana jest próba uzyskania do niego
dost˛epu z żadan
˛
a˛ w wywołaniu ochrona˛ (Otwarcie obiektu możliwe jest również przy użyciu
OpenFileMapping, ale już na ochronie z jaka˛ został tworzony obiekt).
W przeciwnym
wypadku tworzony jest nowy obiekt. Pozostawiajac
˛ nazw˛e pusta˛ (null, a nie „“) tworzymy
nienazwany obiekt, do którego nie b˛edzie si˛e można odwołać przez nazw˛e. W przypadku
Windows XP nazwy musza˛ spełniać wytyczne dotyczace
˛ przestrzeni nazw Terminal Services.
Sama nazwa może być dowolnym ciagiem
˛
znaków poza „\“, a Windows 95/98/Me dopuszczalny
jest również ciag
˛ pusty „“. Maksymalny rozmiar pliku ograniczony jest jedynie miejscem na
11
ROZDZIAŁ 2. MECHANIZMY PROSTE
2.4. MAILSLOTS
dysku.
Zamkni˛ecie obiektu odbywa si˛e w odwrotnej kolejności do otwarcia, a wi˛ec najpierw należy
zamknać
˛ obiekt, a później plik.
2.3.2
Widoku pliku
Uzyskujac
˛ wskaźnik na obiekt mapowania po wywołaniu CreateFileMapping możemy
utworzyć widok na wybrany fragment przy wykorzystaniu funkcji MapViewOfFileEx (lub
MapViewOfFile gdy chcemy mieć widok na cały obszar dost˛epny w obiekcie) z tymi samymi
flagami co poprzedniczk˛e.
Jak już było wspomniane modyfikacja danych w widoku nie powoduje bezpośrednio zapisania
zamian na dysku, operacja ta jest obsługiwana przez system. Zapewnione jest tylko, że wszystkie
procesu maja˛ dost˛ep do tych samych danych, tak wi˛ec zmiany sa˛ widoczne od razu dla wszystkich współużytkujacych
˛
procesów. Można jednak wymusić zapis na dysk poprzez wywołanie
FlushViewOfFile.
Za pomoca˛ wskaźnika uzyskanego z wywołania funkcji MapViewOfFile* mamy dost˛ep do
wybranego obszaru pliku, identycznie jak w przypadku zmiennej dynamicznej.
Zamkni˛ecie widoku wykonuje si˛e poprzez wywołanie UnmapViewOfFile dla pojedynczego
widoku.
2.4 Mailslots
Mailslot jest mechanizmem jednokierunkowej komunikacji mi˛edzy procesami (IPC). Aplikacje
Win32 moga˛ składować dane w mailslotach.
Właściciel mailslotu może otrzymywać
wiadomość, która jest tam składowana. Wiadomości sa˛ przeważnie wysyłane poprzez sieć do
wyspecyfikowanego komputera lub wszystkich komputerów w wyspecyfikowanej domenie.
Domena jest grupa˛ stacji roboczych i serwerów, które dziela˛ nazw˛e grupowa.
˛
Zamiast
mailslotów, do komunikacji mi˛edzy procesami, można używać nazwanych potoków (named
pipes).
Nazwane potoki sa˛ prostym sposobem dla procesu dla rozgłoszenia wiadomości do
wielu procesów. Podstawowa˛ różnica˛ mi˛edzy nimi jest to, że mailsloty używaja˛ datagramów a
nazwane potoki nie. Datagram jest małym pakietem informacji, który jest przesyłany poprzez
sieć. Podobnie jak radio czy telewizja, dla datagramów nie sa˛ przesyłane potwierdzenia odbioru;
nie ma gwarancji, że datagram doszedł na swoje miejsce. Tak jak góry, duże budynki, lub
interferencja sygnału może spowodować strat˛e sygnału radiowego lub telewizyjnego, tak
istnieja˛ rzeczy, które moga˛ przeszkodzić w dotarciu datagramu do odbiorcy. Nazwane potoki sa˛
jak rozmowa telefoniczna. Rozmawiasz tylko w jedna˛ stron˛e jednak wiesz, że konwersacja jest
prowadzona.
Kiedy wiadomość jest wysyłana do mailslotu, aplikacja wysyłajaca
˛ specyfikuje czy wiadomość
ma być wysłana przy użyciu pierwszej klasy czy drugiej klasy.
• Pierwsza klasa jest zorientowana połaczeniowo
˛
i gwarantuje transfer danych dla
połaczenia
˛
jeden-do-jeden, lub jeden-do-wielu. Wiadomości tej klasy moga˛ być wysłane do
12
ROZDZIAŁ 2. MECHANIZMY PROSTE
2.5. POTOKI (PIPES)
mailslotu, który został stworzony na serwerze. (a tak nawiasem piszac
˛ Windows 95 nie
używa wiadomości pierwszej klasy).
• Druga klasa jest oparta na datagramach i niegwarantowanym transferze danych dla
połaczenia
˛
jeden-do-jeden, lub jeden-do-wielu. Wiadomości tej klasy moga˛ być przesyłane
do mailslotów, które zostały utworzone na dowolnej stacji roboczej lub na kilku stacjach
roboczych jeżeli rozmiar wiadomości nie przekracza 400 bajtów.
Windows 95/NT implementuje tylko mailsloty drugiej klasy, które sa˛ najbardziej użyteczne do
identyfikowania innych komputerów lub serwisów w sieci i do szerokiej identyfikacji serwisów.
Windows 95 używa mailslotów dla wiadomości WinPopup.
Implementacja mailslotów w Windows NT jest podzbiorem implementacji OS/2 LAN
Manager. Mailsloty drugiej klasy dostarczaja˛ bezpołaczeniowego
˛
przesyłania wiadomości
dla rozgłoszeniowych wiadomości. Dostarczenie wiadomości nie jest zagwarantowane, jednak
współczynnik dostarczonych wiadomości w wi˛ekszości sieci jest duży. Jest to bardzo użyteczne
dla identyfikacji innych komputerów lub serwisów w sieci. Serwis Computer Browser w Windowsach NT używa mailslotów.
Nazwy mailslotów musza˛ posiadać nast˛epujace
˛ elementy: dwa backslashe na poczatku
nazwy, kropk˛e, backslash po kropce, nazw˛e mailslot, nast˛epnie wystepuje nazwa mailslotu.
Przykad:
\\.\mailslot\[path]name
Aby umieścić wiadomość w mailslocie prces otwiera mailslota porzez jego nazw˛e. Zapisywanie wiadomości na lokalnym komputerze zdarza si˛e rzadko. Cz˛eściej używamy mailslotów na
innych kompuaterach, do których adres jest w postaci:
\\ComputerName\mailslot\[path]name
Aby umieścić wiadomość w każdym mailslocie w domenie z podana˛ nazwa,
˛ stosujemy
nast˛epujac
˛ a˛ form˛e:
\\DomainName\mailslot\[path]name
2.5
Potoki (Pipes)
Nazwane potoki i mailsloty sa˛ aktualnie zaimplementowane jako systemy plików. W ten sposób,
w Rejestrze sa˛ wejścia dla NPFS (Named Pipe File System) i MSFS (Mailslot File System).
Jako systemy plików, dziela˛ one podstawowa˛ funkcjonalność, taka˛ jak bezpieczeństwo, z innymi
systemami plików. Dodatkowo lokalne procesy moga˛ używać nazwanych potoków i mailslotów
z innymi procesami na lokalnym komputerze bez używania komponentów sieciowych. Zdalny
dost˛ep do nazwanych potoków i mailslotów jest osiagalny
˛
przez przekierowanie.
Nazwane
potoki
dostarczaja˛ połaczeniowo-zorientowane
˛
przekazywanie
wiadomości,
które pozwalaja˛ na dzielenie pami˛eci poprzez sieć. Windows NT posiada specjalny interfejs
programowania (API), który zwi˛eksza bezpieczeństwo przy używaniu nazwanych potoków.
13
ROZDZIAŁ 2. MECHANIZMY PROSTE
2.5. POTOKI (PIPES)
Jedna˛ cecha˛ dodana˛ do potoków jest impersonation (personifikacja). Kiedy używamy personifikacji, serwer może zmienić swój identyfikator bezpieczeństwa na taki jaki posiada klient na
drugim końcu połaczenia.
˛
Dla przykładu przypuśćmy, że serwer bazodanowy używa nazwanych
potoków do otrzymywania, czytania i zapisywania żada
˛ ń od klienta. Kiedy żadanie
˛
przychodzi,
serwer może personifikować klienta zanim podj˛eta zostanie próba spełnienia żadania.
˛
Dlatego
też, jeżeli klient nie ma autoryzacji do wykonania zadania, żadanie
˛
zostanie odrzucone.
2.5.1 Named Pipes
Pipe jest sekcja˛ dzielonej pami˛eci, której proces używa do komunikacji.
Nazwane potoki dostarczaja˛ łatwe w dost˛epie połaczenie
˛
jeden-do-jeden, wydajność i zorientowany połaczeniowo
˛
transfer danych mi˛edzy dwoma procesami.
Potok nazwany może być tworzony mi˛edzy procesami niezwiazanymi
˛
z soba,
˛ a także może
przekazywać informacj˛e poprzez sieć.
Proces, który tworzy potok nazywany jest pipe server. Proces, który łaczy
˛
si˛e z potokiem jest
nazywany pipe client. Gdy jeden proces wpisuje informacje do potoku, drugi proces odczytuje
stamtad
˛ informacj˛e.
Proces serwera tworzy potok i zarzadza
˛
dost˛epem do niego. Zasoby, które tworza˛ potok sa˛
własnościa˛ procesu serwera i istnieja˛ fizycznie na stacji roboczej, na której uruchomiony został
proces.
Proces klienta używa protokołów sieciowych aby uzyskać dost˛ep do zdalnego zasobu potoku.
Mimo że, potoki sa˛ zazwyczaj używane dwukierunkowo, potok może być skonfigurowany tak
aby pozwalał na komunikacj˛e w jednym kierunku, na przykład od serwera do klienta.
Powszechnym zastosowaniem nazwanych potoków jest aplikacja klient-serwer bazujaca
˛ na
SQL. Klient aplikacji SQL może być uruchomiony na komputerze i połaczony
˛
z aplikacja˛ serwera
poprzez sieć Microsoft. Microsoft SQL Server musi być jednakże postawiony na LAN Manager,
Windows NT, lub innym serwerze nazwanych potoków.
2.5.1.1
Nazwa potoku
Każdy nazwany potok musi posiadać swoja˛ unikalna˛ nazw˛e, która rozróżnia go od innych potoków. Nazwa potoku ustalana jest podczas tworzenia potoku przy pomocy funkcji CreateNamedPipe. Nazwa potoku otwieranego przez klienta ma nast˛epujac
˛ a˛ form˛e:
\\ServerName\pipe\PipeName
gdzie ServerName jest nazwa˛ zdalnego lub lokalnego komputera. String wyspecyfikowany
przez PipeName może zawierać dowolny znak, włacznie
˛
z cyframi i znakami specjalnymi.
Serwer potoku nie może tworzyć potoku na innym komputerze wi˛ec nazwa tworzonego potoku
zawiera kropk˛e zamiast nazwy serwera.
\\.\pipe\PipeName
14
ROZDZIAŁ 2. MECHANIZMY PROSTE
2.6. NETBIOS
2.5.1.2 Synchronizacja
Funkcje ReadFile, WriteFile, TransactNamedPipe i ConnectNamedPipe moga˛ być
wywoływane synchronicznie lub asynchronicznie.
Kiedy jest uruchamiana synchronicznie
sterowanie jest zwracane gdy operacja przez nia˛ wykonywana jest skończona. Oznacza to, że
watek
˛
wywołujacy
˛ funkcj˛e zostanie wstrzymany na czas jej wykonania. Może być to kłopotliwe
gdy operacja zajmuje dużo czasu. Kiedy funkacja wywoływana jest asynchronicznie, sterowanie
zwracane jest natychmiast, nawet wtedy gdy operacja nie została wykonana do końca.
Serwera potoku, który obsługuje synchroniczne operacje do komunikowania si˛e z kilkoma
klientami, musi stworzyć osobny watek dla każdego klienta, tak aby jeden lub wi˛ecej watków
˛
mogły działać gdy inne czekaja.
˛
2.5.2
Anonymous Pipes
Potoki anonimowe, zwane również potokami nienazwanymi, umożliwiaja˛ zwiazanym
˛
procesom
na wymian˛e informacji przez wpisywanie i odczytywanie z pliku. Typowo anonimowe potoki sa˛
używane do przekierowania standardowego wejścia i wyjścia procesu potomka, dlatego też może
wymienić dane z procesem rodzica.
Do używania anonimowych potoków, proces rodzica typowo tworzy potok, a później pozwala
na dziedziczenie uchwytów do niego przez potomka. Proces rodzica wpisuje dane do potoku, a
proces potomny może je odczytać z drugiej strony potoku. Proces rodzica może stworzyć dwóch
lub wi˛eksza˛ ilość potomków, które dziedzicza˛ uchwyty zapisu i odczytu do anonimowego potoku.
Procesy te moga˛ używać potoków do komunikowania si˛e mi˛edzy soba,
˛ bez przechodzenia przez
proces rodzica.
Anonimowe potoki nie moga˛ być używane poprzez sieć, ani nie moga˛ być używane mi˛edzy
niezwiazanymi
˛
procesami.
2.6 NetBIOS
NetBIOS (Network Basic Input/Output System) jest standardowym interfejsem programowania
w środowisku PC dla tworzenia aplikacji klient-serwer. NetBIOS jest używany jako mechanizm IPC od wprowadzenia tego interfejsu we wczesnych latach 80’tych. Z programistycznego
punktu widzenia, interfejsy wyższego poziomu, takie jak potoki nazwane i RPC, sa˛ lepsze w swojej elastyczności i przenośności. Aplikacja klient-serwer używajaca
˛ NetBIOS może komunikować
si˛e poprzez różne protokoły: NetBEUI (NBF), NWLink NetBIOS (NWNBLink) i NetBIOS over
TCP/IP (NetBT).
Interfejs NetBIOS dostarcza komendy i wsparcie dla nast˛epujacych
˛
serwisów:
• Rejestracja i weryfikacja nazwy sieciowej
• Ustanawianie i zrywanie sesji
• Niezawodność przesyłania danych
15
ROZDZIAŁ 2. MECHANIZMY PROSTE
2.6. NETBIOS
• Monitorowanie i zarzadzanie
˛
protokołem i adapterem
Interfejs NetBIOS wystawia wyraźny zbiór komend, które sa˛ przesyłane przez struktur˛e znana˛
jako network control block (NCB). Aplikacja może wysyłać komendy NetBIOS ponad dowolnym protokołem, który dostarcza odpowiedni interfejs.
16
Rozdział 3
Mechanizmy rozbudowane
3.1 COM (COM+)
Component Object Model jest szkieletem dla integrowalnych ze soba˛ komponentów.
Komponenty moga˛ być łaczone
˛
w wi˛eksze systemy, komunikujac
˛ si˛e wzajemnie poprzez COM.
Wzajemne wykorzystanie komponentów napisanych w różnych j˛ezykach możliwe jest dzi˛eki
standardowemu API oraz zgodności binarnej. Kolejnym etapem rozwoju technologii było
rozszerzenie go o możliwość używania komponentów, wzajemnej ich komunikacji, w środowisku
rozproszonym - Distributed Component Object Model (w skrócie DCOM). DCOM i
COM najlepiej traktować wspólnie, gdyż i tak dostarczane sa˛ w jednym wspólnym pakiecie
umożliwiajacym
˛
prac˛e w środowisku lokalnym jak i sieciowym.
Ponad *COM, które znajduja˛ si˛e w niskich warstwach i wspieraja˛ wzajemna˛ interakcj˛e
mi˛edzy komponentami, stworzone zostały technologie służace
˛ do osadzania obiektu w obiekcie
(ActiveX, OLE) i tworzenia połacze
˛ ń (OLE). Dzi˛eki MTS rozszerzono możliwości COM
o serwisy enterprise’owe, czyli przykładowo transakcyjność i bezpieczeństwo.
Późniejsze
zintegrowanie MTS z COM’em w COM+ oraz uproszczenie wykorzystania mechanizmów
dla programisty pozwoliło na lepsza˛ integracj˛e mechanizmu w wizualnych środowiskach
programistycznych Microsoftu.
3.1.1
COM od podszewki
Jak wspominaliśmy na komponentach COM wymuszona jest binarna zgodność, niezależnie
od wykorzystywanego j˛ezyka programowania.
Dzi˛eki takiemu rozwiazaniu
˛
uzyskujemy
niezależność od j˛ezyka programowania i uniwersalność komponentu. Komponent jest widoczny
jako zbiór interfejsów, posiadajacych
˛
własne zestawy dost˛epnych metod, reprezentujacych
˛
punkty kontaktu pomi˛edzy klientem a obiektem. Interfejsy, w celu zachowania zgodności, nie
powinny si˛e zmieniać. Tzn. chcac
˛ rozszerzyć możliwości obiektu należy nowe metody udost˛epnić
za pomoca˛ nowego interfejsu (można utworzyć interfejs dziedziczy po poprzedniej wersji).
Dzi˛eki temu możemy swobodnie zmieniać i korzystać z komponentów oferujacych
˛
interesujace
˛
nas w konkretnym przypadku interfejsy, oferujacych
˛
czasami różne inne możliwości, akurat
przez nas nie wykorzystywane.
17
ROZDZIAŁ 3. MECHANIZMY ROZBUDOWANE
Aplikacja
kliencka
3.1. COM (COM+)
Obiekt
Wskaźnik
na interfejs
Rysunek 3.1: Użycie obiektu COM przez wskaźnik na interfejs
Obiekty COM jak i interfejsy opisywane sa˛ przy użyciu Microsoft Interface Definition
Language (IDL), b˛edacego
˛
rozszerzeniem DCE IDL (Distributed Computing Environment), a
identyfikator każdego z nich musi być unikalny.
Każdy obiekt COM działa wewnatrz
˛
serwera.
Pojedynczy serwer może obsługiwać
jednocześnie wiele obiektów. Dost˛ep do każdego z obiektów zapewniony jest na trzy sposoby:
1. Serwer wewnatrz
˛
procesu: Klient łaczy
˛
si˛e bezpośrednio z biblioteka˛ zawierajac
˛ a˛ serwer.
Klient i serwer znajduja˛ si˛e w tym samym procesie.
Komunikacja zachodzi poprzez
wywołanie funkcji.
2. Proxy lokalnego obiektu: Klient łaczy
˛
si˛e z serwerem działajacym
˛
w innym procesie, ale na
tym samym komputerze poprzez mechanizmy IPC (obecnie LRPC).
3. Proxy zdalnego obiektu: Klient łaczy
˛
si˛e z serwerem działajacym
˛
na zdalnym komputerze.
Taki sposób połaczenia
˛
został wprowadzony przez DCOM, a do komunikacji wykorzystywany jest DCE RPC.
Proces Lokalnego Serwera
Proces klienta
Obiekt
procesu
stub
Serwer
lokalny
Aplikacja
kliencka
Proxy
obiektu
lokalnego
COM
Serwer
lokalny
LRPC
Proces Zdalnego Serwera
COM
Proxy
obiektu
zdalnego
Obiekt
loklany
stub
RPC
COM
Zdalny host
Rysunek 3.2: Metody dost˛epu do obiektu COM
18
Obiekt
zdalny
Serwer
zdalny
ROZDZIAŁ 3. MECHANIZMY ROZBUDOWANE
3.1. COM (COM+)
O ile pierwszy sposób jest stosunkowo łatwy do realizacji, to dwa nast˛epne wymagaja˛ już
wi˛ekszego nakładu. Dane musza˛ zostać dodatkowo sformatowane i połaczone
˛
w odpowiednim
porzadku
˛
aby można było je współdzielić (proces ten nazywany jest z angielska mashaling’iem).
Cały proces realizowany jest poprzez proxy po stronie klienta i stub po stronie serwera dla
każdego pojedynczego interfejsu danego komponentu. Podczas nawiazywanie
˛
połaczenia
˛
najpierw tworzony jest stub, który b˛edzie udost˛epniał i zarzadzał
˛
prawdziwym wskaźnikiem na
interfejs. Nast˛epnie tworzone jest proxy po stronie klienta, które łaczy
˛
si˛e ze stub i udost˛epnia
klientowi wskaźnik do interfejsu. Podczas połaczenia
˛
klient wysyła dane do proxy, tutaj sa˛ one
poddawane marshalingowi, dalej przesyłane sa˛ do stub, który dokonuje procesu odwrotnego i
wykonuje operacje na interfejsie obiektu. Wynik zwracany jest w identyczny sposób, przy czym
stub teraz porzadkuje
˛
i łaczy
˛
dane, a proxy je konwertuje do postaci wymaganej przez klienta.
Ważna˛ cecha˛ COM jest nierozróżnialność obiektów. Możemy wi˛ec prosić o dost˛ep do
obiektu konkretnego typu bez możliwości wskazania konkretnej jego instancji. W przypadku,
gdy istnieje jednak konieczność zachowania stanu i odwołania do tego samego obiektu możemy
użyć monikerów (monikers). Istnieje także możliwość powiadamiania klienta o zmianach w
używanym przez niego komponencie lub zdarzeniach. Obiekty COM maja˛ również możliwość
przechowywania swojego stanu.
3.1.1.1
Kompatybilność binarna
Wspominaliśmy, że dla komponentów COM wymagana jest kompatybilność binarna, która jest
warunkiem koniecznym dla niezależności od j˛ezyka programowania. Pod poj˛eciem kompatybilność binarna rozumie si˛e ustandaryzowana˛ postać wirtualnych tablic funkcji (vtables) w
pami˛eci. Klient chcac
˛ wykonać metod˛e obiektu COM wykorzystuje wskaźnik do wpisu w wirtualnej tablicy funkcji. Dodatkowo daje to możliwość zredukowania liczby instancji obiektu COM,
gdyż dzi˛eki takiemu rozwiazaniu
˛
może być współdzielony.
3.1.2
Dostepnoś
˛
ć
Wraz z rozwojem technologii COM Microsoft udost˛epniał nowe wersje bibliotek na swoje systemy
operacyjne. Implementacje COM sa˛ również dost˛epne na cz˛eść Unix’ów. Same biblioteki można
było wi˛ec dołaczyć
˛
do swojego systemu i uzbroić go w możliwość wykorzystania komponentów
COM. Stopniowo jednak coraz to nowsze wersje przestały być dost˛epne na starszych wersjach
Windowsów. Na dzień dzisiejszy najnowsza wersja COM+ 1.5 dost˛epna jest jedynie z Windows
XP i Windows .NET Serwer i nie b˛edzie dost˛epna nawet dla Windows 2000.
COM w obecnej formie jest tak bardzo rozbudowany i posiada wiele różnorakich aspektów
wykorzystania, iż samo ich poznanie zajmuje dużo czasu, a o każdym z nich można
swobodnie napisać ksiażk˛
˛ e. Sama technologia zwiazana
˛
jest raczej z komponentowa˛ technika˛
programowania aniżeli IPC, aczkolwiek jest swoistym przejawem komunikacji mi˛edzy
procesami. Jak wspominaliśmy do komunikacji na niskim poziomie wykorzystywane jest RPC,
które opiszemy w dalszej cz˛eści.
19
ROZDZIAŁ 3. MECHANIZMY ROZBUDOWANE
3.1.3
3.1. COM (COM+)
Object Linking and Embedding (OLE)
Korzystanie ze schowka posiada jeden podstawowy mankament. Jeżeli wklejane dane nie sa˛
w standardowym formacie, nie można edytować danych, które zostały wklejone do programu
odbierajacego.
˛
Aby przezwyci˛eżyć te trudności zwiazane
˛
z przekazywaniem danych mi˛edzy programami stworzona została metoda osadzania i łaczenia
˛
obiektów OLE.
Program odbierajacy
˛ nie musi rozumieć danych, ponieważ za wyświetlanie i edytowanie
danych odpowiedzialny jest program źródłowy i mechanizm OLE. Kiedy użytkownik edytuje
dane, automatycznie uruchamia si˛e program źródłowy, który udost˛epnia swoje polecenia
edycji. Dzi˛eki metodzie OLE program może przesyłać dane w dowolnym formacie do każdego
programu, który jest zdolny odbierać dane OLE. Aby edytować dane w programie odbierajacym,
˛
użytkownik nie musi uruchamiać r˛ecznie programu źródłowego.
Technologia OLE jest w rzeczywistości kolekcja˛ wyższego poziomu technologii, które bazuja˛
na infrastrukturze COM. Poniższy rysunek przedstawia zależność mi˛edzy COM i OLE.
Rysunek 3.3: COM i OLE
• In-Place Activation (Visual Editing): Możliwość edytowania danych pochodzacych
˛
z in20
ROZDZIAŁ 3. MECHANIZMY ROZBUDOWANE
3.2. DDE (DDEML)
nej aplikacji. Interfejs aplikacji kontenera zmienia si˛e tak aby można było zmieniać własności dołaczonych
˛
danych.
• Linking and Embedding: Sa˛ to dwie metody dla składowania elementów, które zostały
stworzony w innej aplikacji, wewnatrz
˛
dokumentu OLE. Linkowanie polega na tym, że
wstawiane dane pochodza˛ z pliku, do którego posiadamy ścieżk˛e. Zmiany w pliku oryginalnym zostana˛ uwidocznione w aplikacji kontenera. Osadzanie polega na dołaczeniu
˛
danych
z aplikacji źródłowej do pliku aplikacji docelowej. Zmiany nie sa˛ odzwierciedlane.
• Drag & Drop: Możliwość wymiany danych przez chwycenie zaznaczonych danych I
puszczenie ich do innego okna.
• Automation: Zdolność tworzenia programowalnych aplikacji, które moga˛ być sterowane
zewn˛etrznie ze skryptu uruchomionego w innej aplikacji do zautomatyzowania
zadań końcowego użytkownika.
Automatyzacja umożliwia programowanie makr
mi˛edzy-programowych.
• Compound Documents: Zdolność do osadzenia lub linkowania informacji w centralnym
dokumencie. Umożliwia to posiadanie w dokumencie danych pochodzacych
˛
z innych aplikacji.
• Component Object Model and Component Objects: Zorientowany obiektowo model
programowania odpowiedni dla tworzenia oproramowania możliwego do powtórnego użycia.
• Monikers:
Abstrakcyjne odwołanie do obiektu.
Wyst˛epuje jako nazwa, która
jednoznacznie identyfikuje obiekt COM. W taki sam sposób jak ścieżka identyfikuje plik w
systemie plików, moniker identyfikuje obiekt COM w katalogu przestrzeni nazw.
• Uniform Data Transfer: pot˛eżny mechanizm transportu danych poprzez schowek,
drag&drop, lub automatyzacj˛e. Obiekty dostosowujace
˛ si˛e do tego modelu implemetuja˛
interfejs IdataObject.
• Compound Files:
standardowa implementacja structured storage (przechowywanie
różnych typów obiektów w jednym dokumencie).
3.2 DDE (DDEML)
Dynamic Data Exchange jest jednym z mechanizmów przekazywania danych mi˛edzy aplikacjami. Cały protokół składa si˛e z zestawu komunikatów i wytycznych, a jego realizacja sprowadza
si˛e do użycia pami˛eci współdzielonej i wymiany komunikatów mi˛edzy aplikacjami współdziela˛
cymi dane. Sam mechanizm może być wykorzystany do jednokrotnej wymiany danych, jak i
bieżacej
˛ ich aktualizacji, a użytkownik jedynie inicjalizuje sama˛ wymian˛e, nie biorac
˛ udziału w
późniejszych aktualizacjach. W systemach Windows dost˛epna jest również biblioteka Dynamic
Data Exchange Management Library (DDEML) wspomagajaca
˛ i ułatwiajaca
˛ wykorzystanie
21
ROZDZIAŁ 3. MECHANIZMY ROZBUDOWANE
3.2. DDE (DDEML)
DDE we własnych aplikacjach. Obecnie zaleca si˛e korzystanie z DDEML, aniżeli DDE. Zachowana jest pełna kompatybilność wstecz, tzn. b˛edzie mogli komunikować si˛e ze wszystkimi
aplikacjami używajacymi
˛
DDE, a ponadto mamy pewność, że nasza implementacja DDE jest w
pełni poprawna.
3.2.1
Ogólnie o DDE
Jak wspomnieliśmy DDE jest zestawem komunikatów i wytycznych dotyczacych
˛
ich użycia. Systemy operacyjne rodziny Windows posiadaja˛ architektur˛e oparta˛ na komunikatach przesyłanych
pomi˛edzy oknami. Każdy komunikat składa si˛e z dwóch parametrów, w których należy zmieścić wszystkie potrzebne informacje. DDE specyfikuje właśnie sposób przekazywania informacji
przez te parametry. Cała wymiana informacji sprowadza si˛e konwersacji mi˛edzy klientem a serwerem. Każda aplikacja może być zarówno klientem jak i serwerem, jedynie należy wziaść
˛ pod
uwag˛e, że dane okno powinno uczestniczyć tylko w jednej konwersacji. Czyli chcac
˛ aby aplikacja
uczestniczyła w kilku należy dla każdej z nich stworzyć osobne okno, n.p. poprzez stworzenie
dodatkowego, ukrytego okna, które b˛edzie obsługiwać DDE. Dane przekazywane pomi˛edzy oknami identyfikowane sa˛ za pomoca˛ nazwy aplikacji, tematu i pozycji. Pierwsza z nich oznacza
nazw˛e aplikacji, która udost˛epnia dane, temat zaś może być nazwa˛ pliku z którego b˛eda˛ udost˛epniane dane lub inna˛ dowolna˛ nazwa.
˛ Nazwa aplikacji i tematu nie może być zmieniona podczas
konwersacji mi˛edzy klientem a serwerem. Dane przekazywane sa˛ przy użyciu dowolnego formatu, podobnie jak w przypadku schowka. Dodatkowo rejestrowany jest format Link identyfikujacy
˛ pozycj˛e w konwersacji. Każda aplikacja powinna również udost˛epniać temat System, w
którym moga˛ znaleźć si˛e ogólne informacje przydatne innym aplikacjom takie jak lista dost˛epnych formatów, pomoc, lista pozycji tematu, lista tematów aktualnie dost˛epnych. Kiedy już nawiażemy
˛
konwersacj˛e z serwerem, klient może utworzyć stałe połaczenie
˛
do danych. Tworzac
˛ takie
połaczenie
˛
może wybrać pomi˛edzy samym notyfikowaniem o zmianach ciepłe lub notyfikowaniu
i przesyłaniu zmienionych danych - gorace.
˛
3.2.2
DDEML
Korzystanie z DDE wymaga od programisty implementacji protokołu polegajacej
˛ na odpowiedniej obsłudze komunikatów i reakcji na nie. Łatwo wi˛ec popełnić bład
˛ powodujacy
˛ nie możność
współpracy z innymi aplikacjami. Stosujac
˛ DDEML uzyskujemy dost˛ep do stringów i danych
współdzielonych, a nie uchwytów stringów i uchwytów danych. Możemy również za pomoca˛
DdeNameService zarejestrować nazwy serwisów, które udost˛epnia dana aplikacja (Informacja
to zostanie przekazana wszystkim klientom, którzy odbieraja˛ tego typu komunikaty). DDEML
stanowi wi˛ec pośrednia˛ warstw˛e pomi˛edzy DDE , a aplikacja.
˛
3.2.2.1
Inicjalizacja
Aby móc skorzystać z DDEML konieczne jest dołaczenie
˛
do plików źródłowych nagłówka
DDEML.H oraz zalinkowania przy kompilacji biblioteki USER32.LIB.Dodatkowo w systemie
powinna być dost˛epna bibliotek dynamiczna DDEML.DLL. Przed rozpocz˛eciem korzystanie
22
ROZDZIAŁ 3. MECHANIZMY ROZBUDOWANE
3.2. DDE (DDEML)
z DDE należy wywołać funkcj˛e DdeInitialize podajac
˛ jako parametry wskaźnik do funkcji
zwrotnej i filtry komunikatów. W rezultacie funkcja zwróci identyfikator instancji, który b˛edzie
przekazywany do innych funkcji. Filtry komunikatów moga˛ zostać zmienione później, należy
jedynie przekazać podczas wywołania uzyskany wcześniej identyfikator instancji.
Użycie
DDEML jest ściśle zwiazane
˛
z watkiem
˛
z którego wywoływana jest funkcja inicjalizujaca.
˛
Zwrócony identyfikator może być używany tylko w tym samym watku,
˛
w innych operacja
zakończy si˛e niepowodzeniem - każdy watek
˛
musi sam zainicjalizować wykorzystanie DDEML.
Zakończenie wszystkich konwersacji i zwolnienie zasobów nast˛epuje przy użyciu DdeUninitialize.
Elementem połaczonym
˛
z inicjalizacja˛ jest również rejestracja / odrejestrowanie serwisu
przy użyciu DdeNameService. Operacje te powinny mieć miejsce zaraz po inicjalizacji lub
bezpośrednio przed zwolnieniem zasobów.
3.2.2.2 Funkcja zwrotna DdeCallback
Inicjalizujac
˛ DDEML przekazujemy wskaźnik na funkcj˛e, która b˛edzie obsługiwać wszystkie
zgłoszenia. Musi być ona zgodna z definicja˛ funkcji DdeCallback. Funkcja ta jest wywoływana
dla każdego komunikatu, który nie został zablokowany w DdeInitialize i zależnie od typu komunikatu przekazywane sa˛ w odpowiednich parametrach informacje niesione z komunikatem.
W funkcji tej powinny pojawić si˛e bloki obsługujace
˛ wszystkie typy komunikatów jakie może
odebrać aplikacja. DDEML zwalnia użytkownika od obierania i nadawania komunikatów, musi
jednak zaimplementować całe przetwarzanie danych nadchodzacych
˛
z komunikatami.
3.2.2.3
Wykorzystanie stringów
Korzystajac
˛ z funkcji DDEML nie korzystamy bezpośrednio ze stringów, ale ze uchwytów do
stringów. W systemach Windows sa˛ to tzw. atomy. Do zarzadzania
˛
nimi służa˛ funkcje:
• DddCreateStringHandle - tworzaca
˛ uchwyt do wskazanego stringu dla danej instancji
poprzez wstawienie wpisu do tablicy, o ile nie istnieje i zwi˛ekszenie liczby użyć,
• DdeCmpStringHandles
-
porównuje
stringi
wskazywane
przez
uchwyty
(raczej
sprawdzanie równości),
• DdeFreeStringHandle - zmniejsza liczb˛e użyć, jeżeli wyniesie zero zwalnia,
• DdeKeepStringHandle - zwi˛eksza liczb˛e użyć string’a.
3.2.2.4 Nawiazywanie
˛
połaczenia
˛
- konwersacje
DDEML dopuszcza pojedyncze i wielekrotne konwersacje. Pierwsza nawiazuje
˛
połaczenie
˛
z jednym serwerem wyspecyfikowanym poprzez nazw˛e serwisu i tematu przekazana˛ do funkcji DdeConnect. Po stronie serwera odbierany jest komunikat i zależnie od ustawionych flag przekazywany jest do do funkcji zwrotnej. O ile dany temat istnieje zwracamy wartość true. Możliwie
23
ROZDZIAŁ 3. MECHANIZMY ROZBUDOWANE
3.3. RPC
jest również wykonanie zapytania specyfikujac
˛ jedynie serwis lub usług˛e lub podajac
˛ za obydwa parametry null. W takim przypadku DDEML rozsyła do wszystkich zarejestrowanych i
spełniajacych
˛
warunek serwisów komunikat o wylistowanie wszystkich tematów spełniajacych
˛
warunek. Po zebraniu odpowiedzi od serwisów, wybiera jednego i z nim nawiazuje
˛
połaczenie
˛
przekazujac
˛ go klientowi inicjujacemu
˛
połaczenie.
˛
Podobnie jest w przypadku wielokrotnych konwersacji. Zasady sa˛ podobne przy czym korzystamy w tym wypadku z funkcji DdeConnectList, a lista serwisów przekazywana jest bezpośrednio do klienta. Aby sfinalizować połaczenia
˛
z serwerami należy użyć połaczenia
˛
funkcji DdeQueryNextServer i DdeQueryConvInf pozyskujac
˛ w ten sposób identyfikatory serwisów i
tematów, a później zapisujac
˛ je jako uchwyty stringów DdeKeepStringHandle.
Zamykanie połacze
˛ ń odbywa si˛e poprzez wywołania odpowiednich funkcji podajac
˛ jako
parametr uchwyty otrzymane przy połaczeniu.
˛
3.2.2.5 Zarzadzanie
˛
danymi
Podczas komunikacji mi˛edzy klientem a serwerem nie sa˛ przekazywane dane, a jedynie
uchwyty do nich.
Strona udost˛epniajaca
˛ dane tworzy lokalny bufor z nimi, a nast˛epnie
przekazuje go do funkcji DdeCreateDataHandle, która to kopiuje dane do obiektu DDE i
zwraca do niego uchwyt. Klient po otrzymaniu uchwytu (w funkcji DdeCallback) może dane
odczytać poprzez przekazanie otrzymanego uchwytu do DdeAccessData. Zwrócony wskaźnik
pozwala tylko na odczyt danych z obiektu DDE. Po dokonaniu odczytu konieczne jest zwolnienie
wskaźnika poprzez wywołanie DdeUnaccessData. Innym sposobem na dost˛ep jest stworzenie
lokalnej kopii obiektu funkcja˛ DdeGetData.
Aplikacja
tworzaca
˛
uchwyty,
które
stworzone
zostały
jako
własne
(flaga
HDATA_APPOWNED) lub nie przekazane do DDEML musi zwolnić je przed swoim
zakończeniem poprzez wywołanie na nich DdeFreeDataHandle.
Pozostałe uchwyty sa˛
automatycznie zwalniane.
Aplikacja może również zmieniać zawartość obiektu DDE stworzonego przez siebie dopóki
nie przekaże go dalej. Funkcja DdeAddData pozwala na wypełnienie obiektu danymi lub tylko
dodanie. Obiekt, który został przekazany do DDEML nie może być modyfikowany, można go
jedynie zwolnić.
3.2.2.6 Transakcje
Transakcje w DDEML sa˛ odzwierciedleniem komunikatów DDE, jednakże wiele aspektów protokołu jest już poza zakresem implementacji. Programista musi zaimplementować jedynie w
funkcji zwrotnej obsług˛e odpowiednich trybów transakcji do których zobowiazał
˛
si˛e podczas inicjalizacji DDEML. Pełen wykaz transakcji zamieszczony jest w tabeli 3.1.
3.3 RPC
Zdalne wywoływanie procedur (RPC) zostało zapoczatkowane
˛
przez firm˛e Sun Microsystems.
Prac˛e nad ta˛ technologia˛ były kontynuowane przez Open Software Foundation (OSF) jako cz˛eść
24
ROZDZIAŁ 3. MECHANIZMY ROZBUDOWANE
Typ transakcji
XTYP_ADVDATA
XTYP_ADVREQ
XTYP_ADVSTART
XTYP_ADVSTOP
XTYP_CONNECT
XTYP_CONNECT_CONFIRM
XTYP_DISCONNECT
XTYP_ERROR
XTYP_EXECUTE
XTYP_MONITOR
XTYP_POKE
XTYP_REGISTER
XTYP_REQUEST
XTYP_UNREGISTER
XTYP_WILDCONNECT
XTYP_XACT_COMPLETE
3.3. RPC
Odbiorca Opis
klient
Odpowiedź serwera na XTYP_ADVREQ z
uchwytem do danych
serwer
Serwer wywowłał DdePostAdvise - dane
pozycji zostały zmienione, klient prosi o
zmienione dane
serwer
Wywołanie DdeClientTransaction typu
XTYP_ADVSTART, klient przesyła żadanie
informowania o zmianach wraz ze specyfikacja˛ pozycji, formatu danych i sposobu
informowania
serwer
Wywołanie DdeClientTransaction typu
XTYP_ADVSTOP - anulowanie powiadamiania
serwer
Klient wywołał DdeConnect z wyspecyfikowanym serwisem i tematem obsługiwanym przez serwer
klient
Serwer odpowiedział true na połaczenie
˛
klient / Jedna ze stron wywołała DdeDisconnect
serwer
klient / Bład
˛ DDEML, operacja nie może być kontynserwer
uowana
serwer
Wywołanie DdeClientTransaction typu
XTYP_EXECUTE, umożliwia przesłanie
serwerowi ciagu
˛ poleceń do wykonania
aplikacja Wystapiło
˛
nowe zdarzenie DDE
monitroujaca
˛
DDE
serwer
Wywołanie DdeClientTransaction typu
XTYP_POKE wraz z danymi przekazanymi
do serwera od klienta
klient / Aplikacja zarejestrowała nowy serwis
serwer
serwer
Wywołanie DdeClientTransaction typu
XTYP_REQUEST. Klient przesyła żadanie
o dane specyfikujac
˛ serwis, temat i pozycj˛e.
klient / Aplikacja odrejestrowała serwis
serwer
serwer
Nawiazanie
˛
połaczenie
˛
bez
wyspecyfikowanego serwisu / tematu - listning
spełaniajacych
˛
kryterium
klient
Koniec tranzakcji asynchronicznej, serwer
zwraca wynik
Tablica 3.1: Zestawienie transakcji DDEML
ogólniejszego standardu DCE (Data Communications Exchange).
25
ROZDZIAŁ 3. MECHANIZMY ROZBUDOWANE
3.3. RPC
RPC dostarczane przez Microsoft jest kompatybilny ze standardem OSF/DCE. Ważna˛ uwaga˛
jest to, że jest on kompatybilny ale nie można budować aplikacji na podstawie szkieletu dostarczonego przez OSF. RPC Microsoftu jednak w pełni współpracuje z innymi, bazujacymi
˛
na DCE,
systemami takimi jak HP i IBM AIX.
Mechanizm RPC jest unikalny, ponieważ używa on innych mechanizmów komunikacji
mi˛edzyprocesowej do ustalenia komunikacji mi˛edzy klientem i serwerem. RPC może używać
nazwanych potoków, NetBIOS lub Windows Sockets do komunikacji ze zdalnymi systemami.
Jeżeli klient i serwer sa˛ na tym samym komputerze, moga˛ używać mechanizmu Local Procedure
Call (LPC), do przekazywania informacji mi˛edzy procesami lub podsystemami. Czyni to RPC
najbardziej elastycznym i przenośnym mechanizmem IPC w Windows NT.
Dzi˛eki własnościom RPC logika programu i zwiazane
˛
z nia˛ procedury moga˛ istnieć na innych
maszynach, co jest ważne dla aplikacji rozproszonych.
Jak jest pokazane na poniższym diagramie Windows dostarcza wsparcie dla klienta RPC
poprzez interfejsy NetBIOS, nazwane potoki i Windows Sockets:
Rysunek 3.4: Klient RPC w Windows 95
Nast˛epny diagram pokazuje jak Windows 95 dostarcza wsparcie dla klienta RPC poprzez
NetBIOS i Windows Sockets. Nie ma natomiast wsparcia dla RPC poprzez nazwane potoki.
Aplikacja RPC klienta wykorzystujaca
˛ nazwane potoki może być uruchamiana na komputerze
z Windows 95 lecz aplikacja serwera musi być uruchamiana na LAN Manager Serwerze lub
Windows NT.
RPC bazuje na koncepcji używanej przy budowie programów strukturalnych, które moga˛ być
26
ROZDZIAŁ 3. MECHANIZMY ROZBUDOWANE
3.3. RPC
widziane jako szkielet, do którego można przyczepić różne ciała. Szkielet zawiera główna˛ logik˛e
programu, która powinna być zmieniana tylko w rzadkich przypadkach. Ciałem natomiast sa˛
procedury, które sa˛ wywoływane przez szkielet do wykonywania odpowiednich zadań.
W tradycyjnych programach, ciało jest statycznie dołaczone.
˛
Przy pomocy DLL, strukturalne
programy moga˛ dynamicznie dołaczać
˛
ciało. Z DLL kod procedury sa˛ w innych modułach. Dlatego DLL może być modyfikowany lub modyfikowany bez zmian w szkielecie. RPC znaczy tyle, że
szkielet i ciało może istnieć na innych komputerach, tak jak jest to pokazane na rysunku.
Na rysunku tym, aplikacja klienta została stworzona przy pomocy specjalnie skompilowanej
biblioteki stub. Aplikacja klienta myśli, że wywołuje własne podprogramy. W rzeczywistości
biblioteka ta przesyła dane i funkcje na dół do modułu zwanego RPC Runtime. Moduł ten jest
odpowiedzialny za znalezienie serwera, który może spełnić komend˛e RPC. Kiedy już znajdzie,
funkcja i dane sa˛ przesyłane do serwera, gdzie sa˛ przejmowane przez moduł RPC Runtime. Wtedy serwer ładuje odpowiednie biblioteki dla funkcji, buduje odpowiednie struktury danych i
wywołuje funkcj˛e. Funkcja myśli że jest wywoływana przez aplikacj˛e klienta. Kiedy funkcja jest
gotowa, wszystkie zwracane wartości sa˛ zbierane razem, formatowane i wysyłane z powrotem
do klienta przez moduł RPC Runtime. Kiedy funkcja wraca do aplikacji klienta zawiera w sobie
odpowiednie dane lub dostaje informacje, że wywołanie funkcji nie powiodło si˛e.
27
ROZDZIAŁ 3. MECHANIZMY ROZBUDOWANE
3.4. WINDOWS SOCKETS
3.4 Windows Sockets
Windows Sockets API dostarcza standardowego interfejsu Windows dla wielu transportów z
różnymi schematami adresowania, takimi jak TCP/IP lub IPX. API Windows Socket powstały dla
osiagni˛
˛ ecia dwóch celów. Pierwszym z nich było przeniesienie interfejsu socketów, opracowanego
na University of California, Berkeley we wczesnych latach 80’tych, do środowiska Windows i
Windows NT. Drugim celem była standaryzacja API dla wszystkich platform.
Jest to de facto standard dla dost˛epu datagramów i serwisów sesji poprzez TCP/IP. Aplikacje
nie wykorzystujace
˛ NetBIOS’u musza˛ być napisane dla interfejs Socketów aby mieć dost˛ep do
protokołów TCP/IP Microsoftu. Aplikacje napisane dla tego interfejsu zawieraja˛ FTP i SNMP. W
Windows 95 sockety oferuja˛ rozszerzenie do IPX/SPX.
Windows Socket w systemach Windows jest niezależnym od protokołu sieciowym API stworzonym dla programistów. Windows Socket jest publiczna˛ specyfikacja,
˛ która stara si˛e osiagn
˛ ać
˛
nast˛epujace
˛ cele:
• Dostarcza dobrze znanego sieciowego API dla uzytkowników Windows lub UNIX
• Oferuje binarna˛ kompatybilność mi˛edzy różnymi bazujacymi
˛
na stosie protokołów TCP/IP
narz˛edziami
• Dostarcza zarówno połaczeniowego
˛
jak i bezpołaczeniowego
˛
protokołu.
Dost˛epne sa˛ dwa typy socketów:
• Stream sockets - odpowiada za przesyłanie danych bez tworzenia z niech rekordów - jest to
strumień bajtów. Strumienie gwarantuja˛ dostarczenie danych oraz poprawność sekwencji
i niepowtarzalności.
• Datagram sockets - odpowiada za przesyłanie danych przy pomocy rekordów. W tym przypadku nie jest gwarantowane dostarczenie danych, ich poprawna kolejność i niepowtarzalność.
Poprawna kolejność oznacza, że pakiety zostały dor˛eczone w kolejności, w której zostały wysłane.
Niepowtarzalność oznacza, że dostajemy dany pakiet tylko raz.
Sockety, w porównaniu do protokołu NetBIOS, dostarczaja˛ mniejsze obciażenie.
˛
Protokoły
nie pochodzace
˛ z NetBIOS takie jak TCP/IP i IPX/SPX wymagaja˛ interfejsu NetBIOS i warstwy
mapowania. Ten dodatkowy software zwi˛eksza czas działania i dodaje nagłówek do ramki
danych przesyłanych przez sieć. Dla przykładu, kiedy interfejs NetBIOS jest używany nad
protokołem TCP/IP, nagłówek NetBIOS jest dodawany do ramki przed nagłówkami TCP i
IP. Stacje robocze, które nasłuchuja˛ tylko ramek TCP/IP nie sa˛ wstanie zobaczyć tej ramki.
Jednakże, gdy sockety sa˛ używane, ramka jest wysyłana przez TCP/IP bez dodatkowego
nagłówka NetBIOS’u.
W TCP/IP adresem sieciowym stacji roboczej jest adres IP a adresem procesu jest numer
portu. Źródłowy i docelowy adres IP i numery portów sa˛ polami w strukturze pakietu TCP/IP.
W IPX/SPX, adres sieciowy jest kombinacja˛ sieciowego identyfikatora IPX i adresu MAC (media
28
ROZDZIAŁ 3. MECHANIZMY ROZBUDOWANE
3.4. WINDOWS SOCKETS
access control) urzadzenia,
˛
a adresem procesu jest numer sucketu IPX. Sieć źródłowa, docelowa,
w˛ezeł i numery socketów sa˛ polami w strukturze pakietu IPX/SPX.
Uwaga: Sockety IPX nie sa˛ takie same jak Sockety Windows.
Przy dwukierunkowej ścieżce, aplikacje Windows specyfikuja˛ zast˛epujace,
˛
zależne od protokołu identyfikatory.
Protokół
TCP/IP
IPX/SPX
dwukierunkowa ścieżka
dwukierunkowa ścieżka
Identyfikatory źródłowe i docelowe
adres IP i numer portu żródła
Network ID, adres MAC urzadzenia,
˛
numer socketu IPX
Tablica 3.2: Protokoły i identyfikatory
Nast˛epujaca
˛ tabela opisuje obsługujace
˛ pliki dla 16-bitowych i 32-bitowych socketów dla protokołu TCP/IP i 32-bitowe sockety dla protokołu IPX/SPX.
Plik
WINSOCK.DLL
Opis
16-bit Windows Sockets
WSOCK.VXD
Virtualized Windows Sockets
WSTCP.VXD
Windows Sockets over TCP/IP1
WSOCK32.DLL
32-bit Windows Socket
WSIPX.VXD
Windows Sockets over IPX/SPX2
Komentarz
Dostarcza wsteczna˛ kompatybilność z
istniejacymi
˛
16-bitowymi Socketami
TCP/IP w Windows, aplikacje takie jak
ping
Dostarcza 16-bitowe Sockety Windows i
32-bitowe Sockety TCP/IP i IPX/SPX w
Windows
Dostarcza 16-bitowe Sockety Windows i
32-bitowe sockety TCP/IP w Windows
Dostarcza 32-bitowe sockety TCP/IP w
Windows, aplikacje takie jak telnet i
32-bitowe aplikacje IPX/SPX Windows
Socket
Dostarcza 32-bitowe sockety IPX/SPX
w Windows
Tablica 3.3: Pliki systemowe Windows Sockets
1. Sockety Windows dla protokołu TCP/IP sa˛ oparte na datagramach przy UDP
2. Sockety Windows dla protokołu IPX/SPX sa˛ oparte na datagramach przy IPX
Popularne programy takie jak ftp lub telnet używaja˛ socketów Windows.
3.4.1
Windows Sockets 2
Wersja 2 Windows Sockets rozszerza funkcjonalność w wilu dziedzinach:
29
ROZDZIAŁ 3. MECHANIZMY ROZBUDOWANE
Dost˛ep do protokołów innych niż
TCP/IP
Niezależna od protokołu rezolucja
nazw
Niezależny od protokołu multicast i multipoint
Quality of service
Inne rozszerzenia
3.4. WINDOWS SOCKETS
Windows Sockets 2 pozwala aplikacji na używanie
podobnych interfejsów socketów aby osiagn
˛ ać
˛ jednoczesny dost˛ep do wielu zainstalowanych protokołów
transportowych.
Windows Sockets 2 zawiera zestandaryzowany zbiór
funkcji dla odwołań i pracy z wieloma domenami rezolucji nazw (np. DNS, SAP, X.500)
Windows Sockets 2 odkrywa możliwości dostarczane
przez warstw˛e transportowa˛ i używa ich.
Window Sockets 2 ustala konwencj˛e negocjowania
wymaganego poziomu serwisu (pasmo i opóźnienie)
Windows Sockets 2 zawiera dzielone sockety i warunkowa˛ akceptacj˛e; wymian˛e danych użytkownika w czasie nawiazywania
˛
i zrywania połaczenia;
˛
rozszerzenia
specyficzne dla protokołów.
Tablica 3.4: Rozszerzenia Windows Socket 2
30
Rozdział 4
Podsumowanie
Może si˛e wydawać, że w systemach serii Windows brakuje klasycznych mechanizmów znanych
z Unix’ów. Systemami Microsoftu rzadziły
˛
jednak troch˛e inne prawa aniżeli Unixami - i tutaj można by szukać takiego a nie innego podejścia. W obu rodzinach mamy potoki i pami˛eć
współdzielona,
˛ a jedynie dalszy rozwój na pewnym etapie podażał
˛
innymi drogami.
Obecnie wi˛ekoszść mechanizmów zaliczanych do klasy IPC może swobodnie operować w
środowisku rozproszonym i oferuje rozbudowana˛ funkcjonalność - taki jest wymóg czasu.
Możemy je jednak bez obaw wykorzystywać również lokalnie, a przy obecnych cenach mocy
komputerów możemy swobodnie pozwolić sobie na taka˛ nadmiarowość uzyskujac
˛ jeden
machanizm do wielu zastosowań, a przez to zmniejszenie kosztów implementacji systemów.
Ewolucja podstawowych mechanizów IPC poprzez kolejne wersje systemu Windows jest
bardzo niewielka.
Wi˛ekszość aplikacji powinna ze soba˛ współpracować, co najmniej na
poziomie oferowanym przez aplikacj˛e pisana˛ dla wcześniejszej wersji mechanizmu. Ponadto
tylko podstawowe mechaznizmy sa˛ nierozłaczne
˛
z systemem, a i tak wi˛ekszość z nich można
zaktualizować - oczywiście, o ile istnieje jeszcze wsparcie dla naszej wersji systemu.
31
ROZDZIAŁ 4. PODSUMOWANIE
Sieć
GUI
Synchronizacja
Mailslot
tak
Anonymous nie, tylko
Pipes
lokalne
nie
nie
nie
zewn˛etrzna
Named
Pipes
tak
nie
Windows
Sockets
tak
nie
zewn˛etrzna.
tryb synchroniczy (z blokada˛
funkcji) i asynchroniczny (bez
blokady)
wymagane
stosowanie
zewn˛etrznej
Schowek
nie
tak
nie konieczna
DDE
tak, NetDDE
tak
nie konieczna,
zapytanie
odpowiedź
COM
tak
nie
OLE
nie
tak
nie potrzebna
RPC
tak
nie
File Mapping
nie
nie
interfejs
przykrywa cała˛
struktur˛e RPC
i nie wiadomo
czy dana funkcja
wykonywane
jest zdalnie czy
lokalnie
brak, zalecane
stosowanie
zewn˛etrznej
Kompatybilność
W
Windows
NT/2000/XP
zaimplementiowane
jako
nazwane
o
unikalnej
nazwie
W
Windows
95/98/Me
nie
moga˛ być tworzone
Wymiana
danych
jednokierunkowa
jednokierunkowa
jednolub
dwukierunkowa
Wersja 2 jest
binarnie
i
źródłowo kompatybilna
z
1.1.
brak
niezgodności
pełna wsteczna
dwukierunkowa
Dodatkowa biblioteka.
klient - serwer
Kompatybliny z
OSP RPC
Tablica 4.1: Zestawienie mechanizmów - cechy
32
jednokierunkowa
klient - serwer,
dwukierunkowa
Dane
przechowywane sa˛ u
klienta, na czas
edycji przekazywane
sa˛
do
serwera, a po
jej zakończeniu
zpowrotem
do
klienta.
klient - serwer
jednokierunkowa
ROZDZIAŁ 4. PODSUMOWANIE
Bezpieczeństwo
Tylko
serwer
ma
możliwość odczytu z
mailslota. Klient tylko
może zapisywać.
Można ustalić security
descriptor
odpowiedzialny
za
kontrol˛e dost˛epu do
obu końców potoku
poprzez ACL
stosowanie
impersonacji do przyznawania uprawnień dla
klienta
możliwość kodowania
połaczenia
˛
przy pomocy SSL, używanie
certyfikatów
Jeden
właściel
schowka, inna aplikacja może dopiero
zapisywać po staniu
si˛e właścielem
brak,
NetDDE
mechanizmy
bezpieczeństwa NT / 2000
/ XP
Zalety
elegancja, możliwość
broadcastu <426 bajtów
Wady
Ograniczenie
wielkości wiadomości
< 64K
prostota
komunikacja
tylko
pomi˛edzy
powiazanymi
˛
procesami
prostota
niezależność od protokołu
konieczność
znajmości nazwy potoku
przed
nawiazaniem
˛
komunikacji
niezgodności z socketami z Berkeley
idealny
mechanizm
dla
aplikacji
biurowych
małe możliwości, obecnie nie wystarczajace
˛ pojedyńcza zwartość
prostota, łatwość użycia
w chwili obecnej lepiej
skorzystać z
OLE,
oferujacego
˛
znacznie
wi˛eksze
możliwości.
COM
pełne, identyfikacja,
autoryzacja...
OLE
opiera si˛e na mechanizmach
bezpieczeństwa w NT
i RPC
Duże
możliwości.
Kodowanie, autoryzacja, porównywanie z
ACL
ustawianie
zasad
współdzielenia stron,
możliwość zastosowania ACL
technologia
komponetowa,
łatwość
współpracy aplikacji
Możliwość
wstawania
dokumentów
zewn˛etrznych
aplikacji.
Niezależność platformowa
Mailslot
Anonymous Pipes
Named Pipes
Windows Sockets
Schowek
DDE
RPC
File Mapping
Duże zużycie zasobów.
Skomplikowany.
szybki dost˛ep do pliku,
odpowiednik pami˛eci
współdzielonej
Tablica 4.2: Zestawienie mechanizmów - wady, zalety, bezpieczeństwo
33
Rozdział 5
Bibliografia
1. MSDN
Library,
Platform
SDK:
Interprocess
Communications,
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ipc/
base/interprocess_communications.asp
2. Component Object Model (COM), DCOM, and Related Capabilities, Software Technology
Review, Software Engineering Institute, 13.III.2002r., http://www.sei.cmu.edu/str/
descriptions/com.html
3. MSDN
Library,
Platform
SDK:
COM+
(Component
Services),
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/
cossdk/htm/complusportal_9o9x.asp
34