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

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

10.1.

Сетевая файловая система компании Sun 631

деленными файловыми системами состояла в том, что серверы не сохраняли ин-

формацию о состоянии. Другими словами, протокол NFS не требовал, чтобы сер-

веры как-то поддерживали состояние клиента. Этот подход соблюдался в верси-

ях 2 и 3, но был пересмотрен в версии 4.

Основное преимущество серверов без фиксации состояния

—

это их простота.

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

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

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

деле 7.3, следует учитывать, что клиент в этом случае вообще не может претен-

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

к вопросу отказоустойчивости NFS.

Подход без фиксации состояния в практических реализациях протокола NFS

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

сложно осуществить на сервере без фиксации состояния. В случае NFS для ре-

шения этой проблемы использовался специальный менеджер блокировок. Кроме

того,

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

живал состояние своих клиентов. Тем не менее серверы NFS обычно разрабаты-

вались так, чтобы хранить минимальный объем информации о своих клиентах.

большинстве случаев эта схема работала достаточно успешно.

Начиная с версии 4, разработчики NFS отказались от подхода без фиксации

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

ходилось хранить слишком большой объем информации о клиентах. Кроме того,

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

и другие причины. Ыаиболее важная из них состояла в том, что NFS версии 4

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

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

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

кэша. Подобные протоколы часто хорошо работают в комбинации с сервером,

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

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

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

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

продления. Мы еще вернемся к этому вопросу.

Наиболее очевидное отличие от предыдущей версии NFS состоит в поддерж-

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

состоянии. Кроме того, NFS поддерживает процедуры обратного вызова, при

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

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

ентов.

10.1.4. Именование

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

в NFS важную роль. Основная идея, лежащая в основе модели именования NFS,

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

632 Глава 10. Распределенные файловые системы

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

гается

результате того,

что

клиент может смонтировать удаленную файловую

систему

локальную файловую систему клиента,

как

показано

на

рис.

10.4.

Клиент

Сервер

Клиент

Экспортируемый каталог,

монтируемый клиентом

Экспортируемый каталог,

монтируемый клиентом

Сеть

Рис. 10.4. Монтирование части удаленной файловой системы

NFS

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

клиентам монтировать только часть файловой системы. Если сервер открывает

клиентам доступ

каталогу

его элементам,

то

говорят, что сервер

экспортиру-

ет (expojt) каталог. Экспортированный каталог может быть смонтирован

в ло-

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

Такой подход

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

в принципе, пользователи

не

могут разделять пространства имен.

Как

показано

на ppic. 10.4, файл

именем /remote/vu/mbox

клиента

называется /work/me/

mbox у клиента В. Таким образом, имя файла зависит от того, как клиент органи-

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

таток подобного подхода

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

в том,

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

мер,

Алиса не может сообщить Бобу о некотором файле, используя то имя, кото-

рое дала

ему

она, поскольку

это имя в

пространстве имен файлов Боба может

иметь совершенно ршой смысл.

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

из

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

из

клиентов частично стандартизованно-

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

мы,

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

может использовать локальный каталог /usr/bin. Точно

так же

каталог /local

мо-

жет

по

умолчанию использоваться для монтирования локальной файловой сис-

темы, размещенной

на

хосте клиента.

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

верамрг. Однако

он не

может позволить экспортировать эти каталоги своим кли-

10.1.

Сетевая файловая система компании Sun 633

ентам. Клиент должен монтировать каталоги с того сервера, на котором они раз-

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

хранения простоты конструкции. Если сервер экспортирует монтируемый ката-

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

включающие в себя идентификатор сервера. NFS такие усложненные дескрипто-

ры файлов не поддерживает.

Экспортируемый

каталог

включает

себя

импортируемый

вложенный каталог

Клиент

\ Сервер А

Сервер

импортирует

каталог

сервера

Клиент должен

явно

импортировать

вложенный

каталог с сервера В

Сеть

Рис.

10.5. Монтирование вложенных каталогов с нескольких серверов

NFS

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

файловую систему

FSA,

ИЗ

которой экспортирует каталог /packages. Этот каталог

содержит вложенный каталог /draw, являющийся монтажной точкой файло-

вой системы

FSBJ

которая экспортируется сервером В и монтируется сервером А.

Пусть Л экспортирует каталог /packages/draw своему клиенту, который монти-

рует /packages в свой локальный каталог /bin, как это показано на рис. 10.5.

Если разрешение имен итеративное (как в случае NFS версии 3), то для раз-

