Э. Таненбаум, М. ван Стеен - Распределённые системы (принципы и парадигмы) (1162619), страница 34

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 34)

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

Клиент блокируетсядо тех пор, пока соединение не будет установлено. После установления соеди­нения стороны начинают обмениваться информацией при помощи примитивовwrite и read, предназначенных для посылки и приема данных соответственно.Наконец, закрытие соединения при использовании сокетов симметрично и мо­жет быть осуществлено как клиентом, так и сервером путем вызова примитиваclose. Общая схема взаимодействия клиента и сервера с использованием сокетовдля коммуникаций, ориентированных на соединение, показана на рис.

2.22. Мно­жество подробностей, относящихся к сетевому программированию с использова­нием сокетов и других интерфейсов в среде UNIX, можно найти в [438].СерверI socket | - > |^bind |—>| listen | - > | accept |^Точка синхронизации — • ;write ~ К — Н close/II socket Iread | - ^ |\/ Взаимодействие^Н connectl—H write"]Нread ]—Н close |КлиентРис. 2 .

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

Для сокетов это считаетсянеосуществимым по двум причинам. Во-первых, их уровень абстракции явно не­достаточен — они поддерживают только простейшие примитивы 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 . 2 . Некоторые из наиболее понятных примитивов MPIПримитивНазначениеМР1__bsenclПоместить исходящее сообщение в локальный буфер отсылкиМР1__senclПослать сообщение и ожидать, пока оно не будет скопированов локальный или удаленный буферMPI ssendПослать сообщение и ожидать начала его передачи на обработкуМР1__sendrecvПослать сообщение и ожидать ответаМР1_J sendПередать ссылку на исходящее сообщение и продолжить работуМР1_ 1ssendПередать ссылку на исходящее сообщение и ожидать началаего передачи на обработкуМР1_fecvПринять сообщение, блокировать работу в случае его отсутствияMPI irecvПроверить наличие входящих сообщений, не блокируя работыФактически без поддержки остались только синхронные взаимодействия, по­казанные на рис.

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

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

2.21, г, второй ~ на рис. 2.21, д.Синхронная связь, при которой отправитель блокируется до передачи сооб­щения на дальнейшую обработку, как показано на рис. 2.21, Э, поддерживаетсяпри помощи примитива MPI_ssencl.И наконец, наиболее жесткая форма синхронных коммуникаций показана нарис. 2.21, е. Когда отправитель вызывает примитив MPI_sendrecv, он посылает по­лучателю сообщерп1е и блокируется до получения ответа. В основе работы этогопримитива лежит обычный механизм RFC.Примитивы MPI_senci и MPI_ssend имеют варианты, исключающею необходи­мость копирования сообщения из буфера пользователя во внутренний буфер ло­кальной исполняющей системы MPI. Эти варианты соответствуют асинхроннойсвязи.

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

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

Циники могут сказать, что комитет, каквсегда, не нашел в себе сил хорошенько подумать. Интерфейс MPI был разрабо­тан для высокопроизводительных параллельных приложений, что упрощает по­нимание причин подобного разнообразия коммуникационных примитивов.136Глава 2. СвязьМножество сведений по MPI содержится в [185]. Полное руководство, в ко­тором детально разобрано более 100 функций MPI, можно найти в [184, 425].2.4.3. Сохранная связь на основе сообщенийНу вот мы и подошли к важному классу ориентированных на сообщения службпромежуточного уровня, известных как системы очередей сообщепий (messagequeuing systems), или ориеитированиый па сообщения промежуточный уровень{Message-Onented Middleware, MOM).

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

Эти сообщения передаются по цепочке коммунргкационных серверови в конце концов достигают места назначения, даже в том случае, если получа­тель в момент отправки сообщения был неактивен. На практике большинствокоммуникационных серверов напрямую соединены друг с другом. Другими сло­вами, сообщение обычно пересылается непосредственно на сервер получателя.В принципе каждое приложение имеет собственную очередь, в которую могут по­сылать сообщения другие приложения. Очередь может быть прочитана толькосвязанным с ней приложением, при этом несколько приложений могут совместноиспользовать одну очередь.Важный момент в системах очередей сообщений СОСТОРГТ В ТОМ, ЧТО отправи­тель обычно в состоянии гарантировать только попадание сообщения — рано илипоздно — в очередь получателя. Никакие гарантии относительно того, будет лисообщение действительно прочитано, невозможны, это полностью определяетсяповедением получателя.Подобная семантика определяет слабосвязанное взаимодействие.

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

Список файлов книги