Таненбаум Э. Распределенные системы. Принципы и парадигмы

Подождите немного. Документ загружается.

2.1.

Уровни протоколов 91

хронизации. Последние требуются для создания пользователями контрольных

точек при длинных сеансах передачи данных, а также уведомления их о сбое в хо-

де такого сеанса. При этом необходимо сделать откат только до последней кон-

трольной точки и не нужно проходить весь путь сначала. На практике сеансовый

уровень нужен немногим приложениям и поддерживается редко. Он даже не вхо-

дит в комплект протоколов Интернета.

В отличие от предыдущих уровней, на которых мы заботились о точной и эф-

фективной пересылке битов от отправителя к получателю, уровень представления

занимается смыслом этих битов. Большинство сообщений содержат не случай-

ные последовательности битов, а структурированную информацию типа фами-

лий, адресов, денежных сумм и т. п. На уровне представления можно определить

записи, содержащие подобного рода поля, и потребовать у отправителя уведом-

лять получателя, что сообщение содержит отдельные записи соответствующего

формата. Это упрощает взаимодействие между машинами с различным внутрен-

ним представлением данных.

Прикладные протоколы

Прикладной уровень модели OSI изначально должен был содержать набор стан-

дартных сетевых приложений, например для работы с электронной почтой, пере-

дачи файлов и эмуляции терминала. В настоящее время он стал местом собрания

всех приложений и протоколов, которые не удалось пристроить ни на один из бо-

лее низких уровней. В свете эталонной модели OSI все распределенные системы

являются просто приложениями.

Чего в этой модели нет

—

так это четкого разграничения приложений, специ-

альных протоколов приложений и протоколов общего назначения. Так, напри-

мер,

популярный в Интернете

протокол

передачи файлов

{File Transfer

Protocol,

FTP) [203, 361] определяет передачу файлов между клиентской машиной и сер-

вером. Этот протокол не следует путать с программой ftp, которая представляет

собой законченное приложение для передачи файлов и совпадает (но не полно-

стью) с реализацией протокола FTP для Интернета.

Другим примером сугубо специального прикладного протокола [142] может

служить

протокол передачи гипертекста

(Hypertext

Transfer

Protocol,

HTTP), раз-

работанный для удаленного управления и загрузки web-страниц. Протокол реа-

лизован в таких приложениях, как web-браузеры и web-серверы. Однако сейчас

этот протокол используется и в системах, связь которых с Web не предполагает-

ся.

Так, например, в RMI в языке Java протокол HTTP используется для обра-

щения к удаленному объекту, защищенному брандмауэром

[441].

Кроме того, существует множество протоколов общего назначения, исполь-

зуемых в различных приложениях. Они попали в прикладные протоколы, пото-

му что их нельзя было отнести к транспортным. Во многих случаях они могут

считаться протоколами промежуточного уровня, которые мы сейчас рассмотрим.

Протоколы промежуточного уровня

к промежуточному уровню относятся приложения, логически помещаемые на

прикладной уровень, но содержащие множество протоколов общего назначения.

92 Глава 2. Связь

что дает им право на их собственный уровень, независимый от других, более спе-

циализированных приложений. Можно отделить высокоуровневые протоколы

взаимодействия от протоколов для предоставления различных служб промежу-

точного уровня.

Существует множество протоколов, которые поддерживают разнообразные

службы промежуточного уровня. Так, например, в главе 8 мы обсуждаем раз-

нообразные методы аутентификации, то есть методы удостоверения личности.

Протоколы аутентификации не привязаны к какому-либо конкретному прило-

жению. Вместо этого они встраиваются в системы промежуточного уровня на

правах общедоступной службы. Протоколы авторизации, согласно которым под-

твердившие свой статус пользователи и процессы получают доступ только к тем

ресурсам, на которые они имеют право, также имеют тенденцию к переходу на

независимый от приложений уровень.

В качестве другого примера рассмотрим множество протоколов распределен-

ного подтверждения (commit) из главы 7. Протоколы подтверждения делают

так, чтобы в группе процессов либо все процессы прошли через определенную

операцр1ю, либо операция не была применена ни к одному из них. Это явление,

известное также как

атомарность,

широко используется при транзакциях. Как

мы увидим, не только транзакции, но и другие приложения, особенно рассчитан-

ные на устойчивость к сбоям, также могут нуждаться в протоколах распределен-

ного подтверждения.

В качестве последнего примера рассмотрим протоколы распределенной бло-

