Temat: Interfejs sieciowy (konfiguracje). Stos protokołów IPX/SPX i TCP/IP. 1. Wstęp Zasadniczą strukturę sieciowego systemu operacyjnego można przedstawić w postaci modelu ISO-OSI (rys. 1). Model ten powstał w wyniku prac Międzynarodowej Organizacji ds. Standaryzacji (ISO) mających na celu stworzenie modelu procesu komunikacyjnego. 7 warstwa aplikacji 6 warstwa prezentacji 5 warstwa sesji 4 warstwa transportowa 3 warstwa sieciowa 2 warstwa łącza danych 1 warstwa fizyczna Rys. 1. Model ISO-OSI Model ISO-OSI jest modelem warstwowym. Każda warstwa świadczy pewien rodzaj usług dla warstwy bezpośrednio wyższej, a sama jest obsługiwana przez warstwę bezpośrednio niższą. W obrębie jednego systemu komputerowego komunikacja między warstwami odbywa się w pionie. Komputery komunikują się w poziomie komunikacja odbywa się między odpowiadającymi sobie warstwami modeli.

2. Warstwa łącza danych - Ethernet W sieciach LAN dominują obecnie dwie technologie: Ethernet i Token Ring (razem obejmują ponad 80 % rynku) z ogromną przewagą Ethernetu. Początki Ethernetu sięgają początków lat siedemdziesiątych. Wówczas to firma Xerox opracowała standard Experimental Ethernet wykorzystujący metodę dostępu CSMA/CD (Carrier Sense Multiple Access with Collision Detection). Mechanizm ten polega na tym, że węzły sieci próbują na dawać wyłącznie wtedy gdy w łączu komunikacyjnym panuje cisza, a gdy w trakcie nadawania dochodzi do kolizji ponawiają próbę nadawania po odczekaniu losowo wybranego czasu. W toku dalszych prac firmy DEC, Intel i Xerox uzgodniły na początku lat osiemdziesiątych wspólną specyfikację standardu Ethernet wersja 2.0 (Ethernet_II lub DIX Ethernet). Równolegle prowadzone były prace normalizacyjne komitetu 802 IEEE (Institute of Electrical and Electronics Engineering). Ich celem było zdefiniowanie standardów dla sieci lokalnych. W wyniku prac odpowiednich podkomitetów powstały dokumenty normalizujące zagadnienia związane z przesyłaniem danych w sieciach lokalnych (dotyczące warstwy fizycznej i łącza danych w modelu ISO-OSI). Komitet 802.1 określił relację między standardami IEEE 802, a modelem ISO-OSI. Komitet 802.2

zdefiniował protokół sterowania łączem logicznym (LLC). Komitet 802.3 zdefiniował warstwę fizyczną i warstwę dostępu do nośnika (MAC) w sieciach działających z wykorzystaniem metody dostępu CSMA/CD. Standard ten jest zgodny (z wyjątkiem kilku szczegółów) z Ethernet_II. Standardy opracowane przez IEEE w ramach prac komitetu 802 zostały przyjęte następnie przez Międzynarodową Organizację ds. Standaryzacji jako norma ISO 8802. Obecnie potocznie mianem Ethernet określa się standard IEEE 802.3 Formaty ramek Ethernet Przesyłanie danych szeregowym łączem komunikacyjnym odbywa się najczęściej nie w sposób ciągły. Strumień bitów jest podzielony na ramki (umożliwia to łatwiejszą korekcję przesyłanej informacji). Struktura ramki określa gdzie w ciągu bitów znajduje się informacja, a gdzie dane sterujące. Dane w ramkach Ethernet zawierają całą lub część informacji pakietu - paczki danych przesyłanych pomiędzy urządzeniami łączem komunikacyjnym. Pierwotnym formatem ramek jest Ethernet II (DIX). Strukturę wewnętrzną ramki Ethernet II przedstawiono na Rys. 2. suma kontrolna adres przeznaczenia adres źródła typ dane 4 bajty 6 bajtów 6 bajtów 2 bajty Rys. 2. Ramka Ethernet II. Ramka Ethernet_II wykorzystywana jest przez komputery pracujące z protokołem TCP/IP. Normy opracowane przez komitet 802 wprowadziły pewne zmiany do fomatów ramek - w miejscu gdzie w ramce Ethernet_II znajdował się typ pakietu w ramkach 802 zawarty jest typ pakietu. Jednak dzięki temu, że oznaczenia typów pakietów mają wartości większe od 1518 (np. IP - 0800h, Netware - 8137h), a długości ramek nie przekraczają 1500 bajtów możliwe jest proste odróżnienie obu typów ramek. Jako podstawę przy pracach normalizacyjnych zakładano że ramka 802.3 (rys. 3) powinna być używana wyłącznie z nagłówkiem zdefiniowaną prze komitet 802.2 (rys. 4). Nagłówek ten zawiera jednobajtowe kody protokołu odbiorczego i nadawczego oraz jednobajtowy kod określający rodzaj usługi. Jednak długi cykl prac spowodował, że firma Novell zaczęła używać w protokole IPX tzw. surowej ramki 802.3. Przyjęto wówczas konwencję, że pakiet IPX rozpoczyna się od stałej sumy kontrolnej równej FFFFh. Suma ta znajduje się w miejscu zarezerwowanym w ramce 802.2 dla oznaczenia protokołu obiorczego/nadawczego. Wprowadza to kolizję z jednym z protokołów kontrolnych (o kodzie FFh) zdefiniowanych przez komitet 802.2. Ostatnio jednak firma Novell podporządkowała się normom i zaleca stosowanie ramki 802.2 (jest to standardowy typ ramki w systemie Novell Netware 4.X) Wkrótce po zakończeniu prac przez komitet 802 okazał się, że oznaczanie typu protokołu przy pomocy jednego bajtu nie jest wystarczające. Wprowadzono dodatkowo ramkę 802.2 SNAP w której dzięki dodatkowemu nagłówkowi rozszerzono liczbę dostępnych kodów protokołów (Rys. 5).

