W poprzednim odcinku omawiałem podstawowe właściwości sieciowe Windows NT i pokazałem jak są one usytuowane w stosunku do powszechnie akceptowanego modelu odniesienia OSI oraz do modelu IEEE 802. Teraz podaję bardziej szczegółowy opis elementów składowych sieciowego systemu Windows NT.

NDIS

W początkowych latach rozwoju sieci komputerowych (aż do późnych lat 80.) protokoły komunikacyjne były dość ściśle powiązane z firmowymi realizacjami sterowników kart sieciowych. W roku 1989 firmy Microsoft i 3Com opracowały wspólnie standard interfejsu dla komunikacji między warstwą MAC (rys. 1) a protokołami transportowymi. Znany jest pod nazwą Network Device Interface Specification (NDIS) i definiuje funkcje, pozwalające na komunikację programową między protokołami transportowymi a kartą sieciową. Windows NT korzysta z NDIS w wersji 3.0.

Protokoły transportowe

Windows NT zawiera kilka popularnych protokółów transportowych: DLC, TCP/IP, NBF i Streams.

DLC. Najprostszy z protokółów transportowych, o stosunkowo małej funkcjonalności, ale dodający też bardzo niewiele dodatkowej informacji do standardowej ramki. Bardziej skomplikowane funkcje muszą być realizowane przez warstwy wyższe. Jego prostota umożliwia wpisanie go do pamięci stałej ROM. Na przykład drukarka sieciowa HP IIISi korzysta właśnie z tego protokółu do obsługi pracy w sieci. Używany jest także przez SNA Server do komunikacji z dużymi komputerami IBM (mainframe).

NBF. Pochodzi od dawnego protokółu NetBEUI (NetBIOS Extended User Interface), opracowanego przez IBM w 1985 r. NetBEUI nadaje się tylko dla małych sieci lokalnych, gdyż nie może korzystać z routerów; w celu przejścia na sieci innego typu wymaga stosowania gatewaya. NBF zawiera jedynie protokół transportowy w oddzielnej warstwie sieciowej. Nie należy go mylić z NetBIOSem, mimo iż wcześniejsze jego realizacje w LAN Managerze zawierały także interfejs NetBIOS.

TCP/IP i Streams. TCP/IP w Windows NT jest zrealizowany inaczej niż inne protokóły, gdyż jest "otoczony" przez interfejs Streams. (Streams jest to interfejs komunikacji między procesami, wprowadzony po raz pierwszy w systemie Unix System V release 3.) Tak więc osoba pisząca program do komunikacji z TCP/IP, pisze go faktycznie zgodnie z interfejsem Streams.

Interfejs sterowników transportu TDI

Interfejs sterowników transportu służy jako platforma do opracowania aplikacji rozproszonych w środowisku sieciowym. Nie jest to pojedynczy program, ale raczej interfejs protokółów transportu. Od dołu komunikują się z nim protokóły transportu, od góry redyrektory i serwery (rezydujące na poziomie warstwy sesji).

Redyrektory i serwery

Podstawowym celem działania sieci jest wspólne korzystanie z plików i drukarek. Istnieją dwa podstawowe typy organizacji sieci: sieci z dedykowanym serwerem plików i stacjami roboczymi oraz sieci, w których można korzystać z zasobów każdego z komputerów na warunkach równorzędności dostępu (sieci peer-to-peer albo inaczej workgroup computing). Windows NT tworzy sieć komputerów równorzędnych.

Redyrektor w sieciach komputerów równorzędnych służy do przekazywania żądania dostępu do plików pod właściwy adres (do właściwego komputera). W Windows NT jest on zrealizowany jako sterownik plików: może być w dowolnym momencie załadowany dynamicznie przez jądro systemu, działa w takim samym chronionym trybie jak jądro systemu i może korzystać ze wszystkich możliwości systemu (np. z menedżera buforów dyskowych - Cache Managera) oraz kooperować z innymi redyrektorami.

