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

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

1.4. Концепции программных решений

Машина А Машина В

1 I

Машина С

Распределенные приложения

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

Службы сетевой

операционной

системы

Ядро

Службы сетевой

операционной

системы

Ядро

Службы сетевой

операционной

системы

Ядро

Сеть

Рис. 1.16. Общая структура распределенных систем

с промежуточным уровнем

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

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

появления и широкого распространения сетевых операционных систем многие

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

рые невозможно легко интегрировать в единую систему [45]. Именно тогда про-

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

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

ленного взаимодействия и улучшенные коммуникационные возможности.

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

Была создана организация, призванная определить общий стандарт для решений

на базе промежуточного уровня. К настоящему времени таких стандартов суще-

ствует множество. Стандарты в основном несовместимы друг с другом, и что еще

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

редко способны работать вместе. Вероятно, все это ненадолго. Кто-нибудь непре-

менно предложит «программное обеспечение следующего уровня», которое ис-

правит этот недостаток.

Модели промежуточного уровня

Чтобы сделать разработку и интеграцию распределенных прргложений как можно

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

ня базируется на некоторой модели, или 7гарадигме, определяющей распределе-

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

даемых объектов в виде файлов. Этот подход был изначально введен в UNIX

и строго соблюдался в Plan 9

[353].

В Plan 9 все ресурсы, включая устройства вво-

да-вывода, такие как клавиатура, мышь, диск, сетевые интерфейсы и т. д., рас-

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

личались. Приложение открывало файлы, читало и записывало в них байты и

закрывало их. Поскольку файлы могли совместно использоваться несколькими

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

62 Глава 1. Введение

Подобный же подход, но менее строгий, чем в Plan 9, применяется в про-

граммном обеспечении промежуточного уровня, построенном по принципу рас-

пределенной

файловой системы {distiibuted file system). Во многих случаях это

программное обеспечение всего на один шаг ушло от сетевых операционных сис-

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

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

данных). Процессы, например, часто должны запускаться исключительно на оп-

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

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

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

Другая важная ранняя модель программного обеспечения промежуточного

уровня основана на удаленных вызовах процедур {Remote

Procedure

Calls,

RPC).

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

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

удаленной машине. При вызове такой процедуры параметры прозрачно переда-

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

чего результат выполнения возвращается в точку вызова процедуры. За исклю-

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

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

ляется об имевшем место факте сетевого обмена. Мы вернемся к вызовам уда-

ленных процедур в следующей главе.

По мере того как все более входит в моду ориентированность на объекты, стано-

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

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

муся на удаленной машине. Это привело к появлению разнообразных систем

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

тах

{distributed

objects).

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

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

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

не больше и не меньше. Все, что видит процесс,

—

это интерфейс.

Распределенные объекты часто реализуются путем размещения объекта на

одной из машин и открытия доступа к его интерфейсу с мрюжества других. Когда

процесс вызывает метод, реализация интерфейса на машрп1е с процессом просто

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

ет запрашиваемый метод и отправляет назад результаты. Затем реализация ин-

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

редается вызвавшему процессу. Как и в случае с RPC, процесс может оказаться

не осведомленным об этом обмене.

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

лучшим образом видно на примере World Wide Web. Успех среды Web в основ-

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

сокоэффективной модели распределенных документов {distributed documents).

модели, принятой в Web, информация организована в виде документов, каж-

дый из которых размещен на машине, расположение которой абсолютно про-

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

1.4. Концепции программных решений 63

ми.

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

извлечен из места его хранения и выведен на экран пользователя. Концепция до-

кумента не ограничивается исключительно текстовой информацией. Например,

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

кументов на основе интерактивной графики.

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

Службы промежуточного уровня

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

уровня служб. Все программное обеспечение промежуточного уровня неизменно

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

доставления высокоуровневых средств связи {communication facilities), скрываю-

щих низкоуровневую пересылку сообщений по компьютерной сети. Интерфейс

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

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

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

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

лям и приложениям. Мы уже упоминали удаленный вызов процедур и обраще-

ние к распределенным объектам. Кроме того, многие системы промежуточного

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

такие как распределенные файловые системы или распределенные базы данных.

Прозрачная доставка документов, реализуемая в Web, — это еще один пример

коммуникаций высокого уровня (однонаправленных).

Важная служба, общая для всех систем промежуточного уровня,

—

это имено-

вание {naming). Службы именования сравнимы с телефонными книгами или

