Mechanizmy komunikacyjne w systemach Windows i Windows XP. Przemysław Musiał, Artur Zezula

Transkrypt

1 Mechanizmy komunikacyjne w systemach Windows i Windows XP. Przemysław Musiał, Artur Zezula 14 grudnia 2002

2 Spis treści 1 Wstęp Mechanizmy systemów Windows Mechanizmy proste Schowek (Clipboard) Formaty i ich rejestracja Operacje Kopiowanie Wklejanie Właściciel schowka Podglad schowka Generowanie na żadanie Pamięć Data Copy File Mapping (Pamięć współdzielona) Obiekt mapowania pliku Widoku pliku Mailslots Potoki (Pipes) Named Pipes Nazwa potoku Synchronizacja Anonymous Pipes NetBIOS Mechanizmy rozbudowane COM (COM+) COM od podszewki Kompatybilność binarna Dostępność Object Linking and Embedding (OLE) DDE (DDEML) Ogólnie o DDE

3 SPIS TREŚCI SPIS TREŚCI DDEML Inicjalizacja Funkcja zwrotna DdeCallback Wykorzystanie stringów Nawiazywanie połaczenia - konwersacje Zarzadzanie danymi Transakcje RPC Windows Sockets Windows Sockets Podsumowanie 31 5 Bibliografia 34 2

4 Rozdział 1 Wstęp Większość obecnie używanych systemów posiada mechanizmy ułatwiajace komunikację i wymianę danych między 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ędzy procesami, inne natomiast pomiędzy komputerami w sieci. Aplikacje używajace IPC podlegaja hierarchii klient-serwer w przypadku pojedynczego połaczenia. Aplikacja nadrzędna serwer udostępnia zasób/serwis, przetwarza żadania, a aplikacja podrzędna klient - korzystaja z zasobu/serwisu, przekazuje własne żadania. Aplikacja może korzystać z wielu mechanizmów i występować w każdej z ról. Różnorodność mechanizmów IPC powoduje, iż często trudno wybrać jest ta właściwa. W wielu przypadkach będziemy zmuszeni do wykorzystania kilku mechanizmów celem uzyskania jak najlepszego efektu. Przed wyborem mechanizmu warto odpowiedzieć sobie na następujace pytania: Czy aplikacja będzie komunikowała się tylko z lokalnymi aplikacjami, czy również będzie 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ędzie miał możliwość wyboru z którymi aplikacjami ma zajść wymiana danych, czy raczej aplikacja będzie miała określona z góry grupę kooperantów? Czy komunikacja ma odbywać się między wieloma różnymi aplikacjami w ogólnej formie (n.p. kopiowanie), czy raczej będzie to wymiana konkretnych danych ograniczajaca się 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

5 ROZDZIAŁ 1. WSTEP 1.1. MECHANIZMY SYSTEMÓW WINDOWS 1.1 Mechanizmy systemów Windows Systemy operacyjne firmy Microsoft kryjace się pod nazwa Windows oferuja szeroka gamę mechanizmów komunikacyjnych. Do dyspozycji mamy: Schowek (Clipboard) COM Data Copy DDE File Mapping Mailslots Potoki (Pipes) RPC Windows Sockets W dalszej części przybliżymy kolejno każdy z mechanizmów. 4

6 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ędzy 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ę 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ększość operacji na schowku wykonuja pojedyncze okna. Przeważnie procedura okna pobiera lub umieszcza informacje jak 5

7 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ę polecenie użytkownika. Podgląd schowka Rejestracja formatów Aplikacja A Schowek Format F1 Zmiana zawartośći Lista dostępnych formatów Akceptowalny format Aplikacja B Okno aplikacji A Format F2 Dane w wybranym formacie Okno aplikacji B Eksport w formatach Format F3 Kopiuj Wklej Użytkownik Rysunek 2.2: Użycie i działanie schowka W aplikacjach systemu Windows schowek powiazany jest z następujacymi 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 Formaty i ich rejestracja Aplikacja kopiujac dane do schowka może umieścić je w kilku formatach. Schowek ma określone standardowe formaty obsługuj ace tekst, grafikę i dźwięk. Pełny ich wykaz można znaleźć na 6

