Нерезидентная связь на основе сообщений

Множество распределенных систем и приложений непосредственно построено на базе простой модели обмена сообщениями, предоставляемой транспортным уровнем. Чтобы лучше понять и оценить системы, ориентированные на сообще­ния, как части решений промежуточного уровня, обсудим сперва обмен сообще­ниями через сокеты транспортного уровня.

Сокеты Беркли

Для стандартизации интерфейса транспортного уровня предпринимались специ­альные усилия. Это делалось для того, чтобы позволить программистам исполь­зовать полный комплект протоколов обмена сообщениями как простой набор примитивов. Кроме того, стандартные интерфейсы упрощают перенос приложе­ний на другие машины.

В качестве примера мы кратко рассмотрим интерфейс сокетов, введенный в версии UNIX, разработанной в университете Беркли (Berkeley UNIX). Другой

 

 

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

важный интерфейс, XTI, присутствующий в транспортном интерфейсе Х/Ореп, который официально именуется интерфейсом транспортного уровня {Transport Layer Interface, ТЫ), разработан организацией AT&T. Сокеты и XTI хорошо под­ходят к своим моделям сетевого программирования, но имеют разный набор при­митивов.

Концептуально сокет {socket) — это конечная точка коммуникации. В эту точку приложение может записывать данные, которые следует переслать по базовой сети, и из этой точки оно может читать приходящие данные. Сокеты об­разуют абстракцию, лежащую поверх реальной конечной точки сети, которая ра­ботает с локальной операционной системой по некоторому транспортному про­токолу. Далее мы сосредоточимся на примитивах сокетов для TCP, показанных в табл. 2.1.

Серверы обычно выполняют первые четыре примитива, чаще всего в приве­денном в таблице порядке. При вызове примитива socket вызывающий процесс создает новую конечную точку для некоторого транспортного протокола. Изнут­ри создание конечной точки коммуникации означает, что локальная операцион­ная система резервирует ресурсы для размещения приходящих и отправляемых по некоторому протоколу сообщений.

Примитив bind выполняет привязку локального адреса к только что создан­ному сокету. Например, сервер должен связать IP-адрес своей машины с номе­ром порта (возможно, общеизвестным) сокета. Привязка сообщает операцион­ной системе, что сервер намерен получать сообщения только на указанные адрес и порт.

Примитив listen применяется только для коммуникаций, ориентированных на соединение. Это неблокирующий вызов, требующий от локальной операцион­ной системы зарезервировать буфер для определенного максимального количе­ства соединений, которое вызывающий процесс намерен поддерживать.

Вызов примитива accept блокирует вызывающий процесс до прихода запроса на соединение. Когда этот запрос придет, локальная операционная система соз­даст новый сокет с теми же свойствами, что и у базового, и возвратит его вызы­вающему процессу. Такой подход позволяет серверу, например, разветвить про-

 

 

2.4. Связь посредством сообщений 133

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

Рассмотрим теперь, как все это выглядит со стороны клиента. И здесь все на­чинается с создания сокета при помощи примитива socket, однако в явной при­вязке сокета к локальному адресу нет необходимости, поскольку операционная система может динамически выделить порт при установлении соединения. При­митив connect требует, чтобы вызывающий процесс указал адрес транспортного уровня, на который будет отправлен запрос на соединение. Клиент блокируется до тех пор, пока соединение не будет установлено. После установления соеди­нения стороны начинают обмениваться информацией при помощи примитивов write и read, предназначенных для посылки и приема данных соответственно. Наконец, закрытие соединения при использовании сокетов симметрично и мо­жет быть осуществлено как клиентом, так и сервером путем вызова примитива close. Общая схема взаимодействия клиента и сервера с использованием сокетов для коммуникаций, ориентированных на соединение, показана на рис. 2.22. Мно­жество подробностей, относящихся к сетевому программированию с использова­нием сокетов и других интерфейсов в среде UNIX, можно найти в [438].

Интерфейс передачи сообщений

Работая на высокопроизводительных мультикомпьютерных системах, разработ­чики рассматривают примитивы, ориентированные на передачу сообщений, как средство, которое облегчит им написание высокоэффективных приложений. Это означает, что такие примитивы должны поддерживать подходящий уровень абст­ракции (для облегчения разработки приложений), а их реализация должна вызы­вать минимум дополнительных накладных расходов. Для сокетов это считается неосуществимым по двум причинам. Во-первых, их уровень абстракции явно не­достаточен — они поддерживают только простейшие примитивы send и receive. Во-вторых, сокеты были разработаны для связи между сетями с использованием стеков протоколов общего назначения, таких как TCP/IP. Они не подходят для специальных протоколов, разработанных для высокоскоростных взаимодейст­вующих сетей, например таких, которые используются в системе COW или МРР (мы рассматривали их в разделе 1.3). Эти протоколы требуют интерфейса, обла­дающего множеством дополнительных возможностей, таких как различные вари­анты буферизации и синхронизации.

 

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

