Rozdział 7.
Warstwa aplikacji

W tym rozdziale:

• Przegląd portów

• Wprowadzenie do gniazd (sockets)

Internet jest siecią niejednorodną, na którą składają się różnego typu komputery i systemy operacyjne — takie jak Macintosh, Windows, Unix, OS/2 i tak dalej. Platformy te stosują odmienne konwencje nazywania plików, reprezentowania tekstu, odmienne metody szyfrowania danych i typy terminali. Warstwa aplikacji, piąta i ostatnia w modelu TCP/IP, odpowiada za pomyślną łączność i zgodność pomiędzy tymi niejednorodnymi platformami. Funkcjonalność tej warstwy jest zapewniana przez szereg różnych protokołów, na przykład: SMTP na potrzeby poczty elektronicznej, Telnet dla wirtualnych terminali oraz FTP do przesyłania plików. Warstwa aplikacji zawiera także aplikacje (programy) zdefiniowane przez użytkownika.

Z niniejszego rozdziału Czytelnik dowie się, jak aplikacje działające w odrębnych węzłach komunikują się ze sobą. Omówimy porty, gniazda i ich role w komunikacji równorzędnych aplikacji. Poznamy również popularne interfejsy API gniazd, takie jak gniazda Berkeley (BSD), Transport Layer Interface (TLI), Transport Independent Remote Procedure Calls (TI-RPCs) oraz Windows Sockets (WinSock). Na koniec opiszemy rolę zdalnych wywołań procedur (RPC — Remote Procedure Call) w sieciach rozproszonych globalnie.

Przegląd portów

W procesie komunikacji samo wysłanie komunikatu do odbiorcy nie wystarczy. Na­daw­ca musi nie tylko zapewnić dostarczenie komunikatu do zamierzonego odbiorcy, lecz również dostarczyć go do określonego — spośród wszystkich procesów odbiorcy — procesu, który zainicjował łączność po stronie nadawcy. Protokoły sieciowe umożliwia­ją taką łączność dwupunktową pomiędzy użytkownikiem i aplikacją, lub pomiędzy dwie­ma aplikacjami, za pomocą portów i gniazd.

Odbiorcą komunikatu może być inny węzeł lub usługa działająca w tym samym węźle.

Port jest interfejsem pomiędzy aplikacją i siecią, w której ta aplikacja działa. Inaczej mówiąc, port stanowi punkt końcowy komunikacji, dzięki któremu aplikacja, użytkownik końcowy lub inny węzeł w sieci uzyskuje połączenie z aplikacją. W sieciach opartych na protokole TCP/IP każda aplikacja, która chce komunikować się z inną równorzędną aplikacją działającą w innym węźle, musi używać numeru portu.

Numery portów są podobne do wewnętrznych numerów telefonicznych. Aby połączyć się z głównym budynkiem biura, wybieramy numer do firmy, a następnie wewnętrzny, aby połączyć się z określoną osobą w firmie. Adres IP możemy porównać do numeru biura. Każda usługa działająca w węźle posiada stały numer portu — „numer wewnętrzny” — pod którym możemy uzyskać dostęp do usługi.

Numer portu jest liczbą szesnastobitową z zakresu od 0 do 65535. Ogólnie, na potrzeby popularnych usług komunikacyjnych używane są numery portów poniżej 1024. Wartości powyżej 1024 zarezerwowane są tylko na potrzeby węzła. Większość portów serwerów stosuje numery poniżej 1024.; praktyka ta wywodzi się z wczesnej historii systemu Unix, który zezwalał na wiązanie z portami o numerach poniżej 1024. jedynie procesów użytkownika uprzywilejowanego (root).

Jeśli port serwera jest już w użytku, kolejnym żądaniom przypisywane są tymczasowe numery portów. Załóżmy, że węzeł odbiera wiele żądań FTP. W tym przypadku tylko jeden węzeł żądający usługi może łączyć się z usługą FTP na porcie 21., który jest domyślnym portem dla FTP. Innym węzłom równocześnie żądającym dostępu przydzielane są numery portów powyżej 1024. W ten sposób wiele klientów może korzystać jednocześnie z usługi FTP. Programiści systemowi i sieciowi mogą też używać portów powyżej 1024. na potrzeby własnych aplikacji.