8 ROZDZIAŁ 2. MECHANIZMY PROSTE 2.1. SCHOWEK (CLIPBOARD) stronach MSDN i przytaczanie całego spisu tutaj jest zbędne. W Windows 2000/XP wprowadzono jedynie obsługę UNICODE u oraz jeden typ graficzny. Ciekawszym aspektem jest rejestracja własnych formatów, gdyż większość 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ę, 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ędzy 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. zajmowana przez dane w formacie prywatnym nie jest zwalniania automatycznie. Pamięć otrzymaniu komunikatu WM_DESTROYCLIPBOARD właściciel danych powinien uwolnić zajmowana pamięć. 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ęć 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ę dostępnych formatów dopóki nie napotka jej znanego. W ostatnich wersjach systemu poszerzono również listę wewnętrznych konwersji między formatami. Dzięki temu, o ile istnieje taka możliwość, odpytujac schowek o dostępne 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ększa ilość informacji, na przykład o formatowaniu i może sama zdecydować jak wstawić dane. Po Operacje Każda operacja na schowku rozpoczyna się otwarciem go poprzez wywołanie OpenClipboard, a kończy zamknięciem CloseClipboard. Tylko jedna aplikacja może mieć otwarty schowek. Na okno, które otwarło schowek wskazuje wartość zwracana przez GetOpenClipboardWindow. 7

9 ROZDZIAŁ 2. MECHANIZMY PROSTE 2.1. SCHOWEK (CLIPBOARD) Kopiowanie Po otwarciu schowka możemy zaczać z niego korzystać. Proces wstawiania rozpoczyna się od opróżnienia poprzedniej zawartości EmptyClipboard. Wywołanie funkcji powoduje wysłanie komunikatu WM_DESTROYCLIPBOARD do poprzedniego właściciela, usunięcie zawartości schowka i przypisanie okna, które wywołało funkcję jako nowego właściciela. O aktualnego właściciela można zawsze zapytać funkcja GetClipboardWindow. Następnie można już kolejno umieszczać dane w pożadanych formatach, pamiętajac, że kolejność gra rolę. Dodawanie zawartości przeprowadza się 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 Wklejanie Dostępność wielu formatów tych samych danych w schowku powoduje, że należy przed ich wstawieniem wybrać najbardziej odpowiedni format. Dostępne 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ępnego formatu na podstawie listy priorytetowej GetPriority- ClipboardFormat 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ę jak najszybciej odblokować obiekt. Okno nie będace właścicielem danych nie powinno zwalniać pamięci zaalokowanej na obiekt Właściciel schowka Jak wspominaliśmy okno po wywołaniu EmptyClipboard staje się właścicielem okna i pozostaje nim dopóki innego okno nie opróżni schowka lub do zamknięcia. Funkcja wysyła do poprzedniego właściciela komunikat WM_DESTROYCLIPBOARD. O ile okno wstawiło dane w formacie, w którym pamięć nie jest zwalniania automatycznie lub posiada dane generowane na żadanie powinno obsłużyć komunikat i wykonać odpowiednie akcje - zwolnić pamięć zajmowana przez dane powiazane ze schowkiem Podglad schowka Schowek ma możliwość dołaczeniabonifikowana aplikacji podgladaj acej aktualna zawartość, która przy każdej zmianie będzie o tym notyfikowana. 8 Aplikacje te tworza łańcuch, więc

10 ROZDZIAŁ 2. MECHANIZMY PROSTE 2.2. DATA COPY ważne jest, aby każda z nich przekazywała informację dalej. przekazać komunikat zwraca funkcja rejestrujaca SetClipboardViewer. Informację o tym gdzie mamy Takie rozwiazanie obliguje jednocześnie aplikacje do naprawiania łańcucha podczas wyrejestrowania się jednego z elementów (funkcja ChangeClipboardChain(okno_zamykane, okno_następne)) okna będace w łańcuchu powinny przekazywać sobie komunikat WM_CHANGECBCHAIN dopóki jedno z nich nie stwierdzi, że to jego następnik jest zamykany. W tym momencie dane okno powinno zaktualizować informacje o własnym następniku (informacja o następniku zamykane okna podawana jest w komunikacie). WM_DRAWCLIPBOARD notyfikujacym o zmianę zawartości. Podobnie spraw ma się w przypadku komunikatu W tym przypadku również należy przekazać komunikat do swego następnika, wcześniej wykonujac pożadane operacje odczytu na schowku Generowanie na żadanie W schowku może zostać umieszczona również informacja, że dane zostana wygenerowane na żadanie. przygotowania. Konieczność takiego rozwiazania może być różna: wielkość danych, czas Stosujac takie rozwiazania, okno (dopóki nie dostanie komunikatu WM_DESTROYCLIPBOARD) musi być gotowe przygotować i udostępnić 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. przypadku otrzymania takie komunikatu nie otwieramy schowka. W 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ępne po zamknięciu okna. Jeżeli format nie został umieszczony w schowku, a właściciel nie jest już dostępny to taki format nie będzie widoczny dla oknien sprawdzajacych dostępne formaty Pamięć Wszystkie dane przekazywane do schowka powinny być zapisane w pamięci alokowanej przy użyciu GlobalAlloc z flaga GMEM_MOVEABLE. Po umieszczeniu ich w schowku system staje się właścicielem tych obszarów pamięci 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ęcia. Tyczy się 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