suma kontrolna adres przeznaczenia adres źródła długość dane 4 bajty 6 bajtów 6 bajtów 2 bajty Rys. 3. Ramka 802.3. suma kontrolna adres przeznaczenia adres źródła długość nagłówek 802.2 dane 4 bajty 6 bajtów 6 bajtów 2 bajty 3 bajty Rys. 4. Ramka 802.2. adres przeznaczenia 6 bajtów

nagłówek adres długość 802.2 źródła 2 bajty 3 bajty 6 bajtów

nagłówek SNAP 5 bajtów

suma dane kontrolna 4 bajty

Rys. 5. Ramka 802.2 SNAP.

3. Protokół warstw: sieciowej i transportowej Protokołem nazwamy ściśle określone sposoby komunikowania się z innym systemem. Wyróżnia się dwa podstawowe typy protokołów: 1. połączeniowe 2. bezpołączeniowe. W metodzie połączeniowej między dwoma węzłami sieciowymi ustanawiany jest kanał komunikacyjny. W czasie transmisji węzły pozostają ze sobą w stałym kontakcie - nie ma konieczności przekazywania w pakietach kompletnych informacji adresowych. Pakiety przesyłane są w sieci po ustalonych torach i nadchodzą do miejsca przeznaczenia we właściwej kolejności. W metodzie bezpołączeniowej nadajnik przyjmuje założenie, że odbiornik otrzyma poprawnie przesyłaną informację. Odbiornik musi poinformować nadajnik o tym, że część datagramów nie dotarła lub są uszkodzone i zażądać ich powtórzenia oraz odtworzyć właściwą kolejność datagramów. Protokół TCP/IP Zbiór protokołów sieciowych TCP/IP opracowano w celu umożliwienia komunikacji między różnymi systemami komputerowymi. Początki powstania protokołu TCP/IP wiążą się z powstaniem na przełomie lat sześćdziesiątych i siedemdziesiątych sieci ARPANET. Wynikiem prowadzonych prac było opracowanie w 1978 TCP/IP. W skład zbioru TCP/IP wchodzi protokół połączeniowy TCP (Transfer Control Protocol) oraz protokół bezpołączeniowy i IP (Internet Protocol) - protokół bezpołączeniowy. Protokół TCP/IP stanowi obecnie podstawę komunikacji w Internecie. Protokół IPX/SPX Zbiór protokołów IPX/SPX został opracowany w firmie Novell na potrzeby

sieciowego systemu operacyjnego Novell Netware. Wywodzi się on z stosu protokołów Xerox Network System (XNS). IPX jest protokołem bezpołączeniowym, natomiast SPX protokołem połączeniowym. Na rys. 6 przedstawiono stosy obu zbiorów protokołów. Novell Netware