кировки, при помощи которых может быть предотвращен одновременный дос-

туп к ресурсам нескольких процессов, распределенных по множеству машин.

Мы рассмотрим некоторые из этих протоколов в главе 5. Это еще один пример

протоколов, которые могут быть реализованы в виде общедоступной службы

промежуточного уровня, который в то же время не зависит от какого-либо кон-

кретного приложения.

Коммуникационные протоколы промежуточного уровня поддерживают вы-

сокоуровневые коммуникационные службы. Так, например, в следующих двух

пунктах мы обсудим протоколы, которые позволяют процессам прозрачно вызы-

вать процедуры или обращаться к объектам на удаленных машинах. Существуют

также коммуникационные службы высокого уровня для запуска и синхронизации

потоков данных в реальном времени, что характерно, например, для мультиме-

дийных приложений. В качестве последнего примера приведем предоставляемые

некоторыми системами промежуточного уровня надежные службы групповой

рассылки, способные поддерживать тысячи получателей, разбросанных по гло-

бальной сети.

Некоторые из коммуникационных протоколов промежуточного уровня могут

быть помещены и на транспортный уровень, но для их «повышения» имеются

особые причины. Так, например, службы надежной групповой рассылки с гаранти-

рованной масштабируемостью могут быть реализованы, только если принимаются

во внимание требования к приложению. Соответственно, системы промежуточ-

ного уровня могут предоставлять те или иные протоколы (настраиваемые), каж-

дый из которых реализует различные транспортные протоколы, но предоставля-

ет одинаковый интерфейс.

2.2.

Удаленный вызов процедур 93

Такой подход к подразделению на уровни приводит нас к слегка измененной

эталонной модели взаимодействия (рис. 2.5). По сравнению с моделью OSI сеан-

совый уровень и уровень представления заменены одним промежуточным уров-

нем, который содержит не зависящие от приложений протоколы. Как мы гово-

рили, эти протоколы нельзя поместить на более низкие уровни. Истинные

транспортные службы также могут быть представлены в виде служб промежу-

точного уровня. Для этого не потребуется даже модрхфикации. Этот подход ана-

логичен переносу UDP на транспортный уровень. Точно так же службы проме-

жуточного уровня могут включать в себя службы пересылки сообщегп^й, схожие

с теми, которые предоставляются на транспортном уровне.

Приложение

Промежуточный уровень

Транспорт

Сеть

Передача данных

Физическое воплощение

^ ^

^--

Ы--

^--

Прикладной протокол

Промежуточный протокол

Транспортный протокол

Сетевой протокол

Канальный протокол

Физический протокол

--W

Сеть

Рис. 2.5. Измененная эталонная модель сетевого взаимодействия

В оставшейся части этой главы мы сосредоточимся на четырех высокоуров-

невых коммуникационных службах промежуточного уровня: удаленном вызо-

ве процедур, удаленном обращении к объектам, очередям сообщений и потокам

данных.

2.2.

Удаленный вызов процедур

Основой множества распределенных систем является явный обмен сообщениями

между процессами. Однако процедуры send и receive не скрывают взаимодейст-

вия, что необходимо для обеспечения прозрачности доступа. Эта проблема была

известна давно, но по ней мало что было сделано до появления в 1980 году статьи

[62],

в которой предлагался абсолютно новый способ взаимодействия. Хотя идея

была совершенно простой (естественно, после того как кто-то все придумал), ее

реализация часто оказывается весьма хитроумной. В этом разделе мы рассмот-

рим саму концепцию, ее реализацию, сильные и слабые стороны.

Если не вдаваться в подробности, в упомянутой статье было предложено по-

зволить программам вызывать процедуры, находяицтеся на других машинах. Когда

процесс, запущенный на машине Л, вызывает процедуру с машины Б, вызываю-

94 Глава 2. Связь

щий процесс на машине Л приостанавливается, а выполнение вызванной проце-

дуры происходит на машине В. Информация может быть передана от вызываю-

щего процесса к вызываемой процедуре через параметры и возвращена процессу

в виде результата выполнения процедуры. Программист абсолютно ничего не за-

метит. Этот метод известен под названием удаленный вызов процедур {Remote

Procedure

Call,

RPC).

Базовая идея проста и элегантна, сложности возникают при реализации. Для

начала, поскольку вызывающий процесс и вызываемая процедура находятся на

разных машинах, они выполняются в различных адресных пространствах, что тут

же рождает проблемы. Параметры и результаты также передаются от машины