Większość systemów operacyjnych utrzymuje plik zawierający numery portów i odpowiadające im usługi. Jednakże wartości numerów portów mogą ulegać zmianom, w zależności od platformy programowej i sprzętowej, na której uruchomione jest oprogramowanie TCP.

Większość aplikacji TCP/IP używa w komunikacji modelu klient-serwer. Po stronie użytkownika klient wysyła żądanie określonej usługi poprzez jej port w serwerze, po czym serwer odpowiada na żądanie. Gdy połączenie nawiązywane jest przez port przydzielony do określonego protokołu, wówczas odpowiadające mu usługi są wywoływane szybciej, dzięki czemu stosowanie numerów portów przyspiesza łączność TCP/IP.

Dobrze znane numery portów

Numery portów są zwykle dzielone na trzy kategorie:

• Dobrze znane numery portów (well-known port numbers) — ta nazwa odnosi się do portów od 0. do 1023. Organizacja IANA (Internet Assigned Numbers Authority) opublikowała listę często używanych numerów portów i odpowiadających im usług. Na przykład, FTP jest kojarzony z portem 21., Telnet z 23., SMTP (protokół poczty elektronicznej) z 25., serwery WWW z 80., a protokół POP3 z portem 110. Tabela 7.1 zawiera listę dobrze znanych numerów portów.

Tabela 7.1. Dobrze znane porty TCP/IP i ich numery

Numer portu	Usługa	Opis
1	tcpmux	Multiplekser portów usług TCP
7	echo	Echo
11	systat	Active Users
13	daytime	Daytime (RFC 867)
17	qotd	Cytat dnia
18	msp	Message Send Protocol
19	chargen	Generator znaków
20	ftp-data	Transfer plików — dane
21	ftp	Transfer plików — sterowanie
22	ssh	Protokół logowania zdalnego SSH
23	telnet	Telnet
25	smtp	Simple Mail Transfer
31	msg-auth	Uwierzytelnianie MSG
37	time	Czas
41	graphics	Obsługa grafiki
42	name	Serwer nazw hostów
43	nickname	Who Is
49	tacacs	Login Host Protocol (TACACS)
53	domain	DNS
67	bootps	Bootstrap Protocol Server
68	bootpc	Bootstrap Protocol Client
69	tftp	Trivial File Transfer Protocol
70	gopher	Gopher
79	finger	Finger
80	http	World Wide Web HTTP
101	hostname	Serwer nazw hostów NIC
103	gppitnp	Genesis Point-to-Point Trans Net
107	rtelnet	Usługa Remote Telnet
109	pop2	Post Office Protocol — wersja 2
110	pop3	Post Office Protocol — wersja 3
111	sunrpc	SUN Remote Procedure Call

Tabela 7.1. Dobrze znane porty TCP/IP i ich numery (ciąg dalszy)

Numer portu		Usługa	Opis
119		nntp	Network News Transfer Protocol
123		ntp	Network Time Protocol
137		netbios-ns	Usługa nazewnicza NETBIOS
138		netbios-dgm	Usługa datagramów NETBIOS
139		netbios-ssn	Usługa sesji NETBIOS
143		imap	Internet Message Access Protocol
161		snmp	SNMP
162		snmptrap	SNMPTRAP
163		cmip-man	CMIP/TCP Manager
164		cmip-agent	CMIP/TCP Agent
165		xns-courier	Xerox
179		bgp	Border Gateway Protocol
194		irc	Internet Relay Chat Protocol
199		smux	SMUX
201		at-rtmp	AppleTalk — utrzymanie tras
202		at-nbp	AppleTalk — powiązanie nazw
209		qmtp	Quick Mail Transfer Protocol
213		ipx	IPX
372		ulistproc	ListProcessor
444		snpp	Simple Network Paging Protocol
465		urd	URL Rendesvous Directory dla SSM
465		igmpv3lite	IGMP przez UDP dla SSM
487		saft	Simple Asynchronous File Transfer
512		exec	Zdalne wykonywanie procesów
513		login	Zdalny login ŕ la Telnet
515		printer	kolejkowanie drukowania
517		talk	talk
531		conference	chat
533		netwall	Dla rozgłoszeń awaryjnych
765		webster	Słownik sieciowy
873		rsync	rsync
1080		socks	Socks
	Numery portów przydzielone przez IANA są unikatowe. Inna usługa (lub protokół) nie może używać numeru portu przydzielonego do usługi lub do odpowiadającego jej protokołu.