UNIX

7 warstwa aplikacji

NetWare Core Protocol Network File System

6 warstwa prezentacji

Netware Core Protocol XDR

5 warstwa sesji

NetBIOS potoki nazwane

RPC

4 warstwa transportowa SPX

TCP

3 warstwa sieciowa

IP

IPX

2 warstwa łącza danych 1 warstwa fizyczna Rys. 6. Stosy protokołów dla Novell Netware i UNIX-a

4. Oprogramowanie sterowników sieciowych We współczesnych sieciach, łączących wiele różnych systemów komputerowych pożądana jest praca z wieloma różnymi protokołami. Konieczne stało się opracowanie standardowego sposobu komunikowania się oprogramowania z interfejsem sieciowym. Jest to istotne szczególnie w przypadku komputerów klasy PC, gdzie występuje bardzo wielu producentów zarówno sprzętu, jak i oprogramowania sieciowego. Obecnie najczęściej używa się jednego z trzech głównych standardów oprogramowania sterowników sieciowych: 1. NDIS - Network Driver Interface Specification 2. ODI - Open Data-Link Interface 3. PD - Packet Driver Interface Programy sterowników opracowane według tych standardów zapewniają współpracę jednej kart sieciowej z różnymi protokołami. NDIS Specyfikacja NDIS opracowana została przez firmy 3Com i Microsoft. Wykorzystuje ona sterownik PROTMAN.DOS (Protocol Manager), który pośredniczy między sterownikiem karty sieciowej a różnymi stosami protokołów. Konfiguracja interfejsu sieciowego w standardzie NDIS zawarta jest w pliku PROTOCOL.INI. Specyfikacja NDIS (wersja 2 i 3) jest wykorzystywana głównie w sieciowych systemach operacyjnych opartych na protokole NetBEUI produkowanych przez firmę Microsoft. Istnieją programy, które zapewniają obsługę specyfikacji Packet Driver równocześnie ze specyfikacją NDIS (np. opracowany przez Joe Doupnika DIS_PKT hsdndev.harvard.edu /pub/ndis_pkt).

ODI Specyfikacja ODI opracowana została przez firmy Apple Computer i Novell. Wykorzystuje ona sterownik programowy Link Support Layer (LSL.COM), który zapewnia łącze pomiędzy sterownikiem karty sieciowej i protokołami komunikacyjnymi. Sterownik karty sieciowej spełnia specyfikację ODI Multiple Link Interface Driver (MLID). Novell Netware wykorzystuje sterownik IPXODI, który instaluje zestaw protokołów IPX/SPX i wiąże go z modułem LSL. W ostatniej wersji klienta Novell Netware zastosowano 32-bitową wersję specyfikacji ODI. Do prawidłowego skonfigurowania stacji roboczej w systemie Novell Netware z wykorzystaniem drivera ODI należy załadować do pamięci cztery programy: LSL, driver ODI kart sieciowej, IPXODI, oraz powłokę NETX lub requester VLM (najwygodniej jest umieścić odwołania do tych programów w pliku AUTOEXEC.BAT). Konfiguracja interfejsu sieciowego zawarta jest w pliku NET.CFG. Dla umożliwienia obsługi NDIS równolegle z ODI firma Novell wprowadziła specyfikację ODINSUP (Open Data-Link Interface Network Support). Program ODIPKT autorstwa Dana Lanciani (hsdndev.harvard.edu /pub/odipkt) umożliwia równoczesną z ODI obsługę specyfikacji Packet Driver. Struktura pliku NET.CFG

Plik konfiguracyjny NET.CFG zawiera trzy podstawowe sekcje Link Support zawiera definicję liczby oraz rozmiaru buforów odbiorczych Link Driver określa nazwę drivera oraz specyfikuje parametry (programowe i sprzętowe dla tego drivera) Netware DOS Requester stosowana w przypadku użycia requestera VLM W obrębie każdej z wymienionych sekcji mogą znaleźć się zarezerwowane słowa kluczowe oraz parametry specyfikujące. Niektóre bardziej istotne parametry wymieniono poniżej, opis pozostałych można znaleźć w dokumentacji źródłowej systemu Novell Netware, dostępnej m.in. w serwisie firmy Novell przez sieć WWW.

Sekcja Link Support