к машине, что может вызвать свои затруднения, особенно если машины не оди-

наковы. Наконец, обе машины могут сбоить, и любой возможный сбой вызо-

вет разнообразные сложности. Однако с большинством из этих проблем можно

справиться, и RPC является широко распространенной технологией, на которой

базируются многие распределенные системы.

2.2.1.

Базовые операции RPC

Мы начнем с обсуждения общепринятых вызовов процедур, а затем рассмотрим,

как вызов может быть распределен между клиентской и серверной частями сис-

темы, каждая из которых выполняется на различных машинах.

Общепринятые вызовы процедур

Для того чтобы понять, как работает RPC, важ]1о сначала разобраться, как осуще-

ствляются общепринятые (в пределах одной машины) вызовы процедур. Рас-

смотрим вызов в языке типа С:

count = readCfd. buf. bytes):

Здесь fd

—

целое, указывающее на файл; buf

—

массив символов, в который

будут считываться

дaн^H:)Ie;

bytes

—

другое целое, говорящее, сколько байт следует

считать. Если вызов производится из главной программы, стек до вызова выгля-

дит так, как показано на рис. 2.6, а. Делая вызов, вызывающая программа поме-

щает параметры в стек в порядке «последний первым», как показано на рис. 2.6, б.

Причина, по которой компилятор С помещает параметры в стек в обратном по-

рядке, заключается в функциях типа

printf.

Чтобы выполняться, функция printf

всегда должна знать, где искать свой первый аргумент

—

строку формата. После

завершения read система помещает возвращаемое значение в регистр, удаляет

адрес возврата и возвращает управление назад, в вызвавшую программу. Затем

вызвавшая программа удаляет из стека параметры, приводя его в исходное со-

стояние.

Следует особо отметить некоторые моменты. Во-первых, в С параметры мо-

гут передаваться как по значению, так и по ссылке. Параметр-значение, такой

как fd или bytes, просто копируется в стек, что и показано на рис. 2.6, б. Для вы-

зываемой процедуры параметр-значение представляет собой просто инициали-

зированную локальную переменную. Вызываемая процедура может ее изменить.

2.2.

Удаленный вызов процедур 95

но все эти изменения не могут повлиять на ее оригинальное значение на вызы-

вающей стороне.

Указатель стека

Локальные переменные

главной программы

Локальные переменные

главной программы

bytes

but

Адрес возврата

Локальные переменные

процедуры read

Рис. 2.6. Передача параметров при локальном вызове процедуры: стек до вызова

функции read (а). Стек во время работы вызванной процедуры (б)

Параметр-ссылка в С

—

это указатель на переменную (то есть адрес перемен-

ной),

а не ее значение. В вызове read второй параметр является параметром-

ссылкой, поскольку массивы в С всегда передаются через ссылку. В стек на са-

мом деле будет помещен адрес символьного массива. Если вызванная процедура

использует этот параметр для помещения чего-либо в символьный массив, это

приведет к изменению массива в вызывающей программе. Мы увидим, что

разница между параметрами-значениями и параметрами-ссылками крайне важ-

на для RPC.

Существует еще один механизм передачи параметров, не применяющийся в С.

Он называется вызов через копирование/восстановление {call-by-сору/restore).

этом случае до вызова вызывающей программой производится копирование

переменной в стек, как при вызове по значению, а после завершения вызова

—

копирование этой переменной из стека назад, с удалением исходного значения

этой переменной. В большинстве случаев это дает тот же эффект, что и при вы-

зове по ссылке. Однако иногда, например, если один и тот же параметр присут-

ствует в списке аргументов многократно, их семантика различается. Во многих

языках вызов через копирование/восстановление отсутствует.

Решение об использовании того или иного механизма передачи параметров

принимается обычно разработчиками языка и является его фиксированным свой-

ством. Раньше это решение зависело от типов передаваемых данных. В С, напри-

мер,

как мы виделР!, целые и другие скалярные типы всегда передаются по значе-

нию,

а массивы

—

по ссылке. Некоторые компиляторы языка Ада поддерживают

вызов через копирование/восстановление для изменяемых {in out) параметров,

передавая остальные по ссылке. Определение языка позволяет выбрать любой

вариант, который хоть немного упрощает семантику.

96 Глава 2. Связь

Заглушки для клиента и сервера

Идея, стоящая за RPC, состоит в том, чтобы удаленный вызов процедур выглядел

