13.2. Клиенты и серверы локальных сетей
В основе широкого распространения локальных сетей компьютеров лежит известная идея разделения ресурсов. Высокая пропускная способность локальных сетей обеспечивает эффективный доступ из одного узла локальной сети к ресурсам, находящимся в других узлах.
Развитие этой идеи приводит к функциональному выделению компонентов сети: разумно иметь не только доступ к ресурсам удаленного компьютера, но также получать от этого компьютера некоторый сервис, который специфичен для ресурсов данного рода и программные средства для обеспечения которого (сервиса) нецелесообразно дублировать в нескольких узлах. Так мы приходим к различению рабочих станций и серверов локальной сети.
Рабочая станцияпредназначена для непосредственной работы пользователя или категории пользователей и обладает ресурсами, соответствующими локальным потребностям данного пользователя.
Серверлокальной сети должен обладать ресурсами, соответствующими его функциональному назначению и потребностям сети.
Примерами серверов могут служить:
сервер телекоммуникаций, обеспечивающий услуги по связи данной локальной сети с внешним миром;
вычислительный сервер, дающий возможность производить вычисления, которые невозможно выполнить на рабочих станциях;
дисковый сервер, обладающий расширенными ресурсами внешней памяти и предоставляющий их в использование рабочим станциями и, возможно, другим серверам;
файловый сервер, поддерживающий общее хранилище файлов для всех рабочих станций;
сервер баз данных – фактически обычная СУБД, принимающая запросы по локальной сети и возвращающая результаты.
Сервер локальной сети предоставляет ресурсы (услуги) рабочим станциям и/или другим серверам.
Принято называть клиентом локальной сети компонент, запрашивающий услуги у некоторого сервера, и сервером – компонент локальной сети, оказывающий услуги некоторым клиентам.
13.3. Системная архитектура «клиент-сервер»
Понятно, что в общем случае, чтобы прикладная программа, выполняющаяся на рабочей станции, могла запросить услугу у некоторого сервера, требуется как минимум некоторый интерфейсный программный слой, поддерживающий такого рода взаимодействие (было бы, по меньшей мере, неестественно требовать, чтобы прикладная программа напрямую пользовалась примитивами транспортного уровня локальной сети). Из этого, собственно, и вытекают основные принципы системной архитектуры «клиент-сервер».
Система разбивается на две части, которые могут выполняться в разных узлах сети, — клиентскую и серверную части. Прикладная программа или конечный пользователь взаимодействуют с клиентской частью системы, которая в простейшем случае обеспечивает просто надсетевой интерфейс. Клиентская часть системы при потребности обращается по сети к серверной части.
Интерфейс серверной части определён и фиксирован. Поэтому возможно создание новых клиентских частей существующей системы (пример интероперабельности на системном уровне).
Основной проблемой систем, основанных на архитектуре «клиент-сервер», является то, что в соответствии с концепцией открытых систем от них требуется мобильность в как можно более широком классе аппаратно-программных решений открытых систем. Даже если ограничиться UNIX-ориентированными локальными сетями, в разных сетях применяется разная аппаратура и протоколы связи. Попытки создания систем, поддерживающих все возможные протоколы, приводит к их перегрузке сетевыми деталями в ущерб функциональности.
Еще более сложный аспект этой проблемы связан с возможностью использования разных представлений данных в разных узлах неоднородной локальной сети. В разных компьютерах может существовать различная адресация, представление чисел, кодировка символов и т.д. Это особенно существенно для серверов высокого уровня: телекоммуникационных, вычислительных, баз данных.
Общим решением проблемы мобильности систем, основанных на архитектуре «клиент-сервер» является опора на программные пакеты, реализующие протоколы удаленного вызова процедур (RPC — Remote Procedure Call). При использовании таких средств обращение к сервису в удаленном узле выглядит как обычный вызов процедуры. Средства RPC, в которых, естественно, содержится вся информация о специфике аппаратуры локальной сети и сетевых протоколов, переводят вызов в последовательность сетевых взаимодействий. Тем самым, специфика сетевой среды и протоколов скрыта от прикладного программиста.
При вызове удаленной процедуры программы RPC производят преобразование форматов данных клиента в промежуточные машинно-независимые форматы и затем преобразование в форматы данных сервера. При передаче ответных параметров производятся аналогичные преобразования.
Если система реализована на основе стандартного пакета RPC, она может быть легко перенесена в любую открытую среду.
11. Компьютерные сети. Сервер, клиент и редиректор. Функциональные роли компьютеров в сети.
Компьютерная сеть (вычислительная сеть, сеть передачи данных) — система связи компьютеров или вычислительного оборудования (серверы, маршрутизаторы и другое оборудование). Для передачи данных могут быть использованы различные физические явления как правило — различные виды электрических сигналов, световых сигналов или электромагнитного излучения.
Редиректор (англ. redirector, перенаправляющий) — модуль в прокси-серверах, отвечающий за фильтрацию и обработку адресов (URL) запросов от клиентов к серверам. Может быть как встроенным в прокси-сервер, так и запускающийся отдельным приложением (скриптом).
Задачи, решаемые с помощью редиректора:
- Закрытие доступа к определённым адресам по сложным критериям.
- Замена одного содержимого на другое (например, баннеров на пустые изображения)
- Выдача сообщения о точной причине запрета доступа к странице
- Выдача предупреждения о возможной фишинг-атаке (при наличии фишинг-фильтра)
- Анализ статистики обращения к определённым ресурсам (как разрешённым, так и запрещённым)
12. Модель процессов в многозадачной среде. События, приводящие к созданию процессов и завершению процессов.
Модель процессов в многозадачной среде. В модели сообщений поток представлен как отдельные мессаги, тут важны показатели границ сообщений. Важное понятие, относящееся к взаимодействию процессов — нить исполнения (thread). Нити процесса разделяют его программный код, глобальные переменные и системные ресурсы, но каждая нить имеет собственный программный счетчик, свое содержимое регистров и свой стек. То есть процесс — это много нитей (минимум одна). События, приводящие к созданию процессов и завершению процессов. Для создания нового процесса существующий процесс клонирует самого себя с помощью системного вызова fork. Результатом является получение копии исходного процесса, имеющей лишь некоторые отличия. В частности, новому процессу присваивается новый идентификатор, и учет ресурсов ведется для него независимо от предка. Системный вызов fork обладает уникальным свойством: он возвращает сразу два значения. В порожденном процессе эта функция возвращает 0, а в родительском — идентификатор потомка. Поскольку в остальном процессы идентичны, они должны проверять это значение, чтобы определить, в какой роли следует выступать дальше. После выполнения системного вызова fork новый процесс обычно запускает новую программу с помощью одного из системных вызовов семейства exec. Все вызовы семейства exec производят приблизительно одинаковые действия: они замещают сегмент кода процесса и устанавливают сегменты данных и стека в исходное состояние. Формы вызовов exec отличаются только способами указания аргументов командной строки и переменных среды, передаваемых новой программе. Когда система загружается, ядро самостоятельно создает несколько процессов. Наиболее важный из них — процесс init, идентификатор которого всегда равен 1. Программа init отвечает за вызов командного интерпретатора для выполнения стартовых сценариев, если они используются в системе. Все процессы, кроме тех, что создаются ядром, являются потомками процесса init. Программа init играет и другую важную роль в управлении процессами. Когда процесс завершается, он вызывает функцию _exit(), чтобы уведомить ядро о своей готовности прекратить работу. В качестве параметра функции _exit() передается код завершения — целое число, указывающее на причину останова процесса. По соглашению нулевой код завершения означает, что процесс окончился успешно. В UNIX требуется, чтобы, прежде чем процесс окончательно исчезнет, его удаление было подтверждено родительским процессом с помощью системного вызова wait. Данная функция возвращает код завершения потомка и, если требуется, статистику использования ресурсов. По этой причине ядро должно хранить код завершения, пока родительский процесс не запросит его. По окончании дочернего процесса его адресное пространство освобождается, время центрального процессора ему не выделяется, однако в таблице процессов ядра сохраняется запись о нем. Процесс в этом состоянии называется зомби. Описанный механизм работает нормально, если родительский процесс завершается позже порожденных им процессов и добросовестно выполняет системные вызовы wait для того, чтобы все процессы-зомби были уничтожены. Если же родительский процесс завершается первым, то ядро понимает, что вызова wait не последует, и переназначает все процессы-зомби программе init. Она обязана принять «осиротевшие» процессы и ликвидировать их, осуществив для каждого из этих процессов вызов wait.