Сетевая подсистема (Net)

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

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

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

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

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

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

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

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

Сокеты

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

различаться в зависимости от используемых протоколов и сетевых средств.

Более того, эти способы не всегда применимы для обслуживания взаи­модействия процессов, выполняющихся на одной и той же машине, поскольку в них предполагается существование обслуживающего (серверного) процесса, который при выполнении системных функций ореn() или read() будет приостанавливаться драйвером.

В целях создания более универсальных методов взаимодействия процес­сов на основе использования многоуровневых сетевых протоколов сначала для системы BSD, а потом и для других ОС был разработан механизм, по­лучивший название "sockets". В данном разделе рассматриваются некоторые аспекты применения сокетов (на пользовательском уровне представления).

Структура ядра в ОС Unix имеет три уровня поддержания работы в сети: Сокетов, протоколов И устройств. Смотри рис. 3.14.

Уровень сокетов выполняет функции интерфейса между обращениями к операционной системе (системным функциям) и средствами низких уров­ней, уровень протоколов содержит модули, обеспечивающие взаимодейст­вие процессов, например, стек протоколов ТСР/IP, а уровень устройств со­держит драйверы, управляющие сетевыми устройствами. Допустимые со­четания протоколов и драйверов указываются при построении системы (в секции конфигурации).

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

Реализованный в UNIX вариант механизма сонетов не может реализовать потоковый механизм управления (!), так как процессы взаимодейст­вуют между собой по схеме «клиент-сервер» : сервер ждет сигнала от сокета, находясь на одном конце линии связи, а процессы-клиенты взаимодей­ствуют с сервером через сокеты, которые могут располагаться на другой машине.

Сокеты, обладающие одинаковыми свойствами, например, опирающие­ся на общие соглашения по идентификации и форматы адресов (в протоко­лах), группируются в домены (управляемые одним узлом). В ряде систем (BSD) поддерживаются домены: "UNIX system" - для взаимодействия про­цессов внутри одной машины и "Internet" - для взаимодействия через сеть.

Сонеты бывают двух типов: поток ориентированный (connection oriented) сонет и поток неориентированный (connectionless) сонет, кото­рый еще называют дейтаграммным.

Поток ориентированный сонет обеспечивает надежную доставку данных

с сохранением исходной последовательности.

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

Для каждой допустимой комбинации типа домен - сонет в системе под­держивается по умолчанию некоторый протокол. Так, например, для доме-на "Internet" услуги виртуального канала выполняет протокол транспортной связи TPC, а функции дейтаграммы - пользовательской дейтаграммный протокол UDP