точно так же, как и локальный. Другими словами, мы ждем от RPC прозрачно-

сти

—

вызывающая процедура не должна уведомляться о том, что вызываемая

процедура выполняется на другой машине, и наоборот. Предположим, программа

хочет считать некоторые данные из файла. Для чтения из файла необходимых

данных программист помещает в код вызов read. В традиционной (однопроцес-

сорной) системе процедура read извлекается компоновщиком из библиотеки и

вставляется в объектный код программы. Это короткая процедура, которая обыч-

но реализуется путем системного вызова read. Другими словами, процедура

read

—

это интерфейс между кодом пользователя и локальной операционной сис-

темой.

Даже если read

—

это системный вызов, он производится аналогичным обра-

зом, путем помещения параметров в стек, как показано на рис. 2.6,

б.

Таким обра-

зом, программист так и не узнает, что read делает что-то хитрое.

RPC организует свою прозрачность аналогичным образом. Если read являет-

ся удаленной процедурой (то есть будет исполняться на машине файлового сер-

вера),

в библиотеку помещается специальная версия read, называемая клиент-

ской заглушкой {client

stub). Как и оригинальная функция, она также вызывается

в соответствии с последовательностью, показанной на рис 2.6, б. Как и оригинал,

она также производит вызов локальной операционной системы, только в от-

личие от оригинальной функции клиентская заглушка не запрашивает данные

у операционной системы. Вместо этого она упаковывает параметры в сообщение

и путем вызова процедуры send требует переслать это сообщение на сервер, как

показано на рис. 2.7. После вызова процедуры send клиентская заглушка вызыва-

ет процедуру receive, блокируясь до получения ответа.

к Ожидание результата

Вызов \ / Завершение

удаленной \ / вызова

процедуры \ /

Запрос\ / Ответ

Сервер '

Вызов локальной Время •

процедуры и возвращение

результата

Рис. 2.7. Схема RPC между программами клиента и сервера

Когда сообщение приходит на сервер, операционная система сервера передает

его

серверной

заглушке

{server

stub). Серверная заглушка эквивалентна клиент-

ской, но работает на стороне сервера. Это фрагмент кода, который преобразует

приходящие по сети запросы в вызовы локальных процедур. Обычно серверная

заглушка запускает процедуру receive и блокируется, ожидая входящих сообще-

ний. После получения сообщения серверная заглушка распаковывает его, извле-

кая параметры, и традиционным способом (то есть так, как показано на рис. 2.6)

2.2.

Удаленный вызов процедур 97

вызывает процедуру сервера. С точки зрения сервера это воспринимается как

прямой вызов с клиента

—

параметры и адрес возврата находятся в стеке, где

они и должны находиться, и ничего необычного в этом нет. Сервер делает свое

дело и обычным порядком возвращает результат вызвавшей процедуре. Так,

например, в случае чтения файла сервер заполняет данными буфер, на кото-

рый указывает второй параметр. Этот буфер

—

внутренний буфер серверной за-

глушки.

Когда серверная заглушка после окончания обработки вызова возвращает

управление вызвавшей программе, она запаковывает результаты выполнения (бу-

фер) в сообщение и вызывает процедуру send, чтобы возвратить их клиенту. По-

сле этого серверная заглушка вновь вызывает процедуру receive, переходя в ре-

жим ожидания следующего сообщения.

Когда на клиентскую машину приходит ответное сообщение, операционная

система клиента обнаруживает, что оно адресовано клиентскому процессу (па

самом деле клиентской заглушке, но операционная система их не различает).

Сообщение копируется в буфер ожидания, и клиентский процесс разблокирует-

ся.

Клиентская заглушка рассматривает сообщение, распаковывает его, извлекая

результаты, копирует их в память вызвавшей программы и, завершая работу, пе-

редает в нее код возврата. Когда вызвавшая программа получает управление по-

сле вызова read, все, что она знает,

—

это то, что запрошенные данные находятся

там, где и предполагалось, то есть в буфере. У нее нет никакого представления

о том, как осуществлялся вызов

—

удаленно или в рамках локальной операцион-

ной системы.

В блаженстве неведения, царящем на стороне клиента, и состоит прелесть та-

кой схемы. Как мы видели, доступ к удаленным службам осуществляется по-

средством вызова обычных (то есть локальных) процедур, без всяких там send

гесе1

ve.

Все детали пересылки сообщений скрыты в двух библиотечных проце-

дурах, так же как в традиционных библиотеках скрыты детали реально произво-

