Protokół sieciowy jest integralną, nawet jeśli dość dobrze ukrytą, częścią każdego systemu klient/serwer. Wybór właściwego protokołu komunikacyjnego między stacjami-klientami a serwerem zależy od wielu czynników. Czasem wybór wynika z istniejącej już infrastruktury, czasem zaś jest świadomą decyzją programisty.

Wielu z nas - nawet jeśli jedynie korzysta z sieci - zetknęło się z nazwami TCP/IP, SPX/IPX, NetBIOS czy APPC. Na ogół jednak nie zdajemy sobie sprawy ze złożoności tych protokołów i ilości pracy, którą musi włożyć programista, jeśli będzie musiał korzystać z nich bezpośrednio w pracy nad aplikacjami dla środowiska przetwarzania rozproszonego.

Jednakże w trakcie opracowania aplikacji klient/serwer pojawi się moment, gdy trzeba będzie podjąć decyzję, jaki protokół komunikacyjny zastosować. Trzeba też będzie odpowiedzieć na pytania, które protokoły komunikacyjne działają na używanym sprzęcie, które są wbudowane a które będą wymagać zainstalowania tzw. stosu do ich obsługi, które zaś działają na wielu platformach itd.

Ponieważ większość stacji klienckich w środowisku przetwarzania rozproszonego to komputery pracujące pod DOS/Windows, w związku z tym będziemy tu omawiać jedynie protokoły nadające się do tych komputerów.

Co to jest protokół komunikacyjny?

Najprościej można powiedzieć, że protokół komunikacyjny to zbiór standardów, umożliwiających komputerom komunikowanie się między sobą. Protokoły w komputerze obsługują tzw. stosy protokołów, tj. zestawy programów działających w sposób ciągły. W DOS-ie działają one jako programy rezydentne (TSR), w Unixie są to tzw. demony, w Windows NT jako ładowalne biblioteki DLL, działające w trybie chronionym procesora. Bardziej szczegółowe wyjaśnienie popularnych protokołów komunikacyjnych zawiera sąsiedni materiał ("Protokoły komunikacyjne").

Jeżeli komputer ma komunikować się z wieloma innymi komputerami, posługującymi się różnymi protokołami, często musi ładować do pamięci kilka stosów protokołów. Na przykład w sieci z serwerami Windows NT AS, posługującymi się protokołem NetBIOS i z serwerami NetWare, posługującymi się protokołem IPX/SPX, komputer klienta musi obsługiwać obydwa te protokoły.

Protokoły OSI

Międzynarodowa Organizacja Standardów ISO opracowała siedmiowarstwowy model zwany Open Systems Interconnection (OSI), definiujący różne funkcje sieci.

Model OSI stworzono w celu umożliwienia opracowania aplikacji działających w niejednorodnym środowisku sieciowym i promocji systemów sieciowych, zdolnych do współpracy między sobą.

W modelu jedynie najniższa warstwa dotyczy sprzętu (adapterów sieciowych), wszystkie pozostałe są modułami programowymi.

* Warstwa fizyczna definiuje elektryczne właściwości łącza (poziomy sygnału, okablowanie, właściwości mechaniczne elementów itp.). W tej warstwie dla potrzeb sieci lokalnych zdefiniowano właściwości łącz Ethernet, Token Ring i FDDI.

* Warstwa łącza danych określa sposoby kontroli elementów fizycznych łącza sieciowego, wykrywania i korekcji błędów, rozstrzygania o kolejności dostępu itp. Dzielona na dwie podwarstwy: dolna Media Access Control (MAC) służąca do zdefiniowania sposobu przesyłania przez łącze (przesyłanie żetonu, CSMA/CD, FDDI, in.); górna Logical Link Control (LLC) umożliwia przesyłanie informacji między różnymi typami sieci. W tej podwarstwie możliwe jest wykorzystanie różnych specyfikacji MAC w celu wykorzystania w jednym komputerze kart sieciowych różnych typów.

W warstwie łącza danych działają sterowniki kart sieciowych: novellowski ODI (Open Datalink Interface) i NDIS (Network Driver Interface Specification) firmy Microsoft.

