Коммуникации в ядре Mach. Сетевые операционные системы

Основной целью, которую ставили перед собой разработчики средств коммуникации ядра Mach, являлась поддержка различных стилей коммуникаций в сочетании с надежностью и гибкостью. Коммуникационные средства ядра Mach могут поддерживать асинхронную передачу сообщений, RPC, потоки байт (streams), а также другие способы. Механизм взаимодействия процессов Mach базируется на соответствующих механизмах своих предшественников - RIG и Accent. Из-за своего эволюционного развития этот механизм приспособлен больше для локального использования, а не для распределенных систем.

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

Порты

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

Порт поддерживает взаимодействие подобно конвейерам (pipes) в UNIX. Порт, который может быть использован для отправки запроса от клиента серверу, не может использоваться для отправки ответа от сервера клиенту. Для этого нужен второй порт. У каждого порта может быть только один процесс, читающий из него сообщения, и несколько процессов, пишущих в порт.

Порты поддерживают надежный и последовательный обмен сообщениями. Если нить посылает сообщения в порт, то система гарантирует, что оно будет доставлено. Сообщения никогда не теряются из-за ошибок, переполнения или других причин (по крайней мере, если нет отказов аппаратуры). Также гарантируется, что сообщения, отправленные одной нитью, будут получены в том же порядке. Если же две нити пишут в один и тот же порт попеременно, то система не дает никаких гарантий о последовательности сообщений, так как в ядре сообщения буферизуются. В отличие от конвейера, порты поддерживают поток не байтов, а сообщений. Несколько сообщений никогда не соединяются вместе в одно сообщение.

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

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

Если при использовании порта возникает ошибка, то о ней сообщается путем посылки сообщений на другие порты, чьи права хранятся здесь. Нити могут быть заблокированы при чтении из порта, поэтому в структуру порта включен указатель на список заблокированных нитей. Также важна возможность нахождения прав на чтение из порта (он может быть только один), поэтому такая информация тоже хранится в структуре данных порта. Если порт представляет собой порт процесса, то следующее поле содержит указатель на процесс, к которому порт относится. Если это порт нити, то это поле содержит указатель на структуру данных ядра для нити, и так далее. Имеется также несколько дополнительных полей, не описанных здесь.

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

Нить может передать права доступа к порту другой нити другого процесса. Ясно, что нельзя проделать это просто помещением соответствующего целого числа в сообщение, так же как и UNIX-процесс не может передать дескриптор файла для стандартного устройства вывода путем записи 1 в конвейер. Используемый для этого механизм защищен ядром, мы обсудим его позже. В данный момент времени важно только знать, что это можно сделать.

На рисунке 6.9 мы видим ситуацию, в которой два процесса, А и В, имеют доступ к одному и тому же порту. Процесс А послал сообщение для данного порта, а процесс В прочитал это сообщение. Заголовок и тело сообщения физически копируются из А в порт, а затем из порта в В.

Для удобства порты можно группировать в наборы портов. Порт может относится максимум к одному набору портов. Можно произвести операцию чтения из набора портов (но записать сообщение можно только в один порт). Например, сервер может использовать этот механизм для одновременного чтения из большого количества портов. Ядро возвращает одно сообщение от одного порта набора. В отношении того, какой порт будет выбран, не дается никаких обещаний. Если все порты пусты, то сервер блокируется. В этом случае сервер может поддерживать разные порты для каждого из многих поддерживаемых им объектов и получать сообщения для каждого из них без необходимости выделять нить для каждого объекта. В соответствии с текущей реализацией все сообщения для набора портов ставятся в общую очередь, так что на практике нет особой разницы между получением из порта и получением из набора портов.

Некоторые порты используются особым образом. Каждый процесс имеет специальный порт - порт процесса, который нужен для связи процесса с ядром. Большая часть "системных вызовов", связанных с процессами (смотрите табл. 6.1), делается путем посылки сообщения в этот порт. Аналогично, каждая нить имеет свой собственный порт для выполнения "системных вызовов", связанных с нитями. Взаимодействие с драйверами ввода-вывода также реализуется с использованием механизма портов.