• Zarejestrowane numery portów — ta nazwa dotyczy numerów portów od 1024. do 49151.

• Prywatne numery portów — numery portów od 49152. do 65535. (czasami nazywane są też dynamicznymi numerami portów).

Pełna lista numerów portów dostępna jest pod adresem www.iana.org/ assignments/port-numbers. Dodatkowe informacje o portach można znaleźć w dokumentach RFC 1700 i 793.

Gniazda — wprowadzenie

Gniazdo (socket) jest mechanizmem komunikacji między procesami, służącym jako punkt końcowy połączenia. Gniazdo stanowi połączenie adresu IP z numerem portu TCP. Jest to podstawowy element łączności w sieciach TCP/IP, z których tworzony jest szkielet komunikacji pomiędzy procesami wykonywanymi w tym samym hoście lub w różnych węzłach sieci. Dzięki zastosowaniu gniazd każde połączenie klient-serwer jest unikatowe i nie trzeba zapisywać danych na dysku odbiorcy podczas każdej transakcji — zamiast tego dane składowane są tymczasowo w pamięci podręcznej bufora odbiorcy.

Ponieważ numer portu dla danej usługi oraz adres IP węzła są unikatowe, numery gniazd również są unikatowe.

Gniazda funkcjonują w obrębie domeny komunikacyjnej (lub po prostu domeny). Na tę domenę składają się struktura adresowania i zestaw protokołów implementujących różne typy gniazd. Gniazda zasadniczo tworzą trzy domeny — domenę internetową, domenę uniksową i domenę NS. Chociaż pakiet protokołów TCP/IP może obsługiwać wszystkie trzy domeny, najczęściej używana jest domena internetowa. W tej domenie gniazdo może należeć do jednego z dwóch typów: gniazd potokowych i gniazd datagramów. Ponieważ gniazda potokowe są oparte na protokole TCP, zapewniają transmisję danych zorientowaną na połączenie, dwukierunkową, wiarygodną, sekwencyjną i nie powielaną. W przeciwieństwie do nich, gniazda datagramów oferują wymianę danych bezpołączeniową, dwukierunkową, nie gwarantowaną, która nie zapewnia porządkowania i może w niej występować powielanie.

Dwukierunkowa łączność oparta na gniazdach

Gdy węzeł wysyła w sieci TCP/IP żądanie połączenia z innym węzłem, wysyła również numer gniazda. Jeśli węzeł odbiorcy może nawiązać połączenie, zwraca numer gniazda zawierający adres IP odbiorcy i numer portu usługi, która będzie obsługiwać żądanie. Proces ten nosi nazwę wiązania (binding).

Analogią komunikacji opartej na gniazdach jest łączność telefoniczna. Podobnie jak telefon, gniazdo stanowi punkt końcowy dwukierunkowej łączności, gdy połączymy dwa gniazda, pozwoli to przesyłać dane pomiędzy dwoma procesami, które mogą działać w różnych węzłach (komputerach).

Po nawiązaniu połączenia między dwoma punktami, a przed wymianą danych, oba punkty końcowe dokonują wymiany swoich tożsamości. Informacje te są przechowywane po obu stronach, aby można było odwołać się do nich w dowolnej chwili podczas transmisji. Zapobiega to generowaniu dużego, niepotrzebnego ruchu w sieci, który powstawałby podczas przesyłania z każdym pakietem danych tożsamości gniazda nadającego.

Każdy węzeł może żądać od węzła docelowego więcej niż jednego połączenia. W takim przypadku węzeł-nadawca musi użyć różnych numerów portów do utworzenia odrębnych gniazd. Dzięki temu proces żądający połączenia nie musi czekać aż odbiorca obsłuży wcześniejsze żądania.

Gdy aplikacja klienta łączy się z usługą dostępną w serwerze, wówczas używa portu hosta klienta. Klient, aby uzyskać dostęp do usługi w serwerze, musi postąpić zgodnie ze standardowym procesem „powiąż-słuchaj-połącz-zaakceptuj” (bind-listen-connect-
-accept). Proces ten przebiega według następującego scenariusza:

1. Proces serwera wiąże się z określonym portem.

2. Po powiązaniu z portem proces serwera zaczyna nasłuchiwać na tym porcie żądań klientów.

3. Proces klienta żądający od serwera usługi wiąże się z dostępnym portem w hoście-kliencie.

4. Klient używa tego portu, aby wysłać żądanie połączenia z serwerem przez odpowiadający usłudze port serwera.

5. Proces serwera akceptuje połączenie i powiadamia klienta, by ten rozpoczął transakcję.

Opisany proces dwukierunkowej łączności jest przedstawiony na rysunku 7.1.

Gniazda są w wysokim stopniu zależne od systemu i programowalne. W interfejsie sieciowym gniazda implementowane są jako złącza programowe aplikacji (API — Application Programming Interface). Złącza API stanowią łącze pomiędzy protokołami warstwy sieciowej i programami warstwy aplikacji na potrzeby funkcjonalności sieci. API pozwalają również programistom systemów na wykorzystanie zasobów komputera: interfejsu graficznego, systemu plików, systemów baz danych i oczywiście systemu sieci komputerowej.

Gniazda są implementowane na poziomie sprzętowym, więc są zależne od systemu.

Chociaż gniazda są zależne od systemu, złącza API gniazd powinny obsługiwać trzy podstawowe właściwości: przezroczystość dla protokołu warstwy sieciowej, pracę asynchroniczną i sterowanie szybkością przesyłu danych. Przezroczystość dla protokołu warstwy sieciowej oznacza, iż gniazda powinny być niezależne od protokołów warstwy


Rysunek 7.1. Proces „powiąż- -słuchaj-połącz- -zaakceptuj”

sieciowej, z których korzystają. Praca asynchroniczna oznacza, że funkcje API powinny być wywoływane przez zdarzenia, a nie sekwencyjnie. Ponadto API gniazd powinny zapewniać wystarczające szybkości przesyłu danych pomiędzy dwoma uczestnikami łączności, by nie powodować opóźnień. Do popularnych API gniazd należą:

• gniazda Berkeley,

• TLI (Transport Layer Interface — interfejs warstwy transportu),

• TI-RCPs (Transport Independent Remote Procedure Calls — niezależne od transportu zdalne wywołania procedur),

• WinSock (Windows Sockets — gniazda systemu Windows).

Gniazda i TLI oferują praktycznie taką samą funkcjonalność (dostęp do protokołów TCP i UDP) i wykluczają się wzajemnie, aczkolwiek programista systemowy może napisać obsługujący oba standardy program skompilowany warunkowo. Złącza API RPC obsługują sieciowe podprogramy standardowe za pomocą protokołu RPS firmy Sun. Systemy Microsoft Windows oferują podobne do gniazd złącze API o nazwie WinSock.

Dodatkowe informacje o gniazdach można znaleźć w dokumentach RFC 204, 1323 i 2292.

Gniazda Berkeley

Interfejs gniazd Berkeley został opracowany w University of California w Berkeley na potrzeby wersji 4.1c BSD (Berkeley Software Distribution). Był to prosty interfejs, używany początkowo w różnych wersjach systemu Unix: SCO, Linux i SunOS. Z czasem został też zawarty w Windows 9x, Windows NT, NetWare i innych systemach operacyjnych. Gniazda Berkeley oferują umiarkowane szybkości przesyłu danych, ponieważ nie obsługują nakładających się funkcji wejścia-wyjścia. Dlatego interfejs sieciowy gniazd Berkeley najlepiej nadaje się do wieloprocesorowych sieciowych systemów operacyjnych.

Gniazda Berkeley są popularnie nazywane gniazdami BSD.

Gniazda Berkeley dają interfejs łatwy w użyciu; łatwo je też zaimplementować. Aplikacje, które korzystają z gniazd Berkeley mogą łączyć się z sieciowymi usługami transportowymi na dwa sposoby:

• Dostęp zorientowany na połączenie — pomiędzy nadawcą i odbiorcą utrzymywany jest kanał wirtualny. W zależności od rezultatu transmisji, używane są potwierdzenia i potwierdzenia negatywne. W przypadku, gdy dane nie zostaną dostarczone do odbiorcy, inicjowana jest retransmisja danych albo wyższe warstwy zostają powiadomione o niepowodzeniu, po czym warstwy te mogą podjąć niezbędne czynności korekcyjne. Usługi zorientowane na połączenie są obsługiwane przez TCP.