* Warstwa sieciowa. Określa i utrzymuje drogi komunikacji między różnymi sieciami. Korzystając z adresu sieciowego umieszczonego w pakiecie, może skierować pakiet na właściwą drogę w sieci lokalnej lub rozległej. W tej warstwie działają protokoły bezpołączeniowe (IP z TCP/IP, X.25, Novell IPX). Także w tej warstwie realizowane są routery.

* Warstwa transportowa. Realizuje podstawowe funkcje kontrolne w sieci: kontrolę błędów, rozpoznaje kolejność pakietów, żąda przesłania brakujących pakietów, usuwa duplikaty pakietów, dopisuje do pakietu informacje pozwalające odbiorcy na wykonanie tych samych czynności kontrolnych. Z warstwą transportową odbiorcy ustanawia logiczne połączenie nadawca/odbiorca. W tej warstwie działają typowe transportowe protokoły połączeniowe: (TCP z TCP/IP, Novell SPX, Microsoft NetBIOS/NetBEUI).

* Warstwa sesji. Służy do określenia parametrów sesji połączeniowej między nadawcą a odbiorcą. Wie gdzie przesłać dane i co zrobić po utracie połączenia.

* Warstwa prezentacji. Część systemu operacyjnego komputera. Pozwala np. na przekształcenie kodów ASCII z jednego systemu na kody zgodne z reprezentacją stosowaną przez IBM - EBCDIC.

* Warstwa aplikacji. Definiuje aplikacje korzystające z pozostałych warstw, np. w celu przesyłania plików, korzystania z poczty elektronicznej czy emulacji terminala.

W praktyce jeszcze do niedawna model OSI służył jako punkt odniesienia dla wszystkich innych protokołów sieciowych, pozwalając na ich usytuowanie na odpowiednim poziomie modelu.

Istnieją jedynie nieliczne realizacje protokołów komunikacyjnych zgodnych z tym modelem, chociaż obecnie coraz więcej firm je realizuje. Tak więc praktycznie do realizacji systemów klient/serwer nie możemy wybrać tych protokołów.

SPX/IPX

Największa liczba protokołów komunikacyjnych jest dostępnych dla komputerów DOS, ale najpopularniejszy jest zestaw SPX/IPX, wbudowany w sieciowe systemy operacyjne NetWare. Jeżeli więc pracujemy w sieci Novell, to mamy niejako automatycznie zapewniony ten zestaw komunikacyjny. Oczywiście istnieją także realizacje SPX/IPX dla Unixa, Windows NT, OS/2; jest on także protokołem macierzystym w novellowskiej wersji Unixa - UnixWare 2.0.

Podobnie jak do innych protokołów komunikacyjnych, Novell dostarcza zestaw funkcji API, pozwalający na opracowanie aplikacji, korzystających z niego w celu przesyłania danych. Unikalną funkcją SPX/IPX jest możliwość korzystania z bazy obiektów w sieci (binderów w NetWare 3.x lub NetWare Directory Services w NetWare 4.x) w celu zlokalizowania serwerów w sieci. Serwer po włączeniu się do sieci rejestruje swą obecność w tej bazie, co pozwala klientom uzyskać jego adres sieciowy.

NetBIOS

NetBIOS jest protokołem komunikacyjnym realizowanym w systemach operacyjnych Microsoft i IBM (DOS, Windows, Windows NT, LAN Manager, OS/2), a także w NetWare (przez emulację). NetBIOS nie stosuje się do reguł OSI, mówiących że każda warstwa modelu może komunikować się jedynie z warstwami sąsiednimi. NetBIOS dopuszcza komunikację poprzez wiele warstw, a programy użytkowe mogą porozumiewać się bezpośrednio z NetBIOS, pomijając warstwę aplikacji i prezentacji.

Inną wadą NetBIOS jest niemożność przesyłania jego pakietów przez routery, z powodu ograniczeń w nazewnictwie pakietów i braku nagłówka pakietu właściwego dla warstwy sieciowej (zawierającego informacje kierunkowe dla pakietu). W efekcie, w celu przesłania pakietów NetBIOS przez sieci rozległe (z routerami) należy "opakować" je w inne pakiety, np. IP.

Potoki etykietowane