В первом приближении, для каждого процесса ядро поддерживает таблицу всех портов, к которым он имеет доступ. Эта таблица хранится в ядре, так что пользовательский процесс не может получить к ней доступ. Процесс ссылается на порты, указывая номер их позиции в этой таблице, например, 1, 2 и так далее. Входы этой таблицы содержат указатели на порты и определяют разрешенные над ними действия, и называются мандатами. Назовем таблицу списком прав доступа (списком мандатов).

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

Все нити одного процесса имеют равные права по доступу к портам процесса. Права определяются по отношению к трем возможным операциям: ПОЛУЧИТЬ, ПОСЛАТЬ и ПОСЛАТЬ-ОДИН-РАЗ. Право ПОЛУЧИТЬ дает возможность обладателю этого права прочитать сообщение из порта. Ранее упоминалось, что связи в Mach однонаправленные. Это означает, что в любой произвольный момент только один процесс может иметь право ПОЛУЧИТЬ для данного порта. Мандат с правом ПОЛУЧИТЬ можно передавать другому процессу, но это означает, что он будят изъят у исходного процесса. Таким образом, для каждого порта имеется только один потенциальный получатель.

Мандат с правом ПОСЛАТЬ позволяет его владельцу отсылать сообщения определенному порту. Таким правом могут обладать многие процессы. Эта ситуация является грубым аналогом банковской системы во многих странах: каждый, кто знает номер банковского счета, может положить на него деньги, но только владелец может снять деньги со счета.

Право ПОСЛАТЬ-ОДИН-РАЗ также позволяет отослать сообщение, но только однократно. После того, как сообщение отослано, ядро отбирает это право. Этот механизм используется для протоколов типа запрос-ответ. Например, клиент хочет, чтобы сервер выполнил какой-то его запрос, поэтому он создает порт для получения ответа. Затем он отсылает сообщение-запрос серверу, содержащее защищенный мандат для порта ответа с правом ПОСЛАТЬ-ОДИН-РАЗ. После того, как сервер отошлет ответ, мандат отзывается из его списка прав доступа, и мандат с таким именем может быть только вновь внесен в список прав в будущем.

Имена прав доступа имеют действие только внутри процесса. Два процесса могут иметь доступ к одному и тому же порту, но использовать для этого разные имена. На рисунке 6.10 оба процесса имеют право посылать сообщения на порт Y, но для процесса А это мандат номер 3, а для процесса В - мандат 4.

Список прав доступа привязан к определенному процессу. Когда этот процесс завершается или уничтожается, его список удаляется. Порты, для которых он содержал право на операцию ПОЛУЧИТЬ, больше не могут использоваться, и они уничтожаются, даже если в них есть недоставленные сообщения.

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

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

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

Наконец, четвертая возможность отмечает порты, которые уже не существуют, но для которых права ПОСЛАТЬ еще существуют. Например, когда порт удаляется из-за того, что процесс, имеющий право ПОЛУЧИТЬ для него, завершен, ядро отслеживает все права ПОСЛАТЬ и помечает их как несуществующие. Попытка послать сообщение с нулевым и несуществующим правом приводит к ошибке с соответствующим кодом. Когда все права ПОСЛАТЬ для порта отменены, неважно по каким причинам, ядро может (опционально) отослать сообщение, уведомляющее получателя, что не осталось ни одного отправителя, и можно не ожидать сообщений.

Mach имеет свыше 20 вызовов для управления портами. Все они вызываются путем отправки сообщения на порт процесса. Наиболее важные из них представлены в таблице 6.6.

Таблица 6.6.
Некоторые вызовы управления портами в Mach

Первый вызов, Allocate, создает новый порт и вводит его право в список прав процесса, выполнившего этот вызов. Это право является правом ПОЛУЧИТЬ из этого порта. Имя права возвращается, так что порт можно использовать.