решения имени /bjn/draw/install клиент, локально разрешив /bin, связывается

сервером Л и запрашивает у него дескриптор файла каталога /draw. Сервер Л

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

фикатор сервера В, поскольку только В в состоянии разрешить остаток полного

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

ния имен в NFS не поддерживается.

Разрешение имен в NFS версии 3 (и более ранних версиях) строго итератив-

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

имя файла. Другими словами, разрешение такого имени, как /bin/draw/install, тре-

бует трех отдельных обращений к серверу NFS. Более того, за разрешение пол-

634 Глава 10. Распределенные файловые системы

ного имени полностью отвечает клиент. NFS версии 4 поддерживает также и ре-

курсивное разрешение имен. В этом случае клиент может передать серверу полное

имя и потребовать, чтобы сервер его разрешил.

В схеме разрешения имен NFS версии 4 имеется и еще одна специфическая

особенность. Рассмотрим файловый сервер, поддерживающий несколько файло-

вых систем. При строго итеративном разрешении имен, которое было характер-

но для версии 3, разрешение завершалось на каталоге, к которому монтируется

другая файловая система. При этом возвращался дескриптор каталога. После-

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

содержимое, а не содержимое корневого каталога смонтированной в нем файло-

вой системы.

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

примере обе файловые системы,

FSA

FSB,

находятся на одном и том же сервере.

Если клиент монтирует /packages в свой локальный каталог /bin, то поиск имени

файла draw на сервере приведет к возвращению дескриптора файла draw. Сле-

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

помощи операции readdi

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

начально хранившихся в

FSA

ВО

вложенном каталоге /packages/draw. Только ес-

ли клиент сам смонтирует файловую систему FSB, он сможет правильно разре-

шить полное имя draw/install относительно /bin.

NFS версии 4 решает эту проблему, позволяя операциям поиска файлов пере-

секать границы монтирования файловых систем на серверах. Так, в частности,

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

ла, изначально хранившегося в этом каталоге. Клиент может заметить, что опе-

рация lookup прошла монтажную точку, если проверит идентификатор файловой

системы найденного файла. При необходимости клиент может смонтировать эту

файловую систему локально.

Дескрипторы файлов

Дескриптор файла

—

это ссылка на файл в файловой системе. Он не связан с име-

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

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

вых систем, экспортируемых сервером. Он создается в момент создания файла.

Клиент остается в неведении о содержимом дескриптора файла, он абсолютно не-

прозрачен. Дескрипторы файлов занимают 32 байта в NFS версии 2, имеют пере-

менную длину до 64 байт в версии 3 и до 128 байт в версии 4. Разумеется, длина

дескриптора файла ни для кого не является секретом.

В идеале дескриптор файла реализован как истинный идентификатор файла

в данной файловой системе. Это означает, что в течение всего времени существо-

вания файла он имеет один и тот же дескриптор. Такое постоянство позволяет

клиенту локально сохранить дескриптор файла после того, как соответствующий

файл найден по имени. Одно из достоинств такого подхода

—

высокая произво-

дительность. Поскольку для большинства операций с файлами нужен дескрип-

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

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

10.1.

Сетевая файловая система компании Sun 635

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

файлами независимо от их текущих имен.

Поскольку дескриптор файла можно хранить на стороне клиента, важно не

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

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

жет по ошибке получить доступ к другому файлу.

Отметим, что комбинация операции итеративного разрешения имени файла

и запрета на пересечение этой операцией монтажной точки создает проблемы

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

файловой системе клиенту необходимо вместе с именем разрешаемого файла

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

производиться поиск. NFS версии 3 решает эту проблему, используя особый

протокол монтирования, при помощи которого клиент в действительности мон-

тирует удаленную файловую систему. После монтирования клиент получает кор-

невой дескриптор

файла {root file

handle)

смонтированной файловой системы, ко-

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

ка файла по имени.

В NFS версии 4 эта проблема решается путем предоставления специальной

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

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

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

других дескрипторов файла в файловой системе сервера. Такой подход имеет

дополнительное преимущество, состоящее в том, что теперь необходимость в от-

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

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

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

putrootfh разрешить имена относительно корневого дескриптора файлов.

Автоматическое монтирование

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

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

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

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

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

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

наково.

Другая проблема модели именования NFS связана с принятием решения

том,

в какой момент монтировать удаленную файловую систему. Рассмотрим

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

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

домашних каталогов других пользователей. Так, например, домашний каталог Али-