11 ROZDZIAŁ 2. MECHANIZMY PROSTE 2.3. FILE MAPPING (PAMIEĆ WSPÓŁDZIELONA) 2.3 File Mapping (Pamięć współdzielona) Windowsowy mechanizm o nazwie File Mapping jest odpowiednikiem Unixowej pamięci współdzielonej. Zasada działania polega na udostępnieniu zawartości pliku jako bloku pamięci 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ęc korzystajac w kilku procesach z tego mechanizmu należy zapewnić synchronizację. Zależnie od nadania nazwy danemu przypisaniu dodaje się 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ępu. 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ęścia pamięci współdzielonej procesu używanej do dostępu do pliku (można nim manipulować przy użyciu funkcji VirtualProtect. Głównymi zaletami mapowania pliku sa: Szybszy i łatwiejszy dostęp do plików Działanie podobne do pamięci współdzielonej dla wielu aplikacji 10

12 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ęp 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ęp do innych danych niż aktualnie dostępne 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ę żaden widok może zapisać do pliku i zwolnić pamięć, a ża- dany obszar pliku wczytać, o ile nie jest od dostępny. Przy pomocy File Mapping można uzyskać dostęp 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ędzy 2 a 3 GB wirtualnej przestrzeni adresowej, gdzie oprócz widoków jest 16-bitowy stos jak i współdzielone systemowe biblioteki DLL) Obiekt mapowania pliku Mechanizm może udostępnić dowolny plik, jednym wymogiem jest, aby miał do niego wyłaczny i ciagły dostęp do momentu usunięcia 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ępu z jakimi chce się do niego mieć dostęp z obiektu mapowania. W przeciwnym wypadku może wystapić bład. Otrzymany uchwyt w wyniku działania funkcji będzie parametrem przy wywołaniu CreateFileMapping. Ważne do odnotowania jest, że tworzac obiekt mapowania nie ma konieczności ograniczania rozmiarów dostępnego obszaru pliku, gdyż nie wypływa to na ilość dostępnych zasobów systemowych. Najlepiej więc jako parametry dwmaximumsizehigh i dwmaximumsizelow przy tworzeniu obiektu podać wartość 0. Zasoby systemowe zajmowane sa dopiero przy tworzeniu widoków, ale tutaj dostępny obszar może być dowolnie wybrany z pliku (dowolnie wybrane bloki danych na dysku). W przypadku gdy chcemy jednak udostępnić tylko fragment, należy pamiętać, iż specyfikujemy jedynie udostępniana wielkość, bez offsetu, a więc musimy i tak udostępnić plik od poczatku do końca żadanego fragmentu (uwzględniajac położenie na dysku i rozmieszczenie w klastrach). Jako parametr do funkcji CreateFileMapping podaje się również nazwę dla tworzonego obiektu. Gdy obiekt o takiej nazwie istnieje podejmowana jest próba uzyskania do niego dostępu 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). wypadku tworzony jest nowy obiekt. W przeciwnym Pozostawiajac nazwę pusta (null, a nie ) tworzymy nienazwany obiekt, do którego nie będzie się można odwołać przez nazwę. 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