Serwer działa w podobny sposób jak redyrektor, ale umożliwia dostęp do innych rodzajów instalowalnych systemów plikowych. Na przykład, jeśli Windows NT współistnieje na jednym komputerze z OS/2, niezbędny będzie serwer systemu plików HPFS.

Interfejs dostawców

Interfejs dostawców (Provider Interface) służy m.in. do identyfikacji i znajdowania w sieci zasobów na podstawie nazw, podanych zgodnie z konwencją uniwersalnego nazewnictwa (Universal Naming Convention - UNC). W Windows NT określono metodę nazywania zasobów przez podanie ich pełnej nazwy, poczynając od nazwy komputera na którym rezydują (nazwę komputera wyróżnia się przez rozpoczęcie jej podwójnym backslashem), np. \\serwer1\grupa3\katalog2\plik.

Interfejs dostawców zawiera dodatkowy element: router wielu dostawców (Multiple Provider Router), umożliwiający komunikację z różnymi typami sieci.

Warstwa aplikacji

Oprócz realizowania typowych dla innych systemów sieciowych funkcji dzielenia plików i drukarek, Windows NT zawiera także dodatkowe elementy służące do pisania aplikacji rozproszonych.

W aplikacjach rozproszonych, celem jest właściwe rozdzielenie pracy na część określaną mianem klienta i część wykonywaną przez serwer aplikacji. Pierwsza powinna być możliwie prosta i ma działać na stacji roboczej klienta. Druga wymaga znacznie większej mocy obliczeniowej i działa na serwerze aplikacji lub serwerze bazy danych. Komunikacja między nimi odbywa się przez sieć i normalnie wymaga korzystania ze specjalnych funkcji, odwołujących się do właściwości konkretnych sieci (zwykle są one dostarczane przez producentów sieci).

W Windows NT odpowiedni zestaw funkcji komunikacyjnych, niezależnych od użytej sieci, dostarczany jest w zestawie Win32 API. Nawet jeśli sieć nie jest dostępna, to funkcje są obecne i odpowiedzą właściwymi im kodami błędu.

Potoki etykietowane i skrzynki pocztowe, NetBIOS interfejs. Zostały zrealizowane jedynie w celu uzyskania zgodności z istniejącymi aplikacjami i instalacjami LAN Managera.

Podstawowe możliwości realizacji aplikacji rozproszonych zapewnia mechanizmzdalnego wywoływania procedur (Remote Procedure Call - RPC), opracowany zgodnie z zaleceniami OSF/DCE (Open Software Foundation -Distributed Computing Environment - p. CW nr 33 z dnia 13.09.93 r.). Może współpracować z realizacjami RPC na innych systemach operacyjnych, pozwala więc na opracowanie aplikacji rozproszonych, pracujących w niejednorodnym środowisku sprzętowo-programowym. RPC służy do zapewnienia komunikacji między serwerem a klientem aplikacji. Jeśli serwer i klient rezydują na tym samym komputerze, to stosuje się uproszczony mechanizm lokalnego wywoływania procedur (Local Procedure Call - LPC).

W celu zrozumienia mechanizmu RPC przytoczymy analogię programu z dobrze określoną strukturą jako "kręgosłupa", do którego przyczepione są procedury (kości), wykonujące dobrze sprecyzowane czynności. W dawniejszych programach te procedury stanowiły integralną część programu. Poczynając od Windows i OS/2, procedury te mogą być dołączane dynamicznie w miarę potrzeby. W tym celu skompilowane są w bibliotekach DLL, które można dowolnie modyfikować bez potrzeby modyfikowania "kręgosłupa" programu.

RPC oznacza, że program i jego procedury mogą rezydować na różnych komputerach. Oczywiście zarówno na komputerze- kliencie, jak na komputerzeserwerze musi istnieć możliwość znalezienia tej właściwej procedury. Zadanie to realizuje moduł RPC run-time, dołączany statycznie do aplikacji rozproszonej.

Artykuł niniejszy kończy cykl omawiający podstawowe elementy składowe Windows NT.