Особенности именованных каналов как средство реализации сетевых приложений

Named pipes and mailslots – это API, разработанные первоначально для OS/2 LAN Manager и затем перенесенные для Windows NT. Named pipes обеспечивают надежную двустороннюю связь, в то время как mailslots – ненадежную одностороннюю передачу данных. Преимущества mailslots в поддержке широковещательной передачи.

Серверы назначают именованным каналам и их клиентам имена в соответствии с универсальными правилами именования Windows 2000 Universal Naming Convention (UNC), который обеспечивает независимый от протоколов способ идентификации ресурсов в Windows network.

Коммуникационная связь по именованному каналу включает (named pipe server) сервер именованного канала и (named pipe client) клиента именованного канала. Сервер есть приложение, создающее именованный канал, к которому подключаются клиенты. Формат имени канала (pipe's name) выглядит так \\Server\Pipe\PipeName. Серверная компонента имени указывает на компьютер, на котором работает сервер именованного канала (сервер не может создаваться на удаленном компьютере), и его имя может быть DNS именем (например, mspress.microsoft.com), a NetBIOS именем (mspress) или IP адресом (255.0.0.0). Элемент Pipe должен быть строкой "Pipe," and PipeName – это уникальное имя канала. Уникальная часть имени канала может включать подкаталоги.

Для создания именованного канала сервер использует CreateNamedPipe Win32 функцию. Одним из входных параметров этой функции является указатель на имя канала, в форме \.\Pipe\PipeName. Значение "\\.\" в Win32-это псевдоним локального компьютера -"this computer."

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

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

Создание именованных каналов возможно только в NT-системах, подключение к созданному каналу возможно как в NT-системах, так и в Windows 9x. Кроме того, API работы с каналами в Win9x не поддерживает асинхронных операций ввода-вывода.

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

Заметим, что приложения могут выполнять над каналами Pipe синхронные или асинхронные операции, аналогично тому, как это можно делать с файлами. В случае использования асинхронных операций необходимо отдельно побеспокоиться об организации синхронизации.

По своему назначению именованные каналы похожи на каналы операционной системы UNIX. Базовым объектом для реализации именованных каналов служит объект "файл", поэтому для посылки и приема сообщений по именованным каналам используются те же самые функции Windows API, что и при работы с файлами (ReadFile, WriteFile).

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

При первом вызове CreateNamedPipe с указанием какого-либо имени создается первый экземпляр pipe с этим именем и задается поведение всех последующих экземпляров этого канала. Повторно вызывая CreateNamedPipe сервер может создать дополнительные экземпляры канала, максимальное число которых указывается при первом вызове. Создав минимум один экземпляр канала, сервер выполняет ConnectNamedPipe Win32 function, после чего сервер именованного канала позволяет устанавливать соединение с клиентом. ConnectNamedPipe может выполняться как синхронно, так и асинхронно, и она не завершится, пока клиент не установит соединение через данный экземпляр канала (или если не возникнет ошибка - error).

Для подключения к серверу клиенты канала используют Win32 CreateFile или CallNamedPipe функции, указывая при вызове имя созданного сервером канала. Если server вызывает ConnectNamedPipe, профиль защиты клиента и запрошенные им права доступа к каналу (read, write) сравниваются с дескриптором защиты канала. Если клиенту разрешен доступ к каналу, он получает описатель, представляющий клиентскую сторону, и функция ConnectNamedPipe, вызванная сервером, завершается.

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

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

После того как соединение по именованному каналу установлено, клиент и сервер могут использовать его для чтения и записи данных через ReadFile и WriteFile Win32функции для чтения и записи в канал. На рис. 2 показана коммуникационная связь клиента и сервера через именованный канал.

Рис. 2. Связь через именованный канал

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

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