Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Сетевые средства операционных систем. Учебное пособие
.pdf
Ларина Т.Б. Сетевые средства операционных систем
61
Запрос на установление соединения с сервером.
Системный вызов Сonnect
Системный вызов Сonnect используется клиентом для
установления логического соединения с сервером через потоковый
сокет.
Сonnect выполняет внутри себя настройку сокета на
произвольно выбранный операционной системой порт и любой
сетевой интерфейс узла. То есть, по сути это вызов Bind с нулевым
номером порта и IP-адресом, равным INADDR_ANY.
int connect ( sockd, struct sockaddr *servaddr, addrlen)
Параметры вызова:
int sockd - дескриптор потокового сокета клиента, созданный
вызовом socket();
*servaddr - указатель на структуру данных sockaddr_in,
содержащую полный адрес процесса-сервера;
int addrlen - фактический размер структуры данных с адресом.
Его можно вычислить, как sizeof (struct sockaddr_in).
Cистемный вызов будет завершен только после установления
соединения или по истечении установленного предельного времени
ожидания timeout.
При нормальном завершении вызов возвращает 0 и
отрицательное значение при возникновении ошибки.
Ожидание установления соединения. Системный вызов
Listen
Системный вызов Listen используется только процессомсервером при взаимодействии через потоковые сокеты.
Он переводит сокет сервера в пассивное (слушающее)
состояние и создает очереди для порождаемых при установлении
соединения «присоединенных» сокетов. Присоединенные сокеты
Ларина Т.Б. Сетевые средства операционных систем
62
могут находиться в состоянии «не полностью установленного
соединения» и «полностью установленного соединения».
int listen( sockd, backlog)
Параметры вызова:
int sockd - дескриптор сокета, созданный системным вызовом
socket(). Настройка этого сокета должна быть выполнена системным
вызовом bind();
int backlog - максимальный размер очередей для
«присоединенных» сокетов, находящихся в состояниях полностью и не
полностью установленных соединений.
Системный вызов возвращает значение 0 при нормальном
завершении и значение -1 при возникновении ошибки.
Прием запросов на установление соединения.
Системный вызов Аccept()
Через системный вызов Accept сервер получает информацию о
полностью установленных соединениях и адресах процессов-клиентов,
установивших соединение.
Если очередь полностью установленных соединений не пустая,
вызов возвращает дескриптор первого присоединенного сокета в
очереди, одновременно удаляя его из очереди. Если очередь пуста, то
вызов ожидает появления полностью установленного соединения.
int accept( sockd, struct sockaddr *cliaddr, *clilen)
Параметры вызова:
int sockd - дескриптор сокета, через который будет
ожидаться установление соединения. Предварительно сокет должен
быть создан вызовом socket, настроен вызовом bind и переведен в
слушающий режим вызовом listen;
*cliaddr - указатель на структуру, в которую при
необходимости будет занесен адрес сокета клиента, установившего
соединение;
Ларина Т.Б. Сетевые средства операционных систем
63
*clilen - указатель на целую переменную, содержащую
максимально допустимую длину адреса сокета клиента. После вызова
там будет находиться фактическая длина адреса клиента.
Если сервер не интересует, кто с ним соединился, то вместо
второго и третьего параметров можно указать значение NULL .
Системный вызов возвращает при нормальном завершении
дескриптор присоединенного сокета для последующего общения
клиента и сервера, и значение -1 при возникновении ошибки.
Закрытие сокета. Системные вызовы Close и Shutdown
Системный вызов Close просто закрывает сокетный
коммуникационный узел.
Системный вызов Shutdown закрывает сокет и сбрасывает
системные буферы, где еще могут остаться данные.
int close ( sockd)
int shutdown (sockd, how)
Параметры:
int sockd - дескриптор сокета;
int how – признак: 2- сбросить все данные, 1 – только данные
для посылки, 0 – только данные для чтения.
Сетевой порядок байтов. Функции преобразования порядка
Сетевой порядок байтов - это унифицированный порядок байт, в
котором должно представляться многобайтное целое число в процессе
передачи по сети.
Целые числа должны переводиться процессом-отправителем в
сетевой порядок байт. Процессом-получателем они переводятся из
сетевого порядка в машинно-зависимый числовой формат.
Для преобразования используются четыре функции:
Ларина Т.Б. Сетевые средства операционных систем
64
htons(n) – преобразует порядок байт в 16-разрядном числе из
машинно-зависимого формата в сетевой.
htonl(n) - преобразует порядок байт в 32-разрядном числе из
машинно-зависимого формата в сетевой.
ntohs(n) – преобразует порядок байтов 16-разрядного
числового кода из сетевого формата в машинно-зависимый.
ntohl(n) - преобразует порядок байтов 32-разрядного числового
кода из сетевого формата в машинно-зависимый.
Параметр вызова функций n – это преобразуемое значение.
Функции преобразования IP-адресов
Переводят IP-адрес из символьного представления в числовое
представление и обратно.
Функция inet_addr переводит символьный IP-адрес в числовое
представление в сетевом порядке байт.
int inet_ addr ( *strptr, struct in_addr *addrptr)
Параметры:
char *strptr – указатель на строку символьного IP-адреса;
addrptr - адрес структуры struct in_addr, куда запишется IP-
адрес в сетевом порядке байт.
Функция возвращает значение 1, если символьный IP-адрес
задан правильно, и значение 0 - в противном случае.
Функция inet_ntoa переводит числовой IP-адрес, заданный в
сетевом порядке байт, в символьное «октетное» представление.
char *inet_ntoa (struct in_addr *addrptr)
Параметры:
addrptr - адрес структуры struct in_addr , где записан IP-адрес
в сетевом порядке байт.
Функция возвращает значение указателя на строку символьного
адреса.
Ларина Т.Б. Сетевые средства операционных систем
65
2 .2 Вызов удаленных процедур
Вызов удаленных процедур RPC (Remote Procedure Call)
обеспечивает интерфейс между программами-клиентами и комплексом
сервисных программ сервера («сервис RPC»), оформленных и
вызываемых, как процедуры.
Клиентское приложение отправляет запрос вызова процедуры
на сервер, сервер выполняет процедуру и возвращает результат
клиенту. Такие клиентские приложения называются RPCориентированными.
Цель механизма вызова удаленных процедур – сделать его
похожим на локальный вызов процедур, скрыв от программиста все
детали удаленного взаимодействия.
По своей функциональности в соответствии с моделью OSI
механизм RPC занимает уровни представления и сеансовый.
Теоретически, RPC не зависит от реализации сети, в частности, от
сетевых протоколов транспортного уровня.
Особенности удаленного вызова процедур
Реализация удаленных процедур существенно сложнее
локальных вызовов процедур:
1. Текущий процесс и вызываемая им процедура не имеют
общей памяти – они выполняются на разных компьютерах.
Следовательно, значения параметров вызова должны передаваться по
сети и не содержать адресов памяти.
2. Хотя механизм RPC базируется на системе обмена
сообщениями, это не отражается в программном интерфейсе.
3. В удаленной процедуре участвуют два процесса на
разных узлах - клиентский процесс и серверный процесс (рис.2-4).
Процесс клиента отправляет серверу сообщение с параметрами
вызываемой процедуры и ожидает ответного сообщения с
Ларина Т.Б. Сетевые средства операционных систем
66
результатами. При получении ответа результат считывается, и процесс
продолжает работу.
Процесс-обработчик вызовов на сервере находится в состоянии
ожидания. При поступлении сообщения он считывает параметры
процедуры, выполняет ее, отправляет ответ и становится в состояние
ожидания следующего вызова.
Рис.2.4. Взаимодействие клиента и сервера процедур
.
4. RPC-протокол не требует синхронности выполняемых
функций.
Клиент во время ожидания ответа может выполнять другие
процедуры. Сервер RPC может выделять для каждой вызываемой
процедуры отдельный процесс или виртуальную машину и, не
дожидаясь окончания выполнения предыдущих запросов, может
принимать следующие запросы.
5. Обработка ошибок. Клиент в любом случае должен
получать уведомление об ошибках, возникающих при вызовах
удаленных процедур на сервере или в сети.
6. Скорость выполнения удаленных процедур, как правило,
на один или два порядка ниже скорости выполнения аналогичных
локальных процедур.
7. Поскольку вызовы удаленных процедур происходят по
сети, необходимо использовать механизмы аутентификации клиента.
Ларина Т.Б. Сетевые средства операционных систем
67
Клиентский и серверный стабы
При описании механизма RPC будем называть вызывающий
процесс – «клиентом», а удаленный процесс, реализующий процедуру,
«сервером».
По концепции механизма RPC вызов удаленной процедуры для
клиента должен максимально выглядеть, как вызов локальной
процедуры. Клиент не должен знать, что вызываемая процедура
находится на другой машине и наоборот. За счет чего это достигается?
В библиотеку процедур клиента вместо локальной реализации
кода процедуры помещается другая версия процедуры. Она называется
- клиентский стаб (stub — заглушка).
На удаленный компьютер (сервер процедур) помещается
настоящий код вызываемой процедуры, а также еще одна программа -
серверный стаб.
Назначение клиентского стаба - организовать передачу
параметров вызываемой процедуры по сети на сервер процедур, а
серверного стаба – возвратить результаты процедуры по сети
вызвавшему процедуру клиенту.
Для передачи данных по сети стабы используют средства
подсистемы обмена сообщениями операционной системы, то есть
пользуются примитивами передачи сообщений Send и Receive.
Иногда в подсистеме обмена сообщениями ОС создается
специальный программный модуль, организующий связь стабов с
примитивами передачи сообщений. Его называют модуль RPC
Runtime.
На рисунке 2-5 показана схема выполнения удаленного вызова
процедур по протоколу RPC.
Процесс-клиент делает вызов процедуры CALL, не подозревая,
что она удаленная. На самом деле происходит вызов «клиентского
стаба».
Клиентский стаб формирует сообщение-вызов для сети
определенного формата. Оно содержит имя вызываемой процедуры и
ее параметры. Эта операция называется «Упаковка параметров».
Ларина Т.Б. Сетевые средства операционных систем
68
Далее, клиентский стаб обращается к подсистеме обмена сообщениями
ОС для передачи этого сообщения удаленному серверу, на котором
размещена оригинальная процедура.
Рис.2-5. Выполнение удаленного вызова процедур
Серверный стаб для получения сообщения пользуется
примитивом Receive подсистемы обмена сообщениями серверной ОС.
Серверный стаб извлекает из принятого сообщения имя и параметры
вызова процедуры. Эта операция называется «Распаковка параметров».
Ларина Т.Б. Сетевые средства операционных систем
69
Далее он вызывает обычным образом соответствующую
локальную процедуру. После окончания работы процедуры (Return),
серверный стаб упаковывает ее результаты в сообщение-ответ и с
помощью примитива Send передает сообщение по сети клиентскому
стабу.
Клиентский стаб распаковывает результаты и возвращает их
обычным образом вызывающей процедуре.
Таким образом, заглушки составляют ядро системы RPC,
отвечая за формирование и передачу сообщений между клиентом и
удаленным сервером, где находится процедура. При этом и клиент и
сервер считают, что вызовы происходят локально.
В этом и состоит основная концепция RPC - полностью
спрятать распределенный (сетевой) характер взаимодействия в коде
заглушек.
Преимущества такого подхода очевидны: клиент и сервер
являются независимыми от сетевой реализации, оба они работают в
рамках некой распределенной виртуальной машины, и вызовы
процедур имеют стандартный интерфейс.
Генерация стабов
Стабы могут генерироваться вручную или автоматически.
В первом случае программист пользуется вспомогательными
функциями, которые ему предоставляет сервис RPC. Он получает
большую свободу в выборе способа передачи параметров вызова и
применении различных примитивов передачи сообщений. Однако,
этот способ связан с большим объемом ручного труда.
Автоматический способ основан на применении специального
языка определения интерфейса - IDL (Interface Definition Language).
С помощью этого языка программист описывает интерфейс
между приложением-клиентом и сервером RPC-процедур. Описание
включает список имен процедур, которые клиент может запросить у
сервера, и список типов аргументов и результатов этих процедур.
Ларина Т.Б. Сетевые средства операционных систем
70
После составления программистом описания его надо
откомпилировать специальным IDL-компилятором для конкретного
языка программирования.
В результате компиляции будут созданы:
- файлы исходных модулей клиентских и серверных стабов для
указанных в описании процедур;
- специальные файлы-заголовки с описанием типов процедур и
их аргументов.
Далее эти файлы могут включаться в любое приложение вместе
с обычными модулями, компилироваться и связываться в
исполняемую программу стандартными средствами инструментальной
системы программирования.
Формат сообщений RPC
Механизм RPC оперирует двумя типами сообщений:
сообщения-вызовы, с помощью которых клиент запрашивает у
сервера выполнение определенной удаленной процедуры и передает ее
аргументы;
сообщения-ответы, с помощью которых сервер возвращает
результат работы удаленной процедуры клиенту.
С помощью этих сообщений реализуется протокол RPC,
определяющий способ взаимодействия клиента с сервером.
Протокол RPC обычно не зависит от транспортных протоколов,
с помощью которых сообщения доставляются по сети. При
использовании стека протоколов TCP/IP это могут быть протоколы
TCP или UDP, в локальных сетях часто используется и другие
протоколы - NetBEUI/NetBIOS или IPX/SPX.
Типичный формат двух типов сообщений, используемых RPC,
показан ниже.
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]