13 ROZDZIAŁ 2. MECHANIZMY PROSTE 2.4. MAILSLOTS dysku. Zamknięcie obiektu odbywa się w odwrotnej kolejności do otwarcia, a więc najpierw należy zamknać obiekt, a później plik 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ępny w obiekcie) z tymi samymi flagami co poprzedniczkę. 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ęp do tych samych danych, tak więc 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ęp do wybranego obszaru pliku, identycznie jak w przypadku zmiennej dynamicznej. Zamknięcie widoku wykonuje się poprzez wywołanie UnmapViewOfFile dla pojedynczego widoku. 2.4 Mailslots Mailslot jest mechanizmem jednokierunkowej komunikacji między 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ę grupowa. Zamiast mailslotów, do komunikacji między 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ędzy 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ę 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ę 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

14 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ększoś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ępujace elementy: dwa backslashe na poczatku nazwy, kropkę, backslash po kropce, nazwę mailslot, następnie wystepuje nazwa mailslotu. Przykad: \\.\mailslot\[path]name Aby umieścić wiadomość w mailslocie prces otwiera mailslota porzez jego nazwę. Zapisywanie wiadomości na lokalnym komputerze zdarza się rzadko. Częś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ępujac a formę: \\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ęp do nazwanych potoków i mailslotów jest osiagalny przez przekierowanie. Nazwane potoki dostarczaja które pozwalaja na dzielenie pamięci poprzez sieć. połaczeniowo-zorientowane przekazywanie wiadomości, Windows NT posiada specjalny interfejs programowania (API), który zwiększa bezpieczeństwo przy używaniu nazwanych potoków. 13

15 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ęta zostanie próba spełnienia żadania. Dlatego też, jeżeli klient nie ma autoryzacji do wykonania zadania, żadanie zostanie odrzucone Named Pipes Pipe jest sekcja dzielonej pamięci, której proces używa do komunikacji. Nazwane potoki dostarczaja łatwe w dostępie połaczenie jeden-do-jeden, wydajność i zorientowany połaczeniowo transfer danych między dwoma procesami. Potok nazwany może być tworzony między procesami niezwiazanymi z soba, a także może przekazywać informację poprzez sieć. Proces, który tworzy potok nazywany jest pipe server. Proces, który łaczy się z potokiem jest nazywany pipe client. Gdy jeden proces wpisuje informacje do potoku, drugi proces odczytuje stamtad informację. Proces serwera tworzy potok i zarzadza dostępem 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ęp do zdalnego zasobu potoku. Mimo że, potoki sa zazwyczaj używane dwukierunkowo, potok może być skonfigurowany tak aby pozwalał na komunikację 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 Nazwa potoku Każdy nazwany potok musi posiadać swoja unikalna nazwę, która rozróżnia go od innych potoków. Nazwa potoku ustalana jest podczas tworzenia potoku przy pomocy funkcji Create- NamedPipe. Nazwa potoku otwieranego przez klienta ma następujac a formę: \\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ęc nazwa tworzonego potoku zawiera kropkę zamiast nazwy serwera. \\.\pipe\pipename 14

16 ROZDZIAŁ 2. MECHANIZMY PROSTE 2.6. NETBIOS 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ę 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ę z kilkoma klientami, musi stworzyć osobny watek dla każdego klienta, tak aby jeden lub więcej watków mogły działać gdy inne czekaja Anonymous Pipes Potoki anonimowe, zwane również potokami nienazwanymi, umożliwiaja zwiazanym procesom na wymianę 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ększa ilość potomków, które dziedzicza uchwyty zapisu i odczytu do anonimowego potoku. Procesy te moga używać potoków do komunikowania się między soba, bez przechodzenia przez proces rodzica. Anonimowe potoki nie moga być używane poprzez sieć, ani nie moga być używane między 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ę poprzez różne protokoły: NetBEUI (NBF), NWLink NetBIOS (NWNBLink) i NetBIOS over TCP/IP (NetBT). Interfejs NetBIOS dostarcza komendy i wsparcie dla następujacych serwisów: Rejestracja i weryfikacja nazwy sieciowej Ustanawianie i zrywanie sesji Niezawodność przesyłania danych 15

17 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ę znana jako network control block (NCB). Aplikacja może wysyłać komendy NetBIOS ponad dowolnym protokołem, który dostarcza odpowiedni interfejs. 16

