
- •1)Связь внутри процесса
- •2)Локальная связь
- •3)Удаленный сервер
- •1.3.2. Виды маршалинга в модели сом
- •Кому выгодны облачные вычисления?
- •Экономия за счет масштаба: сопоставление крупных и средних цод
- •2.3.1. Протокол передачи файлов ftp
- •2.3.2. Файловая система nfs
- •2.4.1. Назначение и принципы организации службы каталогов
- •2.4.2. Служба каталогов nds
- •Объектно-ориентированный подход
- •Дерево каталогов
- •Имена и контексты
- •2.4.3. Средства защиты объектов в nds
- •2.5.1 Основные подходы к организации межсетевого взаимодействия
- •2.5.2. Трансляция
- •2.5.3. Мультиплексирование стеков протоколов
- •2.5.4. Инкапсуляция протоколов
- •2.9.1. Системы на базе X.400
- •2.9.2. Системы на базе smtp
- •2.9.3. Системы на основе частных стандартов
- •2.9.4. Гибридные системы (ms Exchange Server)
- •Службы мсвс
- •Домен мсвс
- •Гетерогенные домены
- •1.6.3. Программирование с управлением по сообщениям (событиям)
- •1.6.4. Библиотеки для разработки прикладных программ в X Window
- •Язык и интерпретатор Tcl/Tk
- •2.10.3. Языки и средства создания Web-приложений
- •Примеры телекоммуникационных сетей
- •2.8.4. Стандарты систем управления
2.9.1. Системы на базе X.400
X.400 представляет собой набор рекомендаций по построению системы передачи электронных сообщений, не зависящей от используемых на сервере и клиенте операционных систем и аппаратных средств. Рекомендации X.400 являются результатом деятельности международного комитета по средствам телекоммуникаций. Рекомендации X.400 охватывают все аспекты построения среды управления сообщениями: терминологию, компоненты и схемы их взаимодействия, протоколы управления и передачи, форматы сообщений и правила их преобразования. Существуют несколько редакций рекомендаций.
Более поздние рекомендации описывают дополнительные протоколы и форматы передачи данных, корректируют неточности и/или изменяют трактовку более ранних. Исправления и дополнения к указанным спецификациям выпускаются ежегодно, однако существующие системы в подавляющем большинстве поддерживают рекомендации 1984 и/или 1988 годов. Эти спецификации не являются свободно доступными и распространяются за довольно высокую плату.
Рекомендации X.400 опираются на семиуровневую модель и семейство протоколов OSI. Поскольку рекомендации X.400 определяют набор спецификаций для самого верхнего уровня, отвечающие этим рекомендациям приложения должны свободно взаимодействовать друг с другом, вне зависимости от применяемых операционных систем, аппаратуры и сетевых протоколов.
Первые четыре уровня, от физического до транспортного, отвечают за организацию среды передачи данных. Реализуются частично на аппаратном уровне, частично, как сервисы ядра операционной системы. Верхние три уровня предназначены для использования операционной системой и исполняющимися поверх нее прикладными программами.
Для разделения входящего потока данных на каждом из уровней, транспортом, сеанса и представлений, используется механизм так называемых точек доступа (access point). Каждая точка доступа имеет уникальный идентификатор, или селектор, который может быть либо символьной строкой, либо последовательностью шестнадцатеричных цифр. Длина селектора транспортного уровня - 32 символа (64 цифры), уровня сеансов - 16 символов (32 цифры) и уровня представлений - 8 символов (16 цифр). Чтобы два приложения в сети могли взаимодействовать, каждое из них должно знать набор селекторов другого.
Рассмотрим подробнее, как в терминах X.400 определяются компоненты системы передачи электронных сообщений. На рис. 2.30 приведена схема построения среды управления сообщениями (Messaging Handling Environment или MHE). Эта схема является классической, и в терминах этой схемы может быть описана структура и принципы функционирования любой существующей почтовой системы на любой платформе.
Как видно из рисунка, среда управления сообщениями представляет собой объединение систем управления сообщениями (Messaging Handling Systems или MHS), которые могут быть произвольным образом связаны между собой посредством шлюзов и/или публичных информационных сетей. Каждая из систем управления сообщениями в свою очередь состоит из следующих компонентов:
Рис. 2.30. Схема построения среды управления сообщениями
пользовательский агент (User Agent или UA), подсистема, выступающая в роли клиента в процессе обмена почтовыми сообщениями, клиент же в свою очередь может быть как реальным пользователем, так и процессом, использующим сервисы электронной почты;
агент передачи сообщений (Message Transfer Agent или MTA), подсистема, в обязанности которой входит обмен сообщениями с пользовательскими агентами и/или внешними и локальными агентами передачи сообщений. Каждый агент передачи сообщений может иметь имя и пароль доступа;
система передачи сообщений (Message Transfer System или MTS), которая состоит из одного или нескольких MTA и выполняет функции приема, доставки и промежуточного хранения сообщений;
хранилище сообщений (Message Store или MS), подсистема, в функции которой входит посылка, прием и хранение сообщений от пользовательских агентов и агентов передачи сообщений, в составе MHS может иметь более одного хранилища.
Из всего многообразия описанных в рекомендациях X.400 способов взаимодействия между UA, MTA и MS рассмотрим следующие:
отправка сообщения пользовательским агентом через хранилище, в этом случае пользователь, используя свой агент UA, помещает сообщение, предназначенное для доставки другому пользователю, непосредственно в хранилище сообщений. Оттуда оно выбирается локальным или удаленным MTA и передается дальше;
отправка сообщения пользовательским агентом через MTA, в этом случае сообщение передается напрямую от UA к MTA и далее доставляется его средствами;
получение сообщения агентом пользователя из хранилища, в этом случае MTA осуществляет доставку сообщения в хранилище (почтовый ящик пользователя), для дальнейшей обработки UA;
получение сообщения агентом пользователя от MTA, в этом случае пользовательский агент не имеет непосредственного доступа к хранилищу, а для получения сообщений обращается к агенту передачи.
Любая из ныне известных почтовых систем использует один из перечисленных способов отправки и приема сообщений.
Из всего многообразия описанных в рекомендациях X.400 способов взаимодействия между UA, MTA и MS рассмотрим следующие:
отправка сообщения пользовательским агентом через хранилище, в этом случае пользователь, используя свой агент UA, помещает сообщение, предназначенное для доставки другому пользователю, непосредственно в хранилище сообщений. Оттуда оно выбирается локальным или удаленным MTA и передается дальше;
отправка сообщения пользовательским агентом через MTA, в этом случае сообщение передается напрямую от UA к MTA и далее доставляется его средствами;
получение сообщения агентом пользователя из хранилища, в этом случае MTA осуществляет доставку сообщения в хранилище (почтовый ящик пользователя), для дальнейшей обработки UA;
получение сообщения агентом пользователя от MTA, в этом случае пользовательский агент не имеет непосредственного доступа к хранилищу, а для получения сообщений обращается к агенту передачи.
Как будет показано далее, любая из ныне известных почтовых систем использует один из перечисленных способов отправки и приема сообщений.
Дополнительно в состав MHS могут входить следующие компоненты, которые не являются специфическими для X.400 и определены в отдельной спецификации - X.500:
пользовательский агент доступа к каталогу (Directory User Agent или DUA), подсистема, выступающая в роли клиента при доступе к каталогу;
системный агент доступа к каталогу (Directory System Agent или DSA), подсистема, являющаяся частью каталога и предоставляющая доступ к хранящейся в нем информации локальным и внешним DUA и DSA.
Не менее важными компонентами спецификации X.400 являются следующие компоненты (рис. 2.31):
списки рассылки (Distribution Lists или DL), содержащие ноль или более членов, каждый из которых может быть либо пользователем системы управления сообщениями, либо другим списком рассылки. Будучи отправлено на адрес списка рассылки, сообщение будет доставлено всем его членам, включая вложенные списки пользователей;
устройство доступа (Access Unit или AU), больше известное как шлюз (Gateway), устройство, обеспечивающее сопряжение с внешней средой передачи данных, например с телекс- или телетайп-сетями;
каталог (Directory), назначением которого является хранение информации об объектах, входящих в состав системы управления сообщениями. Понятие каталога было введено впервые в 1988 году, и реализация этой части в системе X.400 является не обязательной.
Интерперсональное сообщение является составным объектом. На рис. 2.32 приведена схема, поясняющая структуру электронного письма и IPM.
Рис. 2.31. Дополнительные компоненты системы управления сообщениями
IPM состоит из заголовка (header) и тела (body). Заголовок обычно включает в себя копию информации, указанной на конверте, и дополнительных полей, определяющих расширенные свойства сообщения. Тело в свою очередь может быть составным и включать различные типы информации, такие как плоский текст, графика, документы различных форматов, вложенные сообщения и т.д. Отдельные части сообщения именуются body parts. В настоящее время используются два формата IPM, различающиеся набором поддерживаемых типов данных и правил кодирования текста, содержащего символы национальных алфавитов: P2, используемый в системах X.400 1984 года, и P22, используемый в системах X.400 1988 года. Эти форматы совместимы снизу вверх, т.е. системы 1988 года могут работать как с содержимым в формате P2, так и P22.
Рис. 2.32. Структура сообщения X.400
Еще один тип содержимого сообщений X.400 - интерперсональная нотификация (Inter Personal Notification). Нотификация используется для автоматического уведомления отправителя о факте доставки и/или прочтения посланного им сообщения. IPN представляет собой плоский текст произвольного содержания с кодировкой в ASCII. Прочие типы содержимого несут служебную нагрузку и используются исключительно для взаимодействия систем между собой.
Семейство протоколов X.400 не получило широкого распространения за пределами государственных и банковских учреждений. Недостатки этого стандарта - чрезмерная сложность реализации и значительная стоимость внедрения и эксплуатации систем на его основе. Отсутствие свободного доступа к стандартам и проблемы несовместимости MTA версий 1984 и 1988 годов также отрицательно сказались на темпах внедрения X.400 в качестве глобальной среды передачи данных.