Buffers liczba_buforów [rozmiar_bufora] definiuje liczbę buforów oraz opcjonalnie ich rozmiar ; ; Przykład: definicja czterech buforów o długości 1600 bajtów ;

Link Support Buffers 4 1600 Sekcja Link Driver

Port adres_hex [długość_hex] definiuje adres bazowy portów wejścia/wyjścia oraz opcjonalnie liczbę tych portów ; ; Przykład: porty wej/wyj zawarte są od adresu 300h ; Link Driver NE1000 Port 300

Mem adres_hex [długość_hex] definiuje adres bazowy pamięci (adres powinien być podany w sposób bezwzględny, a długość jako liczba paragrafów pamięci ; ; Przykład: pamięć karty zawarta jest w granicach D0000-D3FFF

; Link Driver TRXNET Mem D0000 400 Int numer_przerwania określa numer przerwania sprzętowego wykorzystywanego prze kartę sieciową ; ; Przykład: karta wykorzystuje przerwanie IRQ 9 ; IRQ 9 Link Driver NE2000 Int 9

Frame typ_ramki uaktywnia wybrany typ ramki ; ; Przyklad: uaktywnie wszystkich czterech typów ramek Ethernet ; Link Driver NE2000 Frame Ethernet_802.3 Frame Ethernet_802.2 Frame Ethernet_II Frame Ethernet_SNAP Sekcja Netware DOS Requester

First Network Drive=X definiuje nazwę pierwszego dysku sieciowego ; ; Przykład: przypisanie pierwszemu dyskowi sieciowemu nazwy J: ; Netware DOS Requester First Network Drive=J Preferred Server=nazwa_servera określa serwer, do którego chcemy się dołączyć bez konieczności specyfikowania jego nazwy w komendzie LOGIN lub ATTACH ;

; przykład: wybranie domyślnego servera IR ; Netware DOS Requester Preferred Server=IR

Driver'y pakietowe Specyfikacja Packet Driver Interface została opublikowana przez fimę FTP Software Inc. Drivery pakietowe są dostępne jako oprogramowanie dostarczane przez producentów z kartą sieciową, ale dużą popularność zdobyły drivery opracowane przez Crynwr Software i dostępne jako oprogramowanie public domain. Większość oprogramowania sieciowego wykorzystującego protokół TCP/IP współpracuje z driverami typu PD. Drivery pakietowe wymagają przy uruchomieniu podania paramterów konfiguracyjnych. Są to kolejno: numer przerwania programowego drivrera, adres bazowy portów wej/wyj, numer przerwania sprzętowego i adres bazowy pamięci interfejsu sieciowego. Wykorzystując drivery sieciowe zgodne ze specyfikacją PD można również korzystać z systemu Novell Netware. Należy w tym celu załadować program IPXPDI instalujący zestaw protokołów IPX/SPX (ponieważ jednak wersje tego programu nie są od kilku lat rozwijane, więc oprogramowanie wymagające do pracy nowszych wersji powłoki lub klienta Netware może mieć problemy przy pracy z IPXPDI).

5. Interfejs programowy (API) warstwy transportowej Programy aplikacyjne dość rzadko odwołują się wprost do interfejsu sieciowego czy oprogramowania niższych niż czwarta warstw modelu ISO-OSI. Zwykle programy takie korzystają z bibliotek podprogramów, które z punktu widzenia twórcy aplikacji jest interfejsem (API) warstwy transportowej. Jedą z najczęściej używanych (szczególnie w systemie UNIX) bibliotek są tzw. gniazka (ang. sockets). Pozwalają one programiście korzystać z sieci komputerowej porzez standardowe operacje na plikach. Biblioteki gniazdek wchodzą w skład prawie każdej standardowej konfiguracji systemu UNIX. Dla systemu MS Windows opracowano specyfikację Windows Sockets, wzorowaną na gniazdkach systemu UNIX. Jest ona implementowana w postaci biblioteki dynamicznej o nazwie WINSOCK.DLL. Do działania wymaga zainstalowania oprogramowania TCP/IP. Oprogramowanie takie wraz z dostosowaną do niego wersją WINSOCK.DLL oferuje wiele komercyjnych firm software'owych (np. Novell, TCP Software, Sun). Istnieje także wersja shareware tej biblioteki o nazwie Trumpet. Wymaga ona do działania (w sieciach lokalnych) zainstalowania oprogramowania zgodnego ze specyfikacją PD.