Следующие два вызова отменяют действие первого. Destroy удаляет право. Если это право ПОЛУЧИТЬ, то порт разрушается и все остальные права для него во всех процессах помечаются как недействительные. Deallocate уменьшает счетчик ссылок, связанный с правом. Если он равен нулю, то право удаляется, но порт остается существовать. Вызов Deallocate может использоваться только для удаления прав ПОСЛАТЬ и ПОСЛАТЬ_ОДИН_РАЗ или недействительных прав.

Вызов Extract_right позволяет нити выбрать право из списка прав другого процесса и вставить это право в свой собственный список. Конечно, вызывающая нить должна иметь доступ к порту процесса, управляющего другим процессом (например, своим потомком). Insert_right работает иначе. Он позволяет процессу взять одно из своих прав и добавить его в список прав другого процесса (например, своего потомка).

Вызов Move_member используется для управления набором портов. Он может добавить порт к набору портов или удалить порт. Наконец, вызов Set_qlimit определяет максимальное количество сообщений, которые порт может хранить. Когда порт создается, то их по умолчанию 5, но с помощью вызова Set_qlimit это количество может быть увеличено или уменьшено. Сообщения могут иметь любую длину, так как они сами не хранятся портом.

Отправка и получение сообщений

Конечной целью создания портов является возможность отправки в них сообщений. В этом разделе поясняется, как сообщения отправляются, как получаются и что они содержат. Mach поддерживает один системный вызов для отправки и получения сообщений. Этот вызов содержится внутри библиотечной процедуры, называемой mach_mes. Она имеет семь параметров и большое количество опций. Чтобы дать представление о ее сложности, нужно отметить, что существует 35 различных кодов возврата ошибочных ситуаций. Ниже дается упрощенный обзор некоторых возможностей этой процедуры. К счастью, она используется в функциях, генерируемых чаще компилятором заглушек (stub compiler), а не вручную.

Итак, вызов mach_mes используется и для отправки и для получения сообщений. Он может отослать сообщение в порт, а затем вернуть управление вызвавшей mach_mes функции немедленно, так что она может модифицировать буфер сообщения, не влияя на посланные данные. Он может также использоваться для попытки получения сообщения из порта, причем, если порт пуст, он либо блокирует вызвавшую нить, либо отказывается от попытки по истечении некоторого тайм-аута. Наконец, можно объединять операции отправки и получения, сначала отсылая сообщение, а затем блокируя нить до получения ответа. В последнем режиме вызов mach_mes можно использовать для реализации RPC.

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

Детали формата сообщения будут рассмотрены ниже, а сейчас необходимо отметить, что заголовок содержит имя права доступа для порта назначения. Эта информация нужна ядру, так как ядро из нее узнает о том, куда нужно отправить сообщение. Когда выполняется операция только ПОЛУЧИТЬ, заголовок не заполняется, так как он будет полностью переписан пришедшим сообщением.

Второй параметр, options, содержит бит, определяющий, что сообщение должно быть отправлено, и другой бит, который говорит о том, что оно должно быть получено. Если оба бита включены, то выполняется RPC. Еще один бит разрешает тайм-аут, величина которого указана в параметре timeout в миллисекундах. Если требуемая операция не может быть выполнена за время тайм-аута, то вызов возвращает код ошибки. Если часть ПОСЛАТЬ вызова RPC не выполняется за отведенное время (например, порт назначения заполнен в течение слишком большого времени), то часть ПОЛУЧИТЬ просто не выполняется.

Остальные биты поля options позволяет операции ПОСЛАТЬ, которая не может завершиться немедленно, вернуть управление, а сообщение о статусе завершения посылается на notify_port позже.

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

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

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

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

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

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

Следует упомянуть о некоторых вопросах, связанных с приемом сообщений. Во-первых, что делать, если поступившее сообщение имеет длину больше, чем длина буфера? Предусмотрено два варианта: удалить это сообщение или же вернуть вместе с кодом ошибки данный размер, чтобы позволить вызвавшей функцию mach_mes нити повторить передачу с буфером большего размера.

Если существует несколько нитей, блокированных на операции ПОЛУЧИТЬ из одного и того же порта, и сообщение поступает в порт, то системой выбирается одна из них для получения сообщения. Остальные остаются блокированными.

