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