|
Программы, поддерживающие
межмашинную связь, такие, как
электронная почта, программы
дистанционной пересылки файлов и
удаленной регистрации, издавна
используются в качестве
специальных средств организации
подключений и информационного
обмена. Так, например,
стандартные программы,
работающие в составе электронной
почты, сохраняют текст почтовых
сообщений пользователя в
отдельном файле (для
пользователя "mjb" этот файл
имеет имя "/usr/mail/mjb").
Когда один пользователь посылает
другому почтовое сообщение на ту
же машину, программа mail
(почта) добавляет сообщение в
конец файла адресата, используя
в целях сохранения целостности
различные блокирующие и
временные файлы. Когда адресат
получает почту, программа mail
открывает принадлежащий ему
почтовый файл и читает
сообщения. Для того, чтобы
послать сообщение на другую
машину, программа mail должна в
конечном итоге отыскать на ней
соответствующий почтовый файл.
Поскольку программа не может
работать с удаленными файлами
непосредственно, процесс,
протекающий на другой машине,
должен действовать в качестве
агента локального почтового
процесса; следовательно,
локальному процессу необходим
способ связи со своим удаленным
агентом через межмашинные
границы. Локальный процесс
является клиентом удаленного
обслуживающего (серверного)
процесса.
Поскольку в системе UNIX новые
процессы создаются с помощью
системной функции fork, к тому
моменту, когда клиент попытается
выполнить подключение,
обслуживающий процесс уже должен
существовать. Если бы в момент
создания нового процесса
удаленное ядро получало запрос
на подключение (по каналам
межмашинной связи), возникла бы
несогласованность с архитектурой
системы. Чтобы избежать этого,
некий процесс, обычно init,
порождает обслуживающий процесс,
который ведет чтение из канала
связи, пока не получает запрос
на обслуживание, после чего в
соответствии с некоторым
протоколом выполняет установку
соединения. Выбор сетевых
средств и протоколов обычно
выполняют программы клиента и
сервера, основываясь на
информации, хранящейся в
прикладных базах данных; с
другой стороны, выбранные
пользователем средства могут
быть закодированы в самих
программах.
В
качестве примера рассмотрим
программу uucp, которая
обслуживает пересылку файлов в
сети и исполнение команд на
удалении (см. [Nowitz 80]).
Процесс-клиент запрашивает в
базе данных адрес и другую
маршрутную информацию (например,
номер телефона), открывает
автокоммутатор, записывает или
проверяет информацию в
дескрипторе открываемого файла и
вызывает удаленную машину.
Удаленная машина может иметь
специальные линии, выделенные
для использования программой
uucp; выполняющийся на этой
машине процесс init порождает
getty-процессы - серверы,
которые управляют линиями и
получают извещения о
подключениях. После выполнения
аппаратного подключения
процесс-клиент регистрируется в
системе в соответствии с обычным
протоколом регистрации:
getty-процесс запускает
специальный интерпретатор
команд, uucico, указанный в
файле "/etc/passwd", а
процесс-клиент передает на
удаленную машину
последовательность команд, тем
самым заставляя ее исполнять
процессы от имени локальной
машины.
Сетевое взаимодействие в системе
UNIX представляет серьезную
проблему, поскольку сообщения
должны включать в себя как
информационную, так и
управляющую части. В управляющей
части сообщения может
располагаться адрес назначения
сообщения. В свою очередь,
структура адресных данных
зависит от типа сети и
используемого протокола.
Следовательно, процессам нужно
знать тип сети, а это идет
вразрез с тем принципом, по
которому пользователи не должны
обращать внимания на тип файла,
ибо все устройства для
пользователей выглядят как
файлы. Традиционные методы
реализации сетевого
взаимодействия при установке
управляющих параметров в сильной
степени полагаются на помощь
системной функции ioctl, однако
в разных типах сетей этот момент
воплощается по-разному. Отсюда
возникает нежелательный побочный
эффект, связанный с тем, что
программы, разработанные для
одной сети, в других сетях могут
не заработать.
Чтобы разработать сетевые
интерфейсы для системы UNIX,
были предприняты значительные
усилия. Реализация потоков в
последних редакциях версии V
располагает элегантным
механизмом поддержки сетевого
взаимодействия, обеспечивающим
гибкое сочетание отдельных
модулей протоколов и их
согласованное использование на
уровне задач. Следующий раздел
посвящен краткому описанию
метода решения данных проблем в
системе BSD, основанного на
использовании гнезд.
|
|