tanenbaum_seti_all.pages (525408), страница 160
Текст из файла (страница 160)
В двух словах, если программе нужно найти !Р-алрос по имени хоста, например, валлч.сз.Ьвг!гв!ву.вс!и, она может послать ()ПР-пакет с этим именем на сервер !хгч8. Сервер в ответ на запрос посылает (Л)Р-пакет с !Р-адрссом хоста. Никакой предварительной настройки не требуется, как не требуется н разрыва соединения после завершения задачи. По сети просто передаются лва сообщения. Вызов удаленной процедуры В определенном смысле процессы отправки сообщения па удаленный хост и получения ответа очснь похожи на вызов функции в языке программирования. В обоих случаях необходимо передать один нли несколько параметров, и вы получастс результат.
Это соображение навело разработчиков на мысль о том, что можно попробовать организовать запросно-ответное взаимодействие по сети, выполняемое в форме вызовов процедур. Такое решение позволяет упростить и сделать более привычной разработку сетевых приложений. Например, представьте себе процедуру с именем уе1 !Р ассгеьз(иня хоста), работающую посредством отправки ()ПР-пакетов на сервер Е)ХЯ, ожидания ответа н отправки повторного запроса в случае наступления тайм-аута (если одна из сторон работает недостаточно быстро). Таким образом, все детали, связанные с особенностями сетевых технологий, скрыты от программиста.
Ключевая работа в этой области написана в 1984 году Бирреллом (В!ггс!!) и Нельсоном (Хс!зоп). По сути дела, было предложено разрешить программам вызывать процедуры, расположенные на удаленных хостах. Когда процесс на машннс 1 вызывает процедуру, находящуюся на ллашинс 2, вызываюн!ий процесс машины 1 блокируется и выполняется вызванная процедура на машине 2. Информация от вызывая>щего процесса может передаваться в виде параметров и приходить обратно в виде результата процедуры.
Передача сообщений по сети скрыта от программиста. Такая технология известна под названием КРС (!сешоге Ргосег!нгс Са!! — удаленный вызов процедуры) н стала основой многих сетевых приложений. Традиционно вызывающая процедура считается клиентом, а вызывасмая — сервером. Мы и алесь будем называть их так жс. Идея ЕРС состоит в том, чтобы сделать вызов улалспной процедуры максимально похожим на локальный вызов.
В простейшем случае лля вызова удаленной процелуры клиентская программа должна быть связана с маленькой библиотечной процедурой, называемой клиентской заглушкой, которая отображает серверную процедуру в пространство адресов клиента, Аналогично сервер должен быть связан с процедурой, называемой серверной заглушкой. Эти процедуры скрывают тот факт, что вызов клиентом серверной пропедуры осуществляется не локально.
Реальные шаги, выполняемь|е при удаленном вызове процедуры, показаны на рис. 6.19. Шаг 1 заключается в вызове клиентом клиентской заглулпки. Это ло- Транспортные протоколы Интернета: 00Р 601 кальный вызов процедуры, параметры которой самым обычным образом помещаются в стек. Шаг 2 состоит в упаковке параметров клиентской заглушки в сообщение и в осуществлении системного вызова для отправки этого сообщения. Упаковка параметров называется маршалингом. На шаге 3 ядро системы передает сообщение с клиентской машины па сервер, Шаг 4 заключается в том, что ядро передает входящий пакет серверной заглушке.
Последняя на пятом шаге вызывает серверную процедуру с демаршализованными параметрами. При ответе выполняются тс же самые шаги, но передача происходит в обратном направлении. Важнее всего здесь то, что клиентская процедура, написанная пользователем, выполняет обычный (то есть локальный) вызов клиентской заглушки, имеющей то же имя, что и серверная процедура.
Поскольку клиентская процедура и клиентская заглушка существуют в одном и том же адресном пространстве, параметры передаются обычным образом. Аналогично серверная процедура вызывается процедурой, находящейся в том же адресном пространстве, с ожидаемыми параметрами. С точки зрения серверной процедуры, не происходит ничего необычного, Таким образом, вместо ввода-вывода с помощью сокетов сетевая коммуникация осуществляется обычным выаовол1 процедуры. Несмотря на элегантность концепции КРС, в ней есть определенные подводные камни. Речь идет прежде всего об использовании указателей в качестве параметров.
В обычной ситуации передача указателя процедуре не представляет никаких сложностей. Вызываемая процедура может использовать указатель так же, как и вызывающая, поскольку они обе существуют в одном и том же виртуальном адресном пространстве. При удаленном вызове процедуры передача указателей невозможна, потому что здресныс пространства клиента и сервера различаются. Клиентский Серверный Процессор клиента П Р - УРР ° Процессор серве Сеть Рис. 6И 9. Этапы выполнения удаленного вызова процедуры. Заглушки затенены Иногда с помощью некоторых уловок все же удается передавать указатели. Допустим, первым параметром является указатель на целое число л.
Клиентская заглушка может выполнить маршализацию л и передать его серверу. Серверная 602 Глава 6. Транспортный уровень заглушка создаст указатель на полученную переменную я и передаст его серверной процедуре. Именно этого та и ожидала.
Когда серверная процедура возвращает управление серверной заглушке, последняя отправляет я обратно клиенту, где обновленное значение этой переменной записывается вместо старого (если оно было изменено сервером). В принципе, стандартная последовательность действий, выполняемая при вызове по ссылке, заменилась последовательностью копирования и восстановления. Увы, этот трюк не всегда удается применить — в частности, нельзя это сделать, если указатель ссылается на граф или иную сложную структуру данных. По этой причине на параметры удаленно вызываемых процедур должны бь1ть наложены определенные ограничения.
Вторая проблема заключается в том, что в языках со слабой типизацией данных (например, в С) можно совершенно законно написать процедуру, которая подсчитывает скалярное произведение двух векторов (массивов), не указывая их размеры. Каждая из этих структур в качестве ограничителя имеет какое-то значение, известное только вызывающей и вызываемой процедурам. При этих обстоятельствах клиентская заглушка не способна маршализовать параметры: нет никакой возможности определить их размеры. Третья проблема заключается в том, что не всегда можно распознать типы параметров по спецификации или по самому коду. В качестве примера можно привести процедуру рг1 пС1, у которой может быть любое число параметров (не меньше одного), и они могут представлять собой смесь целочисленных, коротких вещественных, длинных вешественных, символьных, строковых, вешественных с плавающей запятой различной длины и других типов.
Задача удаленного вызова процедуры рг1вст" может оказаться практически невыполнимой из-за такой своеобразной толерантности языка С. Тем не менее, нет правила, говорящего, что удаленный вызов процедур возможен только в том случае, если используется не С (С++), — это подорвало бы репутацию метода ВРС. Четвертая проблема связана с применением глобальных переменных. В нормалиной ситуации вызывающая и вызываемая процедуры могут общаться друг с другом посредством глобальных переменных (кроме общения с помошью параметров). Если вызываемая процедура переедет на удаленную машину, программа, использующая глобальные переменные, не сможет работать, потому что глобальные переменные больше не смогут служить в качестве разделяемого ресурса. Эти проблемы не означают, что метод удаленного вызова процедур безнадежен. На самом деле, он широко используется, просто нужны некоторые ограничения для его нормальной практической работы.
Конечно, ВРС не нуждается в ()гор-пакетах, однако они хорошо подходят друг для друга, и ()ЭР обычно используется совместно с ВРС. Тем не менее, когда параметры или результаты оказываются больше максимальных размеров Ш>Р-пакетов или запрашиваемая операция не идемпотентна (то есть не может повторяться без риска сбоя — например, операция инкрементирования счетчика), может понадобиться установка ТСР-соединения и отправки запроса по ТСР, а не по (ЛЭР. Транспортные протоколы Интернета: ВОР 603 Транспортный протокол реального масштаба времени Клиент-серверный удаленный вызов процедур — это та область, в которой 130Р применяется очень широко.
Еще одной такой областью являются мультимедийные приложения реального времени. В частности, с ростом популярности интернет-рэдио, интернет-телефонии, музыки и видео по заказу, видеоконференций и других мультимедийных приложений стало понятно, что все они пытаются заново изобрести велосипед, используя более или менее одинаковые транспортные протоколы реального времени. Вскоре пришли к мысли о том, что было бы здорово иметь один общий транспортный протокол для мультимедийных приложений. Так появился на свет протокол КТР (Кеа1-Типе Тгапзрогг Ргогосо! — транспортный протокол реального масштаба времени).
Он описан в КРС 1889 и ныне широко используется. КТР занимает довольно странное положение в стеке протоколов. Было решено, что КТР будет принадлежать пользовательскому пространству и работать (в обычной ситуации) поверх ()ОР. Делается это так. Мультимедийное приложение может состоять из нескольких аудио-, видео-, текстовых и некоторых других потоков.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