димых системных вызовов.

Подведем итоги. При удаленном вызове процедур происходят следующие

действия.

Процедура клиента обычным образом вызывает клиентскую заглушку.

Клиентская заглушка создает сообщение и вызывает локальную операцион-

ную систему.

Операционная система клиента пересылает сообщение удаленной операцион-

ной системе.

Удаленная операционная система передает сообщение серверной заглушке.

Серверная заглушка извлекает из сообщения параметры и вызывает сервер.

6. Сервер выполняет вызов и возвращает результаты заглушке.

Серверная заглушка запаковывает результаты в сообщение и вызывает свою

локальную операционную систему.

8. Операционная система сервера пересылает сообщение операционной системе

клиента.

Глава 2. Связь

9. Операционная система клиента принимает сообщение и передает его клиент-

ской заглушке.

10.

Заглушка извлекает результаты из сообщения и передает их клиенту.

Сетевые эффекты этих шагов состоят в том, что клиентская заглушка превра-

щает локальный вызов процедуры клиента в локальный вызов процедуры серве-

ра, причем ни клиент, ни сервер ничего не знают о промежуточных действиях.

2.2.2.

Передача параметров

Назначение клиентской заглушки состоит в том, чтобы получить параметры, за-

паковать их в сообщение и послать его серверной заглушке. Хотя эти действия

выглядят несложно, они не так просты, как кажется на первый взгляд. В этом

пункте мы рассмотрим некоторые вопросы, связанные с передачей параметров

в системах RPC.

Передача параметров по значению

Упаковка параметров в сообщение носит название маршалиига параметров

{parameter

marshaling),

В качестве простейшего примера рассмотрим удаленную

процедуру, add

(1,

j), которая использует два целых параметра,

и возвращает

в результате их арифметическую сумму. (На практике так не делается, поскольку

удаленная реализация столь простой процедуры крайне невыгодна, но для при-

мера сойдет.) Вызов add иллюстрируется левой частью рис. 2.8 (в клиентском

процессе). Клиентская заглушка извлекает два ее параметра и, как показано на

рисунке, упаковывает их в сообщение. Она также помещает туда имя или номер

вызываемой в сообщении процедуры, поскольку сервер может поддерживать не-

сколько разных процедур и ему следует указать, какая из них потребовалась

в данном случае.

Клиентская машина

Клиентский процесс

к^&^Щ).

ргос: "add"

inti val(i)

int: val(j)

Операционная

система клиента

Серверная машина

Серверная

заглушка

Клиентская

заглушка

ргос:

jnt:

int:

"add"

val(i)

val(j)

Серверный процесс

Реализация

процедуры

add

iiiiiii

ргос: "add"

int: val(i)

int: val(j)

Операционная

система сервера

Рис. 2.8. Процесс удаленных вычислений с использованием RPC

2.2.

Удаленный вызов процедур 99

Когда сообщение приходит на сервер, заглушка исследует сообщение в поисках

указания на то, какую процедуру следует вызвать, а затем делает соответствую-

щий вызов. Если сервер поддерживает и другие удаленные процедуры, сервер-

ная заглушка должна содержать ргнструкцию типа switch для выбора вызываемой

процедуры в зависимости от первого поля сообщения. Реальный вызов процеду-

ры сервера из серверной заглушки выглядит почти как первоначальный клиент-

ский вызов, если не считать того, что параметрами являются переменные, ини-

циализированные значениями, взятыми из сообщения.

ТакР1м образом, имеет место следующая пошаговая процедура.

Клиент вызрлвает процедуру add.

Клиентская заглушка строит сообщение.

Сообщение отправляется по сети на сервер.

Операционная система сервера передает сообщение серверной заглушке.

Серверная заглушка распаковывает сообщение.

6. Серверная заглушка выполняет локальный вызов процедуры add.

Когда сервер заканчивает работу, управление вновь передается серверной за-

глушке. Она получает результат, переданный сервером, и запаковывает его в со-

общение. Это сообщение отправляется назад, к клиентской заглушке, которая

распаковывает его и возвращает полученное значение клиентской процедуре.

До тех пор пока машины клиента и сервера идентичны, а все параметры и ре-

зультаты имеют скалярный тип (то есть целый, символьный или логический),

эта модель работает абсолютно правильно. Однако в больип1х распределенных

системах обычно присутствуют машины разных типов. Каждая из машин часто

имеет собственное представление чисел, символов и других элементов данных.