В результате большинство взаимодействующих сетей и мультикомпьютерных систем оснащалось собственными коммуникационными библиотеками. Эти биб­лиотеки содержали множество эффективных высокоуровневых коммуникацион­ных примитивов. Разумеется, все библиотеки были абсолютно несовместимыми друг с другом, и теперь разработчики приложений имеют очевидные проблемы с переносимостью.

Требование независимости от аппаратного обеспечения постепенно привело к созданию стандарта пересылки сообщений, названному просто интерфейсом передачи сообщений {Message-Passing Interface, MPI). MPI разрабатывался для параллельных приложений, но затем был перенесен на нерезидентное взаимо­действие. Он предполагает использование базовых сетей и не предусматривает ничего, напоминающего коммуникационные серверы (см. рис. 2.19). Кроме того, он предусматривает, что серьезные сбои в системе, такие как аварии процессов или участков сети, фатальны и не могут быть восстановлены автоматически.

MPI предполагает, что связь происходит в пределах известной группы про­цессов. Каждая группа получает идентификатор. Каждый процесс в группе также получает идентификатор (локальный). Пара идентификаторов (groupID, processID), таким образом, однозначно определяет источник или получателя сообщения и используется вместо адреса транспортного уровня. В вычислениях может уча­ствовать несколько, возможно перекрывающихся, групп процессов, исполняе­мых одновременно.

В основе MPI лежат примитивы передачи сообщений, поддерживающие боль­шинство видов нерезидентного взаимодействия, показанных на рис. 2.21 (в-е), наиболее понятные из них собраны в табл, 2.2.

Фактически без поддержки остались только синхронные взаимодействия, по­казанные на рис. 2.21, г. Другими словами, MPI не поддерживает синхронизацию отправителя и получателя при передаче сообщения по сети.

Нерезидентная асинхронная связь (см. рис. 2.21, в) поддерживается примити­вом MPI_bsend. Отправитель отправляет сообщение на передачу. Обычно оно сперва копируется в локальный буфер исполняющей системы MPI. После того

 

2.4. Связь посредством сообщений 135

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

Также существует и операция передачи с блокировкой, которая называется MPI_send. Ее семантика зависит от реализации. Примитив MPI_send может блоки­ровать отправителя как на время копирования сообщения в исполняющую систе­му MPI на стороне отправителя, так и до момента инициирования получателем операции приема. Первый случай соответствует асинхронной связи, показанной на рис. 2.21, г, второй — на рис. 2.21, д.

Синхронная связь, при которой отправитель блокируется до передачи сооб­щения на дальнейшую обработку, как показано на рис. 2.21, д, поддерживается при помощи примитива MPI_ssend.

И наконец, наиболее жесткая форма синхронных коммуникаций показана на рис. 2.21, е. Когда отправитель вызывает примитив MPI_sendrecv, он посылает по­лучателю сообщение и блокируется до получения ответа. В основе работы этого примитива лежит обычный механизм RPC.

Примитивы MPI_send и MPI_ssend имеют варианты, исключающие необходи­мость копирования сообщения из буфера пользователя во внутренний буфер ло­кальной исполняющей системы MPI. Эти варианты соответствуют асинхронной связи. При помощи примитива MR_isend отправитель передает указатель на со­общение, после чего исполняющая система MPI начинает взаимодействие. От­правитель немедленно продолжает свою работу. Чтобы избежать изменения сообщения до момента окончания связи, MPI предоставляет примитивы для про­верки завершения передачи или, при необходимости, блокировки. Как и в случае MR_send, вопрос о том, нужно ли реально передавать сообщение или достаточно копирования в локальный буфер исполняющей системы MPI, оставлен на ус­мотрение разработчиков.

В случае вызова примитива MR_issend отправитель также передает исполняю­щей системе MPI только указатель. Когда исполняющая система показывает, что она обработала сообщение, отправитель удостоверяется, что получатель получил сообщение и в настоящее время работает с ним.

Операция MPI_recv вызывается для приема сообщения и блокирует запустив­ший процесс до прихода сообщения. Существует также и асинхронный вариант этой операции под именем MPI_irecv, вызовом которого получатель показывает, что он готов к приему сообщений. Получатель может проверить, имеются ли при­шедшие сообщения, или заблокироваться в ожидании таковых.

Семантика коммуникационных примитивов MPI не всегда проста, и иногда замена различных примитивов никак не влияет на правильность программы. Официальная причина поддержки такого разнообразия вариантов взаимодейст­вия состоит в том, что разработчики систем MPI должны иметь все возможности для оптимизации производительности. Циники могут сказать, что комитет, как всегда, не нашел в себе сил хорошенько подумать. Интерфейс MPI был разрабо­тан для высокопроизводительных параллельных приложений, что упрощает по­нимание причин подобного разнообразия коммуникационных примитивов.

 

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

Множество сведений по MPI содержится в [185]. Полное руководство, в ко­тором детально разобрано более 100 функций MPI, можно найти в [184, 425].