Как уже было сказано, тело сообщения может быть простым или сложным, в зависимости от значения управляющего бита заголовка. Структура сложного сообщения показана на рисунке 6.11. Тело сложного сообщения состоит из последовательности пар (дескриптор, поле данных). Каждый дескриптор несет информацию о том, что находится в поле данных, следующим непосредственно за дескриптором. Дескриптор может иметь два формата, различающихся только количеством бит в каждом его поле. Обычный формат дескриптора приведен на рисунке 6.12. Дескриптор определяет тип последующих данных, их длину, и количество однотипных данных (поле может содержать некоторое число данных одного типа). Возможны такие типы данны, как последовательность бит и байт, целое число различной длины, неструктурированное машинное слово, булевское значение, число с плавающей запятой, строка и мандат (право доступа). Имея такую информацию, система может попытаться выполнить преобразование данных между машинами, если они имеют различные внутренние представления данных. Это преобразование выполняется не ядром, а сервером сетевых сообщений (описан ниже). Преобразование данных выполняется и для простых сообщений (также этим сервером).

Рис. 6.12. Дескриптор комплексного сообщения

Одним из наиболее интересных типов данных, которые могут содержаться в поле данных сообщения, является мандат. Используя сложные сообщения, можно копировать или передавать мандаты доступа от одного процесса другому. Так как в Mach права доступа являются защищенными объектами ядра, то для их передачи нужен защищенный механизм.

Этот механизм состоит в следующем. Дескриптор может определить, что слово, стоящее в сообщении непосредственно за ним, содержит имя одного из прав доступа отправителя, и что это право нужно переслать процессу-получателю и вставить в его список прав. Этот дескриптор также определяет, должно ли право копироваться (то есть оригинал остается нетронутым) или же перемещаться (оригинал удаляется).

Кроме того, некоторые значения характеристики дескриптора Тип поля данных указывают ядру на то, что нужно модифицировать право при копировании или передаче. Например, право ПОЛУЧИТЬ может трансформироваться в право ПОСЛАТЬ или ПОСЛАТЬ-ОДИН-РАЗ, так что получатель сможет посылать ответ через порт, к которому у отправителя есть только право ПОЛУЧИТЬ. Действительно, нормальным способом установления взаимодействия между двумя процессами является создание одним из них порта, а затем отправка мандата ПОЛУЧИТЬ для этого порта другому процессу, превращая его в мандат ПОСЛАТЬ по дороге.

Рис. 6.13. (а) Ситуация перед отправкой мандата; (б) Ситуация после его прибытия

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

Мы видим два процесса, А и В, имеющие мандат 3 и 1 соответственно. Все права являются правом только ПОЛУЧИТЬ. Нумерация начинается с 1, так как значение 0 обозначает нуль-порт. Одна из нитей процесса А отправляет сообщение процессу В, и в этом сообщении содержится мандат 3.

Когда сообщение прибывает, ядро проверяет заголовок и видит, что это сложное сообщение. Затем ядро начинает обрабатывать дескрипторы в теле сообщения, один за другим. В этом примере сообщение содержит только один дескриптор, описывающий мандат и инструкции ядру, что его нужно превратить в мандат ПОСЛАТЬ (или, может быть ПОСЛАТЬ-ОДИН-РАЗ). Ядро выделяет одну свободную запись в списке права доступа получателя, например, запись номер 2 в данном случае, и модифицирует сообщение таким образом. что слово, следующее за дескриптором, теперь содержит значение 2, а не 3. Когда приемник получает сообщение, то он видит, что оно содержит новое право, с именем (индексом) 2. Он может использовать его немедленно, для отправки ответа.

Имеется еще один интересный тип данных, которые может передавать сообщение: внешние данные (out-of-line). Эти данные не содержатся непосредственно в сообщении, а описаны как область виртуального адресного пространства отправителя. Тем самым в Mach обеспечивается возможность передачи в пределах машины большого количества данных без их физического копирования. Слово, следующее за дескриптором внешних данных, содержит адрес, а размер и количество полей дает 20-битный счетчик байтов. Все вместе это и определяет область виртуального адресного пространства. Для больших областей используется увеличенная форма дескриптора.

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

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