Zostały opracowane dla OS/2 jako czysty mechanizm komunikacji w środowisku klient/serwer. Służą do łączenia poprzez sieć dwóch procesów, działających na różnych komputerach. Każdy proces czyta i zapisuje do etykietowanego potoku, tak jak czyta i zapisuje plik. Jednakże informacja nie rezyduje na dysku, ale przenosi się przez sieć do stacji przeznaczenia. W systemie Unix służą do komunikacji między procesami na tym samym komputerze, są więc znacznie mniej atrakcyjne z punktu widzenia aplikacji klient/serwer. Mechanizmy systemowe OS/2 i Unixa pozwalają na uruchamianie potoków etykietowanych w zadanym czasie oraz pozwalają na ich synchronizację.

TCP/IP

Protokoły komunikacyjne opracowane dla potrzeb sieci Internet. Stały się standardem komunikacyjnym dla komputerów unixowych. Faktycznie jest to cały zestaw protokołów komunikacyjnych, służących do realizacji wielu funkcji w środowisku Unixa.

Z punktu widzenia aplikacji klient/serwer największe znaczenie ma możliwość zdalnego wywoływania procedur (Remote Procedure Call - RPC), służąca do uruchamiania procesów i procedur na komputerze zdalnym, np. w celu wykonania operacji obliczeniowych albo tylko pobrania danych z bazy. Dodatkowy mechanizm w RPC - tzw. zewnętrzna reprezentacja danych (External Data Representation - XDR) pozwala na przekształcanie formatu danych na potrzebną postać.

Mechanizmem komunikacyjnym w Unixie podobnym do etykietowanych potoków w OS/2, są tzw. Sockets. Mają właściwości zbliżone do plików, to jest możliwe jest ich otwieranie, odczytywanie, zapisywanie i przesyłanie do innego komputera za pośrednictwem TCP/IP.

TCP/IP zyskuje stale na znaczeniu w związku z burzliwym rozwojem Internetu. Istnieją realizacje TCP/IP na komputerach DOS, Windows, NetWare i OS/2. Ponieważ jednak jest to protokół stosunkowo skomplikowany, to odpowiedni stos protokółów zajmuje dość dużo pamięci.

APPC

Jeżeli korzystasz Czytelniku z bazy danych ma mainframie, to jest duża szansa, że korzystasz z protokołu APPC, realizowanego np. w postaci gatewaya (bramy) z systemu DB2 na tym komputerze. Protokół APPC pozwala na komunikowanie się między dużymi komputerami a komputerami PC, Unix, OS/2. Dla programistów realizujących dostęp do bazy danych na mainframie dostępny jest zestaw funkcji API o nazwie Common Programming Interface for Communications (CPI-C), ukrywający skutecznie skomplikowane mechanizmy sieciowe APPC.

Jaki protokół wybrać?

Wydaje się, że najwięcej do powiedzenia w tej sprawie ma producent używanego systemu zarządzania bazami danych. Zawsze istnieje możliwość uruchomienia na komputerze - serwerze bazy danych - kilku stosów protokołów sieciowych, ale im mniej pośrednich warstw oprogramowania między tym serwerem a siecią, tym większa sumaryczna wydajność bazy. Większość producentów systemów zarządzania bazami danych rozumie ten problem i dostarcza serwery wyposażone w różne protokoły sieciowe. Na przykład serwery baz danych Gupta i Progress mogą komunikować się przy użyciu protokołów TCP/IP, SPX/IPX i NetBIOS.

Na wybór protokołu poważny wpływ ma także wyposażenie sprzętowe. Jeżeli korzystamy ze znacznej liczby stacji roboczych DOS/Windows, to do wyboru mamy praktycznie jedynie SPX/IPX i NetBIOS; jeśli zaś korzystamy w dużej mierze ze sprzętu unixowego, to najlepiej będzie wybrać TCP/IP.

Najkorzystniej - z punktu widzenia efektywności opracowania aplikacji klient/serwer - jest wyeliminowanie problemów związanych z protokołem przez użycie odpowiedniej, pośredniej warstwy oprogramowania, zwanej middleware. Nie zmienia to jednak faktu, że wcześniej należy wybrać protokoły komunikacyjne, do których dobierzemy sterowniki middleware (p. "Middleware na ratunek programiście").