сы может быть доступен для нее локально как /home/alice, хотя на самом деле

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

роваться в тот момент, когда Алиса начнет работать на своей рабочей станции.

Кроме того, она может иметь доступ к открытым файлам Боба через каталог Бо-

ба /home/bob.

636 Глава 10. Распределенные файловые системы

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

роваться при входе Алисы в систему. Преимущество такого подхода состояло бы

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

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

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

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

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

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

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

Монтирование удаленных файловых систем (или собственно экспортируемо-

го каталога) по запросу осуществляется в NFS

автоматическим монтировщиком

(automounter)

—

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

шине клиента. Принципы, на которых основана работа автоматического монти-

ровщика, относительно просты. Рассмотрим простой автоматический монтиров-

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

системе UNIX (другие реализации этой программы можно найти в [80]).

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

вателей доступны через каталог /home, как было описано выше. При включении

клиентской машины автоматический монтировщик начинает свою работу, мон-

тируя этот каталог. В результате локального монтирования при любой попытке

доступа программ к каталогу /home ядро UNIX будет пересылать операцию lookup

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

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

Машина клиента

Машина сервера

Клиент NFS

Поиск «/home/alice»

Автомонтировщик

Создание вложенного

каталога «alice»

Интерфейс локальной файловой системы

home.

3. Запрос

на монтирование

4. Монтирование

вложенного каталога

«alice» с сервера

Рис. 10.6. Простой автоматический монтировщик

для

NFS

Так, например, представим, что Алиса входит в систему. Программа входа

в систему пытается прочитать каталог /home/alice, чтобы найти определенную

информацию, например сценарии подключения. Автоматический монтировщик.

10.1.

Сетевая файловая система компании Sun 637

получив запрос

на

поиск вложенного каталога /home/alice, должен сначала

со-

здать вложенный каталог /alice

каталоге /home. После этого

он

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

сервер NFS, который экспортирует домашний каталог Алисы,

монтирует этот

каталог в /home/alice. После этого алгоритм входа в систему выполняется далее.

Проблема такого подхода состоит

том,

что для

обеспечения прозрачности

автоматический монтировш;ик должен участвовать во всех операциях с файлами.

Если файл,

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

того,

что соответствующая файловая система еще

не

смонтирована, автоматиче-

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

То

есть он должен обрабатывать

все

запросы

на

чтение

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

ваны. Такой подход порождает серьезные проблемы производительности. Значи-

тельно лучше было бы, если

бы

автоматический монтировщик занимался только

монтированием

размонтированием каталогов,

все

остальное время оставаясь

незадействованным.

Простейшее решение

—

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

тировал каталоги

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

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

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

10.7.

home

/ \tmp mnt

alice

V ±

home

, alice

[«/tmp_mnt/home/alice»]

\^ ^^

Символическая

ссылка

Рис. 10.7. Использование символических ссылок

и автоматического монтирования

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

качестве

вложенного

каталог /tmpmnt. Когда Алиса входит

систему, автоматический

монтировщик монтирует

ее

домашний каталог

/tmp_mnt/home/alice

создает

символическую ссылку /home/alice, которая указывает

на

этот вложенный ката-

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

ду, связь

сервером NFS, экспортирующим домашнрн! каталог Алисы, осуществ-

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

-1

/home/al1ce

Атрибуты файла

Файл

NFS имеет несколько ассоциированных

ним атрибутов. В версии

3 на-

бор атрибутов

был

фиксирован,

любая реализация NFS должна была поддер-

живать

эти

атрибуты. Однако, поскольку система NFS традиционно строго сле-

довала идеологии, принятой

файловой системе UNIX, полная реализация NFS

638 Глава 10. Распределенные файловые системы

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

ной или даже невозможной.

В NFS версии

набор атрибутов файлов был разделен на набор обязательных

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

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

дополнительный набор

именованных атрибутов.

Именованные атрибуты

не

являются частью протокола NFS, они хранятся

виде массива пар

{атрибут,

значение),

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

виде

строк,

а их

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

не

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

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

живает операции

для

чтения

записи значений атрибутов. Однако всякая

ин-

терпретация атрибутов

и их

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

В табл. 10.2 перечислено некоторое количество обязательных атрибутов (все-

го

их

12). Эти атрибуты присутствовали

и в

предыдущих версиях NFS. Следует

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

По

значению

этого атрибута клиент может узнать, когда содержимое файла изменялось

в по-

следний раз.