Сервер сетевых сообщений

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

Сервер сетевых сообщений (Network Message Server) - это многонитевый процесс, который реализует многие функции. Они включают взаимодействие с локальными нитями, передачу сообщений через сеть, трансляцию типов данных из представления одной машины в представление другой машины, управление права доступа защищенным образом, удаленное уведомление, поддержку простого сервиса поиска сетевых имен, аутентификацию других сетевых серверов. Серверы сетевых сообщений должны поддерживать различные сетевые протоколы, в зависимости от сетей, к которым они присоединены.

Основной метод, с помощью которого сообщения пересылаются через сеть, иллюстрируется рисунком 6.14. На нем изображена машина-клиент А и машина-сервер В. Прежде, чем клиент сможет взаимодействовать с сервером, на машине А должен быть создан порт, чтобы работать как передаточное звено для сервера. Сервер сетевых сообщений имеет право ПОЛУЧИТЬ для этого порта. Нить сервера всегда прослушивает этот порт (и другие удаленные порты, которые вместе образуют набор портов). Этот порт показан как небольшой квадрат внутри ядра машины А.

Передача сообщения от клиента серверу требует пяти шагов, пронумерованных на рисунке 6.14 от 1 до 5. Во-первых, клиент посылает сообщение порту-посреднику сервера сетевых сообщений своей машины. Во-вторых, сервер сетевых сообщений получает это сообщение. Так как это сообщение сугубо локальное, то с помощью него могут быть посланы внешние данные или данные режима копирование-при-записи. В-третьих, сервер сетевых сообщений ищет локальный порт, в нашем примере 4, в таблице, которая отображает порты-посредники на сетевые порты. Когда сетевой порт становится известен, сервер сетевых сообщений начинает искать его в других таблицах. Затем он конструирует сетевое сообщение, содержащее локальное сообщение плюс любые внешние данные, и посылает его по локальной сети серверу сетевых сообщений на машине-сервере. В некоторых случаях трафик между серверами сетевых сообщений должен быть зашифрован для защиты информации. Ответственность за разбивку сообщения на пакеты и инкапсуляцию их в формат соответствующего протокола несет транспортный модуль.

Рис. 6.14. Межмашинное взаимодействие в Mach выполняется за пять шагов

Когда сервер сообщений удаленной сети получает сообщение, он берет из него номер сетевого порта и отображает его на номер локального порта. На шаге 4 сервер записывает сообщение в этот локальный порт. Наконец, локальный сервер машины В читает сообщение из локального порта и выполняет запрос клиента машины А. Ответ проходит по этому же пути в обратном направлении.

Сложное сообщение требует небольшой дополнительной работы. Для обычных полей данных сервер сетевых сообщений на машине-сервере выполняет преобразование форматов данных, если это необходимо (например, изменяет порядок байт в слове). Обработка прав доступа при пересылке через сети также усложняется. Когда мандат пересылается через сеть, должен быть назначен номер сетевого порта, и оба сервера сетевых сообщений, отправитель и получатель, должны сделать соответствующие записи в своих таблицах отображения. Если эти машины не доверяют друг другу, необходимы тщательно разработанные процедуры аутентификации, чтобы каждая из машин убедилась в идентичности другой.

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

Знаете ли Вы, что релятивистское объяснение феномену CMB (космическому микроволновому излучению) придумал человек выдающейся фантазии Иосиф Шкловский (помните книжку миллионного тиража "Вселенная, жизнь, разум"?). Он выдвинул совершенно абсурдную идею, заключавшуюся в том, что это есть "реликтовое" излучение, оставшееся после "Большого Взрыва", то есть от момента "рождения" Вселенной. Хотя из простой логики следует, что Вселенная есть всё, а значит, у нее нет ни начала, ни конца... Подробнее читайте в FAQ по эфирной физике.