• Dostęp bezpołączeniowy — dane wysyłane są do odbiorcy bez czekania na potwierdzenie. Jeśli dane (lub ich część) zostaną utracone w trakcie transmisji, nadawca nie będzie o tym wiedział. Usługi bezpołączeniowe są realizowane przez protokół UDP.

Protokoły typu SMTP (Simple Mail Transfer Protocol) oparte są na TCP, natomiast protokoły takie jak Echo mogą korzystać zarówno z TCP, jak i UDP. Inne protokoły, jak np. SNMP (Simple Network Management Protocol), w pełni opierają się na UDP.

Z programistycznego punktu widzenia gniazda tworzone są za pomocą funkcji socket(), która wymaga dwóch kluczowych argumentów — domeny i typu. W sieciach TCP/IP najczęściej używaną domeną jest PF_NET (chociaż istnieją też inne). Dwa podstawowe typy gniazd internetowych to STREAM (potok, dla TCP) oraz DGRAM (datagram, dla UDP). Gniazda STREAM nie mogą wysyłać i odbierać danych bez nawiązania połączenia, zaś gniazda DGRAM mogą przesyłać dane natychmiast.

W komunikacji TCP zorientowanej na połączenie nadawca używa funkcji send() do wyszczególnienia adresu IP i numeru portu odbiorcy do utworzenia aktywnego gniazda, co inicjalizuje połączenie TCP. Odbiorca, czekając na połączenie, używa funkcji listen() i bind(). Po wykryciu nadesłanego żądania odbiorca używa funkcji accept(), aby zaakceptować połączenie i utworzyć aktywne gniazdo.

W bezpołączeniowej komunikacji UDP nadawca tworzy gniazda DGRAM i wysyła pakiety UDP za pomocą funkcji sendto(). Aby odebrać pakiet, adresat dołącza gniazdo do lokalnego numeru portu za pomocą funkcji bind(). Po dołączeniu pakietu do portu UDP gniazdo może służyć do wysyłania pakietów (za pomocą funkcji sendto()) oraz ich odbierania (za pomocą rcvfrom()).

Dodatkowe informacje o gniazdach Berkeley można znaleźć w dokumentach RFC 793 i 1122.

Transport Layer Interface

API TLI (Transport Layer Interface) udostępnia niezależny od protokołu interfejs dostępu do zasobów sieciowych z warstwy transportowej. TLI został wprowadzony przez Bell Labs pod koniec lat 80. w systemie AT&T UNIX System V Release 3 (UNI SVR3). Interfejs ten został opracowany na potrzeby rozproszonych aplikacji działających na różnych platformach. Do opracowania TLI w Bell Labs wykorzystano w roli modelu warstwę transportową modelu OSI, dzięki czemu TLI jest w pełni zgodny z usługami transportowymi OSI. Jest to też główny powód, dla którego TLI deklaruje wyższość nad gniazdami (nie funkcjonującymi w środowisku OSI). Interfejs TLI może obsługiwać TCP/ UDP, IPX/SPX i inne protokoły warstwy transportowej.

Chociaż TLI jest interfejsem API warstwy transportowej, udostępnia niemal identyczną funkcjonalność jak gniazda Berkeley i może współpracować z usługami opartymi na gniazdach oraz IP. Jednakże w przeciwieństwie do gniazd Berkeley, usługi oparte na TLI mają bezpośredni dostęp do danych wysyłanych lub odbieranych w trakcie transmisji. Do komunikacji z połączeniem sieciowym muszą one używać serwerów baz danych lub plików, w wyniku czego interfejs TLI nie jest tak powszechnie akceptowany jak gniazda Berkeley.

TLI zaczyna powoli zyskiwać na popularności. Większość systemów operacyjnych, a szczególnie Unix, obsługuje zarówno gniazda, jak i TLI. Wielu producentów preferuje jednak interfejs TLI z uwagi na szybkie, wiarygodne transakcje i zgodność z protokołami OSI — na przykład, w systemach Unix SRV4 i Solaris 2.x firmy Sun TLI jest preferowanym interfejsem transportowym. TLI był zawsze interfejsem faworyzowanym we wszystkich wersjach Novell NetWare. Dodatkowe informacje o TLI można znaleźć w RFC 1122.

