Программы, поддерживающие
межмашинную связь, такие, как
электронная почта, программы
дистанционной пересылки файлов и
удаленной регистрации, издавна
используются в качестве
специальных средств организации
подключений и информационного
обмена. Так, например, стандартные
программы, работающие в составе
электронной почты, сохраняют текст
почтовых сообщений пользователя в
отдельном файле (для пользователя
"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,
основанного на использовании
гнезд. Предыдущая
глава || Оглавление
|| Следующая глава
11.3 ВЗАИМОДЕЙСТВИЕ В СЕТИ