18 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ększe systemy, komunikujac się wzajemnie poprzez COM. Wzajemne wykorzystanie komponentów napisanych w różnych językach możliwe jest dzięki 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ę w środowisku lokalnym jak i sieciowym. Ponad *COM, które znajduja się w niskich warstwach i wspieraja wzajemna interakcję między komponentami, stworzone zostały technologie służace do osadzania obiektu w obiekcie (ActiveX, OLE) i tworzenia połaczeń (OLE). Dzięki 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ę mechanizmu w wizualnych środowiskach programistycznych Microsoftu COM od podszewki Jak wspominaliśmy na komponentach COM wymuszona jest binarna zgodność, niezależnie od wykorzystywanego języka programowania. Dzięki takiemu rozwiazaniu uzyskujemy niezależność od języka programowania i uniwersalność komponentu. Komponent jest widoczny jako zbiór interfejsów, posiadajacych własne zestawy dostępnych metod, reprezentujacych punkty kontaktu pomiędzy klientem a obiektem. Interfejsy, w celu zachowania zgodności, nie powinny się zmieniać. Tzn. chcac rozszerzyć możliwości obiektu należy nowe metody udostępnić za pomoca nowego interfejsu (można utworzyć interfejs dziedziczy po poprzedniej wersji). Dzięki 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

19 ROZDZIAŁ 3. MECHANIZMY ROZBUDOWANE 3.1. COM (COM+) Aplikacja kliencka Wskaźnik na interfejs Obiekt 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ędacego 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ęp do każdego z obiektów zapewniony jest na trzy sposoby: 1. Serwer wewnatrz procesu: Klient łaczy się bezpośrednio z biblioteka zawierajac a serwer. Klient i serwer znajduja się w tym samym procesie. wywołanie funkcji. Komunikacja zachodzi poprzez 2. Proxy lokalnego obiektu: Klient łaczy się z serwerem działajacym w innym procesie, ale na tym samym komputerze poprzez mechanizmy IPC (obecnie LRPC). 3. Proxy zdalnego obiektu: Klient łaczy się z serwerem działajacym na zdalnym komputerze. Taki sposób połaczenia został wprowadzony przez DCOM, a do komunikacji wykorzystywany jest DCE RPC. Proces klienta Obiekt procesu Serwer lokalny Proces Lokalnego Serwera stub COM Obiekt loklany Serwer lokalny Aplikacja kliencka Proxy obiektu lokalnego LRPC Proces Zdalnego Serwera COM Proxy obiektu zdalnego RPC stub COM Obiekt zdalny Serwer zdalny Zdalny host Rysunek 3.2: Metody dostępu do obiektu COM 18

20 ROZDZIAŁ 3. MECHANIZMY ROZBUDOWANE 3.1. COM (COM+) O ile pierwszy sposób jest stosunkowo łatwy do realizacji, to dwa następne wymagaja już większego 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ędzie udostępniał i zarzadzał prawdziwym wskaźnikiem na interfejs. Następnie tworzone jest proxy po stronie klienta, które łaczy się ze stub i udostępnia 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ęc prosić o dostęp 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 Kompatybilność binarna Wspominaliśmy, że dla komponentów COM wymagana jest kompatybilność binarna, która jest warunkiem koniecznym dla niezależności od języka programowania. Pod pojęciem kompatybilność binarna rozumie się ustandaryzowana postać wirtualnych tablic funkcji (vtables) w pamięci. Klient chcac wykonać metodę obiektu COM wykorzystuje wskaźnik do wpisu w wirtualnej tablicy funkcji. Dodatkowo daje to możliwość zredukowania liczby instancji obiektu COM, gdyż dzięki takiemu rozwiazaniu może być współdzielony Dostępność Wraz z rozwojem technologii COM Microsoft udostępniał nowe wersje bibliotek na swoje systemy operacyjne. Implementacje COM sa również dostępne na część Unix ów. Same biblioteki można było więc 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ępne na starszych wersjach Windowsów. Na dzień dzisiejszy najnowsza wersja COM+ 1.5 dostępna jest jedynie z Windows XP i Windows.NET Serwer i nie będzie dostępna nawet dla Windows 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ę. Sama technologia zwiazana jest raczej z komponentowa technika programowania aniżeli IPC, aczkolwiek jest swoistym przejawem komunikacji między procesami. Jak wspominaliśmy do komunikacji na niskim poziomie wykorzystywane jest RPC, które opiszemy w dalszej części. 19