Podczas transakcji TLI tworzy punkty końcowe transportu, którymi można łatwo manipulować za pomocą funkcji analogicznych do funkcji gniazd. Interfejs TLI i gniazda Berkeley różnią się jedynie składnią.

Niedawno pojawiło się rozszerzenie TLI — X/OPEN Transport Interface (XTI). Interfejs XTI został opracowany w roku 1996 przez X/Open Company, Ltd. jako ulepszenie istniejącego interfejsu TLI. Poza obsługą tradycyjnych pakietów TCP/IP oraz IPX/SPX, interfejs XTI pozwala na dostęp do pakietów NetBIOS. Dodatkowe informacje o XTI można znaleźć pod adresem: www.tru64unix.compq.com/faqs/publications/base_doc/DOCUMENTATION/ HTML/AA-PS2WD-TET1_html/netprog4.html.

Transport Independent Remote Procedure Call

Transport Independent Remote Procedure Call (TI-RPC) jest najnowszym dziełem w dziedzinie zdalnych wywołań procedur (RPC). TI-RPC umożliwia gładkie przejście z jednego protokołu na drugi, oddzielając protokół mieszczący się poniżej, w warstwie sieciowej. Zdolność ta uniezależnia specyfikację RPC od transportu.

TI-RPC wprowadza warstwową strukturę RPC, w której API RPC podzielone są na różne poziomy:

• Poziom uproszczony (Simplified Level) — wszystkie wywołania API połączone są w jedną procedurę. Wprawdzie nie wolno dostosowywać klientów ani usług, lecz można opracować usługę RPC i odpowiadającą jej aplikację klienta.

• Poziom najwyższy (Top Level) — klienty i usługi mogą być łatwo modyfikowane w zależności od potrzeb. Parametry są bardzo podobne do używanych w poziomie uproszczonym.

• Poziom średni (Intermediate Level) — na tym poziomie zaczyna się rozróżnienie pomiędzy warstwami, co pozwala na wyższy stopień modyfikacji i kontroli nad transportem.

• Poziom ekspercki (Expert Level) — najniższy poziom dostępnych API TI-RPC. Możliwości dostosowania klientów i usług są na nim znacznie większe — dostępna jest kontrola nad transportem, rozmiarami buforów i innymi drobnymi szczegółami aplikacji.

Poziom ekspercki TI-RPC używa złączy API tłumaczenia nazw na adresy, które udostępniają interfejs podobny do wywołań gniazd.

Można używać innych API, w połączeniu z wszystkimi poziomami z wyjątkiem uproszczonego. Udostępniają one metody zwracania błędów od usługi do klienta, zwalniania przestrzeni pamięci przydzielonej do klientów i usług oraz ulepszone metody wykrywania i zgłaszania błędów.

Dodatkowe informacje o TI-RPC można znaleźć w dokumentach RFC 1057, 1058 i 2292.

WinSock

W środowisku Windows używa się gniazd Windows (Windows Sockets — WinSock), będących odmianą gniazd Berkeley. Microsoft wprowadził na rynek WinSock API (WSA) w styczniu 1993 r. jako interfejs do tworzenia w środowisku Windows uniwersalnych aplikacji opartych na TCP/IP. Początkowo WinSock API koncentrował się jedynie na TCP/IP, chociaż mógł obsługiwać inne pakiety protokołów. Druga, ulepszona wersja WinSock (WinSock Version 2) została wydana w połowie 1995 r. Wersja ta obsługuje o wiele więcej pakietów protokołów — na przykład, IPX/SPX, ATM, DECnet i tak dalej. WinSock 2 zapewnia też pełną zgodność wstecz z wcześniejszą wersją WinSock (1.1) i pozwala tworzyć aplikacje niezależne od protokołu sieciowego.

WinSock to biblioteka procedur, wywołań funkcji i struktur danych, która jest standardowym interfejsem dla aplikacji opartych na systemie Windows. Aplikacja WinSock 2 może wybierać protokół w zależności od wymagań usługi. Korzystając z mechanizmów udostępnionych przez WinSock 2, aplikacja może również dostosowywać się do różnic w sieciowych schematach nazw i adresowania.