справочниками типа «Желтых страниц». Они позволяют совместно использовать

и искать сущности (как в каталогах). Хотя присвоение имен на первый взгляд

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

Проблема состоит в том, что для эффективного поиска имени в большой системе

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

Такое допущение, в частности, принято в среде World Wide Web, в которой лю-

бой документ поименован посредством URL. URL содержит имя сервера, на ко-

тором находится документ с данным URL-адресом. Таким образом, если доку-

мент переносится на другой сервер, его URL перестает работать.

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

ства хранения данных, также именуемые средствами сохранности {persistence).

В своей простейшей форме сохранность обеспечивается распределенными файло-

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

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

ва для связи приложений с базами данных.

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

ставляются и средства для распределенных транзакций {distributed transactions).

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

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

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

64 Глава 1. Введение

завершаются успешно), либо неудачной, что оставляет все задействованные дан-

ные не измененными. Распределенные транзакции работают с данными, кото-

рые,

возможно, разбросаны по нескольким машинам.

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

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

труднена. К сожалению, транзакции легче масштабировать на нескольких гео-

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

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

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

{secuiity).

По сравнению с сетевыми операционными системами проблема за-

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

Промежуточный уровень в принципе не может «надеяться» на то, что базовые

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

сети. Соответственно, защита отчасти ложится на программное обеспечение про-

межуточного уровня. В сочетании с требованием расширяемости защита превра-

щается в одни из наиболее трудно реализуемых в распределенных системах

служб.

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

Современные распределенные системы обычно создаются в виде систем проме-

жуточного уровня для нескольких платформ. При этом приложения создаются

для конкретной распределенной системы и не зависят от платформы (операцион-

ной системы). К сожалению, эта независимость часто заменяется жесткой зави-

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

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

чем утверждается.

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

ляется полнотой (завершенностью) ее интерфейса. Полнота означает реальное

наличие всех необходимых для создания систем описаний. Неполнота описания

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

свои собственные интер>фейсы. Таким образом, мы можем прийти к ситуации,

когда разными командами разработчиков в соответствии с одним и тем же стан-

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

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

ных усилий.

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

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

солютно одинаковый набор интерфейсов, но различные базовые протоколы. Так,

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

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

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

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

на

рис.

1.17.

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

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

1.4. Концепции программных решений 65

щаться. Если

сущностям

одной системе обращение идет через URL,

а в

дру-

гой системе

—

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

дут

проблемам.

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

предписывать вид ссылок.

Приложение

\-^^^ШшШШШШ!г\

Программное

' обеспечение

промежуточного

уровня

Сетевая

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

система

Одинаковые

программные

интерфейсы

Общий

протокол

Приложение

MiiliiiililiiiiilH

J Программное

обеспечение

промежуточного

уровня

Сетевая

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

система

Рис. 1.17. В открытых распределенных системах должны быть одинаковыми как протоколы,

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

предоставляемые приложениям

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

Краткое сравнение распределенных операционных систем, сетевых операци-

онных сргстем

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

табл.

1.5.

Таблица 1.5. Сравнение распределенных операционных систем,

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

промежуточного уровня

Характеристика

Степень

прозрачности

Идентичность

операционной

системы на всех

узлах

Число копий ОС

Коммуникации

на основе

Управление

ресурсами

Распределенная операционная

система

мульти-

процессорная

Очень высокая

Поддерживает-

ся

Совместно

используемой

памяти

Глобальное,

централизован-

ное

мульти-

компьютерная

Высокая

Поддерживает-

ся

Сообщений

Глобальное,

распределен-

ное

Сетевая

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

система

Низкая

Не поддержи-

вается

Файлов

Отдельно

на узле

Распределен-

ная система

промежуточ-

ного уровня

Высокая

Не поддержи-

вается

В зависимости

от модели

Отдельно

на узле

продолжение-S^

66 Глава 1. Введение

Таблица 1.5

(продолжение)

Характеристика Распределенная операционная

система

мульти-

процессорная

мульти-

компьютерная

Сетевая

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

система

Распределен-

ная система

промежуточ-

ного уровня

Масштабируемость Отсутствует Умеренная Да Различная

Открытость Закрытая Закрытая Открытая Открытая

Что касается прозрачности, ясно, что распределенные операционные системы

работают лучше, чем сетевые. В мультипроцессорных системах нам нужно скры-

вать только общее число процессоров, а это относительно несложно. Сложнее

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

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

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