Таблица 10.2. Некоторые из обязательных атрибутов файла в NFS

Атрибут Описание

TYPE Тип файла (обычный, каталог, символическая ссылка

т. д.)

SIZE Длина файла

байтах

CHANGE

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

изменялся ли файл

и/или

когда он изменялся

FSID Уникальный идентификатор файловой системы сервера,

на котором хранится файл

В табл. 10.3 перечислены некоторые из рекомендованных атрибутов. Текущая

версия NFS (версия

содержит 43 рекомендованных атрибута файлов. Одним

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

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

со

списком мест

расположения реплик файловой системы. Этот список может быть использован

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

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

[413].

Таблица 10.3. Некоторые из рекомендуемых атрибутов файла в NFS

Атрибут Описание

АСЕ

Список контроля доступа, ассоциированный

файлом

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

FILEID Уникальный идентификатор файла

файловой системе

FST_LOCATIONS Место расположения файловой системы

сети

OWNER

Имя владельца файла

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

TIME ACCESS Время последнего доступа

содержимому файла

10.1.

Сетевая файловая система компании Sun 639

Атрибут Описание

TIMEMODIFY Время последнего изменения содержимого файла

TIMECREATE Время создания файла

10.1.5. Синхронизация

ФаР1лы

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

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

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

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

лов,

необходима синхронизация. Синхронизация

—

дело относительно неслож-

ное,

если хранить файлы на центральном сервере. Такое решение, однако, способ-

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

иметь локальную копию файла,

из

которой они читают

и в

которую они пишут

данные. Отметим,

что

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

грузки (см. рис. 10.1,

б).

Перед тем

как

мы углубимся

детали синхронизации,

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

Семантика совместного использования файлов

Когда

два или

более пользователей совместно используют (разделяют) один

тот же файл, для предотвращения возникновения определенных проблем необ-

ходимо точно определить семантику чтения

записи. Чтобы понять семантику

разделения файлов

NFS, рассмотрим сначала некоторые общие понятия.

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

цессами, например UNIX, семантика подобных операций обычно состоит

том,

что операции чтения следуют

за

операциями записи,

то

есть чтение возвращает

записанное ранее значение, как показано

на

рис. 10.8, а. Таким образом, если од-

на

за

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

данные, записанные

на

диск

ходе последней операции записи.

действитель-

ности система поддерживает упорядоченность всех операций

по

абсолютному

времени

всегда возвращает последнее

по

времени значение.

Мы

будем назы-

вать

эту

модель семантикой UNIX (UNIX

semantics).

Эту

модель легко понять

и просто реализовать.

В распределенных системах семантика UNIX может успешно применяться до

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

клиен-

тами, не поддерживающими кэширование файлов. Все запросы на чтение

запись

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

их

строго последовательно.

Такой подход позволяет использовать семантику UNIX (если

не

принимать

во

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

сети, из-за которых

операция чтения, произошедшая

на

микросекунду позже операции запР1СР1,

мо-

жет достичь сервера первой

возвратить устаревшее значенрш).

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

которых

все запросы

файлам передаются

на

единственный сервер, часто слишком низ-

ка.

Эта

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

в их

внутреннем

локальном кэше копий часто используемых файлов. Хотя

мы

будем дополни-

640 Глава 10. Распределенные файловые системы

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

нам важно отметить, что если клиент локально модифицирует кэшируемый файл,

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

клиент получает устаревший вариант файла (рис. 10.8, б).

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

Запись «с» 1. Чтение «аЬ»

Файловый сервер

Исходный файл

Одиночная машинау

Процесс

/ а b с

а b

3. Чтение дает «аЬ»

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

Запись «с»

Чтение «аЬс»

Процесс

|-^

Рис. 10.8. В случае единственного процессора, когда чтение следует за записью,

прочитанное значение соответствует ранее записанному (а). В распределенной

системе с кэшированием клиент может получить устаревшее значение (б)

Один из способов справиться с этой проблемой

—

немедленная передача всех

изменений в кэшированных файлах на сервер. Несмотря на концептуальную про-

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

рассмотреть ослабление семантики совместного использования файлов. Вместо

того чтобы непременно требовать от операции чтения визуализации эффекта,

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

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

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

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

получить другие процессы (или машины). Введение этого правила не изменит

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

работы (В просто получает исходное значение файла). Когда процесс Л закроет

файл, он отошлет его копию на сервер, и последующее чтение, разумеется, при-

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

ем семантики сеансов

{session

semantics).

Как и многие другие распределенные