Так, в мэйнфреймах IBM используется кодовая таблица EBCDIC, а в персональ-

ных компьютерах той же фирмы

—

ASCII. Вследствие этого, если передать сим-

вольный параметр с клиента на базе IBM PC на мэйнфрейм IBM, используемый

в качестве сервера, по простейшей схеме, показанной на рис. 2.8, сервер поймет

эти символы неправильно.

Сходные проблемы могут обнаружиться при передаче целых чисел (знако-

вый или значащий старший бит) и чисел с плавающей точкой. Вдобавок сущест-

вует значительно более серьезная проблема, состоящая в том, что в некоторых

машинах, таких как Intel Pentium, байты нумеруются справа налево, а в других,

например в Sun SPARC,

—

в обратном направлении. Формат компании Intel на-

зывается

остроконечным

{little endian), а формат SPARC

—

тупоконечным (big

endian),

по аналогии с названиями политрхческих партий из книги «Путешествия

Гулливера», которые в спорах о том, с какой стороны разбивать яйца, дошли до

войны

[108].

Для примера рассмотрим процедуру с двумя параметрами, целым

числом и строкой из четырех символов. Для размещения каждого из параметров

требуется одно 32-битное слово. На рис. 2.9, а показано, как будет выглядеть со-

держащий параметры фрагмент сообщения, построенного клиентской заглуш-

кой, когда клиент работает на компьютере Intel Pentium. Первое слово содержит

целый параметр, в данном случае 5, а второе слово

—

строку

JILL.

100

Глава 2. Связь

о'""

о'""'

;_6_

L'""

о'""

1_5_

б'""

—1—

"" L

3 !

""о

7.J

—1

"""о

—,—

1 1

""о

_5_!

—.,—

_6j

Л!

Рис. 2.9. Исходное сообщение, подготовленное на Pentium (а). Сообщение после

получения на SPARC (б). Сообщение после инверсии (в). Цифры в квадратах

показывают адрес каждого байта

Поскольку сообщение передается по сети байт за байтом (на самом деле бит за

битом), первый посланный байт будет и первым принятым. На рис. 2.9, б мы ви-

дим, как будет выглядеть сообщение с

рис.

2.9, а, принятое на компьютере SPARC.

Нумерация байтов здесь такова, что нулевым байтом считается левый (верхню"!

байт),

а не правый (нижний байт), как в процессорах Intel. После того как сер-

верная заглушка прочитает параметры по адресам

и 4, сервер получит, соответ-

ственно, целое число, равное 83 886 080 (5x2^"^), и строку

JILL,

Очевидное, но, к сожалению, неверное решение

—

просто инвертировать бай-

ты каждого слова после того, как оно будет принято (рис. 2.9, в). Теперь целое

число стало правильным, а строка превратилась в

LLIJ.

Проблема состоит в том,

что целые нужно приводить к другому порядку следования байтов, а строки

—

нет. Не имея дополнительной информации о том, где строка, а где целое, мы не

в состоянии исправить положение дел.

Передача параметров по ссылке

Теперь мы подошли к сложной проблеме: как передавать указатели или, в общем

случае, ссылки? Общий ответ таков: с величайшим трудом. Мы помним, что ука-

затель имеет смысл только в адресном пространстве того процесса, в котором он

используется. Возвращаясь к нашему примеру с процедурой read, который мы об-

суждали ранее, второй параметр (адрес буфера) для клиента может быть равен,

например, 1000, но нельзя же просто передать на сервер число 1000 и ожидать,

что это сработает. На сервере адрес 1000 вполне может прийтись на середину тек-

ста программы.

Одно из решений состоит в том, чтобы вообще забыть про указатели и ссыл-

ки в качестве параметров. Однако важность таких параметров делает такое реше-

ние абсолютно неподходящим. На самом деле в нем нет особой необходимости.

В примере с процедурой read клиентской заглушке известно, что второй пара-

метр указывает на массив символов. Предположим на минуту, что заглушка также

знает и величину этого массива. После этого вырисовывается следующая страте-

гия:

скопировать этот массив в сообщение и передать его на сервер. Серверная

заглушка может после этого вызвать сервер, передав ему указатель на этот мас-

сив,

даже если числовое значение этого указателя будет отличаться от передан-

ного во втором параметре вызова процедуры read. Изменения, которые с помо-

щью указателя сделает сервер (то есть по указанному адресу запишет данные),

прямо отразятся на буфере сообщения серверной заглушки. Когда сервер закон-