специальных моделей распределения и связи. Так, например, распределенные

файловые системы обычно хорошо скрывают местоположение файлов и доступ

к ним. Однако они несколько теряют в общности, и пользователи, решршшие вы-

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

блемы с некоторыми приложениями.

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

собственную операционную систему (ядро). В мультипроцессорных системах

нет необходимости копировать данные

—

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

дятся в общей памяти и могут использоваться совместно. В этом случае вся

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

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

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

нете большая часть обмена осуществляется путем передачи файлов. Кроме того,

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

систем электронной почты и досок объявлений. Связь в распределенных систе-

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

Ресурсы в сетевых операционных системах и распределенных системах про-

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

этих систем относительно простым. Однако практика показывает, что реализа-

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

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

операционные системы осуществляют глобальное управление ресурсами, что ус-

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

данные находятся в общей памяти) в мультипроцессорных системах они также

масштабируются с трудом.

И, наконец, сетевые операционные системы и распределенные системы про-

межуточного уровня выигрывают с точки зрения открытости. В основном узлы

поддерживают стандартный коммуникационный протокол типа TCP/IP, что де-

лает несложной организацию их совместной работы. Однако здесь могут встре-

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

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

1.5. Модель клиент-сервер 67

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

результате

на

дороге

открытым систе-

мам

них стоит множество запатентованных решений.

1.5. Модель клиент-сервер

До этого момента мы вряд ли сказали что-то о действительной организации рас-

пределенных систем, более интересуясь тем,

как в

этих системах организованы

процессы.

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

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

раз-

работчики

все же

договорились.

Они

пришли

выводу

том,

что

мышление

понятиях клиентов, запрашивающих службы

серверов, помогает понять слож-

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

этом разделе мы кратко рас-

смотрим модель клиент-сервер.

1.5.1.

Клиенты

серверы

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

ся

на

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

рую службу, например службу файловой системы или базы данных, называются

серверами

{servers).

Процессы, запрашивающие службы

серверов путем посыл-

ки запроса

последующего ожидания ответа

от

сервера, называются клиентами

{clients).

Взаимодействие клиента

сервера, известное также под названием

ре-

жим работы запрос-ответ {request-reply

behavior),

иллюстрирует рис.

1.18.

Клиент•

Сервер

•

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

Служба провайдера Время

Рис.

1.18.

Обобщенное взаимодействие между клиентом

сервером

Если базовая сеть

так же

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

ду клиентом

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

ла,

не

требующего установления соединения. В этом случае клиент, запрашивая

службу, облекает свой запрос

форму сообщения с указанием

нем службы, ко-

торой

он

желает воспользоваться,

необходимых

для

этого исходных данных.

Затем сообщение посылается серверу. Последний,

свою очередь, постоянно

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

тат обработки

ответное сообщение

отправляет его клиенту.

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

игрыш

эффективности.

До тех пор

пока сообщения

не

начнут пропадать

или

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

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

случайным сбоям связи,

—

петри-

68 Глава 1. Введение

виальная задача. Все, что мы можем сделать, — это дать клиенту возможность

повторно послать запрос, на который не был получен ответ. Проблема, однако,

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

ное сообш,ение с запросом было потеряно или ошибка произошла при передаче

ответа. Если потерялся ответ, повторная посылка запроса может привести к по-

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

«снять 10 000 долларов с моего банковского счета», понятно, что было бы гораз-

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

ли о произошедшей ошибке. С другой стороны, если операция была «сообщите

мне,

сколько денег у меня осталось», запрос прекрасно можно было бы послать

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

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

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

дежный протокол с установкой соединения. Хотя это решение в связи с его отно-

сительно низкой производительностью не слишком хорошо подходит для ло-

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

ненадежность является «врожденным» свойством соединений. Так, практически

все прикладные протоколы Интернета основаны на надежных соединениях по

протоколу TCP/IP. В этих случаях всякий раз, когда клиент запрашивает служ-

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

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

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

единения в смысле затрачиваемого времени и ресурсов относительно дороги,

особенно если сообщения с запросом и ответом невелики. Мы обсудим альтерна-

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

данных, в следующеР! главе.

Примеры клиента и сервера

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

мы рассмотрим описание клиента и файлового сервера на языке С. И клиент,

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

соберем вместе в файл под названием header.h, текст которого приведен в лис-

тинге 1.3. Эти определения затем включаются в тексты программ клиента и сер-

вера следующей строкой:

#1nclucle <header.h>

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

вставит все содержимое файла header.h в текст программы до того, как начнется

ее компиляция.

Листинг 1.3. Файл header.h, используемый клиентом и сервером

/* Определения, необходимые и клиентам, и серверам */

#clefine TRUE 1

Максимальная длина имени файла

#define МАХ_РАТН

255

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

1.5. Модель клиент-сервер 69

#def1ne BUF_SIZE

Сетевой адрес

#def1ne FILE SERVER

1024

илового сервера

243

Определения разрешенных операций

создать новый файл

#define CREATE

считать данные

из

файла

вернуть

их

#define READ

записать данные

файл

'^1

#define WRITE

удалить существующий файл

#def1ne DELETE

Коды ошибок

операция прошла успешно

#def1ne

запрос неизвестной операции

#def1ne E_BAD_OPER

-1

ошибка

параметре

#def1ne E_BAD_PARAM

-2

ошибка диска

или

другая ошибка чтения-записи

#def1ne

-3

Определение формата сообщения

struct message

{

long source-

long dest;

long opcode

long count;

long offset

long result:

char name[MAX_PATH];

char data[BUF

SIZE]:

идентификатор источника

идентификатор приемника

'^1

запрашиваемая операция

число передаваемых байт

позиция

файле,

которой начинается

ввод-вывод

результат операции

имя файла,

которым производятся

операции

данные,

которые будут считаны

или

записаны

Итак, перед нами текст файла header.h. Он начинается с определения двух

констант,

МАХ_РАТН

BUF_SIZE,

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

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

в имени файла (то есть в строке с путем типа /usr/ast/books/opsys/chapter1.t).

Вторая задает размер блока данных, который может быть прочитан или записан

за одну операцию путем установки размера буфера. Следующая константа, FILE_

SERVER,

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

лать сообщения.

Вторая группа констант задает номера операций. Они необходимы для того,

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

—

за-

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

их обычно больше.

70 Глава 1. Введение

Каждый ответ содержит код результата. Если операция завершена успешно,

код результата обычно содержит полезную информацию (например, реальное

число считанных байтов). Если нет необходимости возвращать значение (напри-

мер,

при создании файла), используется значение

ОК.

Если операция по каким-

либо причинам окончилась неудачей, код результата

(E_BAD_OPER,

E_BAD_PARAM

и др.)

сообщает нам, почему это произошло.

Наконец, мы добрались до наиболее важной части файла header.h

—

определе-

ния формата сообщения. В нашем примере это структура с 8 полями. Этот фор-

мат используется во всех запросах клиентов к серверу и ответах сервера. В ре-

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

скольку не во всех случаях нужны все поля), но здесь это упростит объяснение.

Поля source и dest определяют, соответственно, отправителя и получателя. Поле

opcode

—

это одна из ранее определенных операций, то есть create, read, write или

delete. Поля count и offset требуются для передачи параметров. Поле result в за-

просах от клиента к серверу не используется, а при ответах сервера клиенту со-

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

из них,

name,

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

ром, data, находятся возвращаемые сервером при чтении или передаваемые на

сервер при записи данные.

Давайте теперь рассмотрим код в листингах 1.4 и 1.5. Листинг 1.4

—

это про-

грамма сервера, листинг 1.5

—

программа клиента. Программа сервера достаточно

элементарна. Основной цикл начинается вызовом receive в ответ на сообщение

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

указан его адрес, а второй указывает на буфер сообщений, идентифицируя, где

должно быть сохранено пришедшее сообщение. Процедура receive блокирует

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

продолжает свою работу и определяет тип кода операции. Для каждого кода опе-

рации вызывается своя процедура. Входящее сообщение и буфер для исходящих

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

в параметре ml и строит исходящее в параметре т2. Она также возвращает значе-

ние функции, которое передается через поле result. После посылки ответа сер-

вер возвращается к началу цикла, выполняет вызов receive и ожидает следующе-

го сообщения.

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

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

писи его в файл-приемник. Цикл повторяется до тех пор, пока исходный файл не

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

ния

—

должен быть ноль или отрицательное число.

Первая часть цикла состоит из создания сообщения для операции чтения и пе-

ресылки его на сервер. После получения ответа запускается вторая часть цикла,

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

для записи в файл-приемник. Программы из листингов 1.4 и 1.5

—

это только на-

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

процедуры do_xxx (которые на самом деле выполняют работу), отсутствует также

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