Ponieważ WinSock opiera się na oryginalnych gniazdach Berkeley, łączność przez WinSock przypomina łączność przez gniazda Berkeley. Gniazda WinSock, podobnie jak Berkeley, tworzone są za pomocą funkcji socket(), która przyjmuje jako argumenty domenę i typ. W Internecie oraz sieciach opartych na TCP/IP najczęściej spotykaną domeną jest AF_NET. Argument typu może przybrać jedną z dwóch wartości — SOCK_STREAM (dla komunikacji opartej na TCP) lub SOCK_DGRAM (dla komunikacji opartej na UDP).

Dodatkowe informacje o WinSock można znaleźć w RFC 1122.

Ponieważ coraz więcej organizacji staje się obecnych na skalę globalną, zasięg sieci również się zwiększa. Obecnie sieć przedsiębiorstwa może nie ograniczać się do miasta czy nawet kraju. Sieci rozciągają się na cały świat. Tego typu sieci noszą nazwę systemów rozproszonych lub intranetów. Ponadto, pojedynczy intranet nie musi w całości używać wspólnej platformy, typu komputery lub aplikacje. Platformy — zarówno sprzętowe, jak i programowe — mogą być tak różnorodne, jak tylko się da. Rozproszony charakter sieci wymógł pojawienie się oprogramowania rozproszonego (na przykład sieciowych usług katalogowych i rozproszonych baz danych). Potrzeba funkcjonowania rozproszonego oprogramowania na różnorodnych procesorach i pod różnymi systemami operacyjnymi doprowadziła do opracowania zdalnych wywołań procedur (RPC — Remote Procedure Call).

RPC

Zdalne wywołania procedur (RPC), opracowane w CERN (Center for Nuclear Research), są metodą budowania rozproszonych aplikacji i systemów opartych na modelu klient-serwer. RPC pozwala aplikacji uruchomionej w jednym komputerze wywołać podprogram standardowy, który może wykonywać się w odległym komputerze. Wywołująca go aplikacja nawet nie „wie”, iż podprogram jest zdalny. Inaczej mówiąc, RPC jest metodą korzystania w sposób przezroczysty z istniejących środków komunikacji.

Podprogram standardowy jest częścią programu, wykonującą określone zadanie lub uporządkowany zbiór zadań.

RPC nie zawiera żadnego kodu związanego z komunikacją, w wyniku czego jest niezależne od:

• platform i sprzętu komunikacyjnego,

• protokołów komunikacyjnych,

• systemów operacyjnych,

• sekwencji wywołań, które musiałyby korzystać z oprogramowania komunikacyjnego.

Niezależność od interfejsu izoluje rozproszone aplikacje oparte na RPC od fizycznych i logicznych aspektów przesyłu danych i pozwala aplikacjom korzystać z różnych modeli transportu danych. Pozwala też programistom tworzącym aplikacje rozproszone ignorować szczegóły interfejsu w trakcie pisania programu. Dzięki tym cechom RPC model środowisk komputerowych klient-serwer staje się bardziej efektywny i łatwiejszy do oprogramowania.

Idea RPC została pomyślnie wdrożona w wielu typach aplikacji. Aplikacjami, które dość wcześnie zaczęły korzystać z RPC, były zdalne serwery plików i baz danych. Sun Network File System firmy Sun Microsystems używa RPC Sun XDR. Aplikacje zdalnego monitorowania, na przykład GKS, oraz aplikacje zdalnego zarządzania zadaniami programowymi używane w komputerach VAX również korzystają z RPC.

Gdy zostaje wygenerowane zdalne wywołanie podprogramu standardowego, program wywołujący nazywany jest klientem, zaś wywołany podprogram gra rolę serwera tworzącego moduły namiastkowe. Klient i serwer potrzebują nazw procedur, zaangażowanych w transakcję, liczby parametrów, które zostaną przekazane, oraz typu danych każdego parametru. Gdy serwer jest wywoływany przez klienta, RPC sprawia, że:

• wszystkie parametry przeznaczone do przekazania do serwera zostają przesłane do odległego komputera, w którym wykonuje się podprogram standardowy,

• wykonuje się podprogram w odległym komputerze,

• wyniki i parametry będące rezultatem wykonania podprogramu zostają przekazane z powrotem do klienta (wywołującego program).

RPC do łączności pomiędzy serwerem i klientem stosuje moduły namiastkowe (stub module). Namiastka jest podprogramem, który przypomina zdalne podprogramy standardowe. Namiastki nie zawierają żadnych informacji związanych z fizycznymi adresami komputerów zaangażowanych w transakcję, wobec czego w celu znalezienia komputera docelowego używają systemu wykonawczego (RTS) RPC. Ponieważ system wykonawczy RPC zajmuje się całą komunikacją, moduł namiastkowy zawiera jedynie kod związany z aplikacją, która zainicjowała zdalne wywołanie. Cały proces komunikacji przebiega następująco:

1. Program klienta zostaje powiązany z modułem namiastkowym klienta, który jest podprogramem przyjmującym dane z procesu wywołującego i zamykającym je w komunikacie. Ten proces nosi nazwę zestawiania (marshalling).

6. Moduł namiastkowy klienta wysyła komunikat do serwera (procesu) za pomocą procedury w systemie wykonawczym RPC i wchodzi natychmiast w tryb oczekiwania; czeka na komunikat odpowiedzi od modułu namiastkowego serwera, znajdującego się w odległym komputerze.

7. System wykonawczy RPC powiadamia moduł namiastkowy serwera o otrzymaniu komunikatu od klienta. Moduł namiastkowy serwera rozmontowuje (unmarshall) parametry otrzymane w komunikacie, wywołuje docelowy podprogram standardowy i czeka na wyniki od serwera (procesu).

8. Serwer po ukończeniu wykonywania podprogramu zwraca parametry wynikowe do modułu namiastkowego serwera. Ten z kolei zestawia zwrócone parametry w komunikat i wysyła go do modułu namiastkowego klienta.

9. Po odebraniu odpowiedzi moduł namiastkowy serwera rozmontowuje zwrócone parametry, wywołuje proces klienta jako zwykłą procedurę i zamienia wartości na zmienne programu wywołującego.

Po stronie klienta program wywołujący pozostaje uśpiony, dopóki nie otrzyma wyniku od wywołanego podprogramu standardowego. Po otrzymaniu oczekiwanych parametrów proces klienta podejmuje na nowo wykonanie. Natomiast po wysłaniu wyników w stan uśpienia wchodzi podprogram standardowy. Rysunek 7.2 przedstawia cały proces komunikacji.

	Chociaż proces klienta pozostaje uśpiony w trakcie oczekiwania na parametry od serwera, sam klient nie jest uśpiony i może wykonywać inne zadania w trakcie oczekiwania. Dzięki temu wywołania RPC są asynchroniczne.
Rysunek 7.2. Łączność sieciowa za pomocą RPC

Do poznania wszystkich usług RPC zarejestrowanych w określonym hoście i ich adresów możemy użyć polecenia powłoki rpcinfo. Polecenie to może też posłużyć do ustalenia bieżących informacji o rejestracji RPC. Administratorzy mogą dzięki tym informacjom usuwać wszelkie nadmiarowe, przestarzałe lub bezużyteczne usługi i rejestracje. Polecenia rpcinfo możemy również użyć, aby „pingować” programy uruchomione w komputerze i ustalić, czy odpowiedź została otrzymana, czy nie, co z kolei pomaga w ustaleniu, czy odległy komputer się zawiesił. Wyniki polecenia rpcinfo przedstawia rysunek 7.3.

Rysunek 7.3. Okno polecenia rpcinfo

RPC wykorzystuje komunikację pomiędzy najwyższą warstwą modelu OSI — warstwą aplikacji a niższymi warstwami zajmującymi się rozproszoną naturą ogólnoświatowego intranetu. RPC pełni podobną funkcję w stosunku do wyższych warstw, jak usługi transportowe dla niższych. Obecnie trwają prace nad uczynieniem standardu z RPC.

Dodatkowe informacje o RPC można znaleźć w dokumentach RFC 1050, 1057, 1700 i 1831.

156 Część I Wprowadzenie do transmisji TCP/IP

Rozdział 7. Warstwa aplikacji 157

---