ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 11.01.2024
Просмотров: 750
Скачиваний: 1
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
5.3.Технология inetd
Понятие UNIX-подобных систем.
UNIX (читается ю́никс) — семейство переносимых, многоза- дачных и многопользовательских операционных систем.
Первая система UNIX была разработана в 1969 году в подраз- делении Bell Labs компании AT&T. С тех пор было создано большое количество различных UNIX-систем. Юридически лишь некоторые из них имеют полное право называться «UNIX»; остальные же, хотя и используют сходные концепции и технологии, объединяются терми- ном «UNIX-подобные» (англ. UNIX-like). Для краткости в данной статье под UNIX-системами подразумеваются как истинные UNIX, так и UNIX-подобные ОС.
Некоторые отличительные признаки UNIX-систем включают в себя:
Использование простых текстовых файлов для настройки и управления системой;
Широкое применение утилит, запускаемых в командной строке;
Взаимодействие с пользователем посредством виртуально- го устройства — терминала;
Представление физических и виртуальных устройств и не- которых средств межпроцессового взаимодействия как файлов;
273
Использование конвейеров из нескольких программ, каж- дая из которых выполняет одну задачу.
В настоящее время UNIX-системы используются в основном на серверах, а также как встроенные системы для различного оборудо- вания. На рынке ОС для рабочих станций и домашнего применения лидером является Microsoft Windows, UNIX занимает только второе
(Mac OS X), третье (GNU/Linux) и многие последующие места.
UNIX-системы имеют большую историческую важность, по- скольку благодаря им распространились некоторые популярные сего- дня концепции и подходы в области ОС и программного обеспечения.
Также, в ходе разработки Unix-систем был создан язык Си.
Среди примеров известных UNIX-подобных операционных си- стем: BSD, Solaris, Linux, Android, MeeGo, NeXTSTEP, Mac OS X,
Apple iOS.
UNIX-подобная операционная система (иногда сокр. *nix) — система, которая образовалась под влиянием UNIX. Термин включает свободные/открытые операционные системы, образованные от UNIX компании Bell Labs или эмулирующие его возможности, коммерче- ские и запатентованные разработки, а также версии, основанные на исходном коде UNIX. Нет стандарта, определяющего термин, и допу- стимы различные точки зрения о том, считать ли определённый про- дукт UNIX-подобным или нет.
Деннис Ритчи, один из создателей UNIX, выразил своё мнение, что UNIX-подобные системы, такие как Linux, являются де-факто
UNIX-системами. Эрик Рэймонд предложил разделить UNIX- подобные системы на 3 типа:
Генетический UNIX
Системы, исторически связанные с кодовой базой AT&T. Боль- шинство, но не все коммерческие дистрибутивы UNIX-систем попа- дают под эту категорию. Так же, как и BSD-системы, которые явля- ются результатами работы университета Беркли в поздних 1970-х и ранних 1980-х. В некоторых из этих систем отсутствует код AT&T, но до сих пор прослеживается происхождение от разработки AT&T.
UNIX по товарному знаку, или бренду
274
Эти системы, в основном коммерческого характера, были опре- делены The Open Group как соответствующие Единой спецификации
UNIX, и им разрешено носить имя UNIX. Большинство этих систем
— коммерческие производные кодовой базы UNIX System V в той или иной форме (например, Amiga UNIX), хотя некоторые (например, z/OS компании IBM) заслужили торговую марку через слой совме- стимости с POSIX, не являясь по сути UNIX. Многие старые UNIX- системы не подходят под это определение.
UNIX по функциональности
В целом, любая система, поведение которой примерно соответ- ствует спецификации UNIX. К таким системам можно отнести Linux и Minix, которые ведут себя подобно UNIX-системе, но не имеют ге- нетических связей с кодовой базой AT&T. Большинство свобод- ных/открытых реализаций UNIX, являясь генетическим UNIX или нет, подпадают под ограниченное определение этой категории в связи с дороговизной сертификации The Open Group, которая стоит не- сколько тысяч долларов.
Понятие фоновой службы
Фо́новая зада́ча (фоновой процесс) — это процесс, который ра- ботает в фоне, на заднем плане. Имеется в виду, что оболочка опера- ционной системы, которая выполняет фоновый процесс, не ждёт за- вершения или окончания процесса, как это происходит с обычными программами. Оболочка может запустить ещё много процессов сразу после запуска одного фонового так, что они будут выполняться одно- временно. На самом деле процессы будут выполняться поочерёдно то один, то другой, но скорость переключения между процессами слиш- ком быстра для человеческого восприятия, поэтому нам кажется, что они выполняются одновременно. Типичными фоновыми процессами, выполняющимися в системе, являются обработчики событий и си- стемные службы. В рамках выделенной оперативной памяти может выполняться любое желаемое количество процессов.
275
Как правило (например, в UNIX), деление процессов на фоно- вые и процессы переднего плана отражает только отношение процес- са к оболочке ОС и к драйверу терминала, а не особенности его ис- полнения внутри операционной среды и диспетчера.
Так, например, фоновый процесс, как правило, не имеет права принимать ввод пользователя, при попытке сделать это он останавли- вается и оболочка ОС выводит об этом сообщение пользователю.
Оболочка ОС UNIX подразделяет запущенные ей группы про- цессов на «переднего плана», «фоновые» и «приостановленные», и поддерживает перевод групп процессов из одного из выше названных классов в другой. Для этого используется & (амперсенд) в конце ко- мандной строки, клавиатурная комбинация Ctrl-Z (приостанавливает текущую группу процессов переднего плана), и команды jobs, fg и bg.
Отличие фоновых процессов от «демонов» (служб) ОС UNIX в том, что «демон» полностью утрачивает ассоциацию с пользователь- ским терминалом и оболочкой ОС, зачастую продолжая существовать и после выхода породившего его процесса оболочки. Фоновый же процесс по-прежнему сохраняет логическую ассоциацию с термина- лом и оболочкой.
Демон inetd управляет другими демонами. Он запускает демо- ны-клиенты, когда для них есть работа, а после выполнения задачи позволяет им тихо завершиться.
Демон inetd работает только с теми демонами, которые оказы- вают услуги по сети. Для того чтобы установить, не пытается ли кто- нибудь получить доступ к одному из его клиентов, демон inetd кон- тролирует те редко активизируемые сетевые порты, которые обслу- живаются обычно бездельничающими демонами. Когда устанавлива- ется соединение, демон inetd запускает соответствующий демон и со- единяет каналы его стандартного ввода-вывода с сетевым портом.
Это правило следует учитывать при написании демонов, совмести- мых с inetd.
Работа некоторых демонов (например, тех, что связаны с NIS и
NFS) основана на протоколе RPC, который был разработан и реализо- ван компанией Sun в качестве механизма совместного использования
276 информации в распределенной сетевой среде. Назначениями портов для RPC-демонов управляет демон portmap (иногда называется
rpcbind).
Многие демоны могут использоваться либо традиционным спо- собом (т.е. они запускаются однократно и работают до выключения системы), либо под контролем демона inetd.
Одной из распространённых задач администрирования является запуск каких-то задач в определённое время с заданной периодично- стью. В UNIX этой цели служит планировщик заданий cron.
За выполнением задач по расписанию следит демон, который обычно называется crond. Само расписание описывается в специаль- ных конфигурационных файлах — есть расписание общесистемных задач (/etc/crontab), а также персональное расписание задач (файл crontab) для каждого пользователя. Всем ли пользователям дозволяет- ся пользоваться выполнением задач по расписанию — определяет ад- министратор системы; зачастую для этого пользователей включают в специальную группу (например, cron).
Стандартные потоки ввода и вывода в UNIX/Linux наряду с файлами являются одним из наиболее распространённых средств для обмена информацией процессов с внешним миром, а перенаправле- ния >, >> и |, одной из самых популярных конструкций командного интерпретатора.
Процесс взаимодействия с пользователем выполняется в терми- нах записи и чтения в файл. То есть вывод на экран представляется как запись в файл, а ввод — как чтение файла. Файл, из которого осуществляется чтение, называется стандартным потоком ввода, а в который осуществляется запись — стандартным потоком вывода.
Стандартные потоки — воображаемые файлы, позволяющие осуществлять взаимодействие с пользователем как чтение и запись в файл. Кроме потоков ввода и вывода, существует еще и стандартный поток ошибок, на который выводятся все сообщения об ошибках и те информативные сообщения о ходе работы программы, которые не могут быть выведены в стандартный поток вывода.
277
Вывод данных на экран и чтение их с клавиатуры происходит потому, что по умолчанию стандартные потоки ассоциированы с тер- миналом пользователя. Это не является обязательным — потоки можно подключать к чему угодно — к файлам, программам и даже устройствам. В командном интерпретаторе bash такая операция назы- вается перенаправлением.
Стандартные потоки можно перенаправлять не только в файлы, но и на вход других программ. Если поток вывода одной программы соединить с потоком ввода другой программы, получится конструк- ция, называемая каналом, конвейером или пайпом (от англ. pipe, тру- ба).
В bash канал выглядит как последовательность команд, отде- ленных друг от друга символом |: команда1 | команда2 | команда3 ...
Стандартный поток вывода команды1 подключается к стан- дартному потоку ввода команды2, стандартный поток вывода коман- ды2 в свою очередь подключается к потоку ввода команды3 и т.д.
В UNIX/Linux существует целый класс команд, предназначен- ных для преобразования потоков данных в каналах. Такие программы известны как фильтры. Программа-фильтр читает данные, поступаю- щие со стандартного потока ввода (на вход), преобразовывает их тре- буемым образом и выводит на стандартный поток вывода (на выход).
Существует множество хорошо известных фильтров, призванных ре- шать определенные задачи, и являющихся незаменимым инструмен- том в руках пользователя ОС.
Каналы в ОС Linux являются одной из наиболее часто применя- емых конструкций, а фильтры — наиболее часто применяемых про- грамм. Большинство повседневных задач в Linux легко решаются при помощи конструкций построенных на основе нескольких фильтров.
Программы, образующие канал, выполняются параллельно как независимые процессы.
В UNIX/Linux существует целый класс команд, которые прини- мают данные со стандартного потока ввода, каким-то образом обра-
278 батывают их, и выдают результат на стандартный поток вывода. Та- кие программы называются программами-фильтрами.
Как правило, все эти программы работают как фильтры, если у них нет аргументов (опции могут быть), но как только им в качестве аргумента передаётся файл, они считывают данные из этого файла, а не со стандартного потока ввода (существуют и исключения, напри- мер, программа tr, которая обрабатывает данные поступающие ис- ключительно через стандартный поток ввода).
5.4. Технология RPC
Удалённый вызов процедур (или Вызов удалённых процедур)
(от англ. Remote Procedure Call (RPC)) — класс технологий, позволя- ющих компьютерным программам вызывать функции или процедуры в другом адресном пространстве (как правило, на удалённых компью- терах). Обычно, реализация RPC технологии включает в себя два компонента: сетевой протокол для обмена в режиме клиент-сервер и язык сериализации объектов (или структур, для необъектных RPC).
Различные реализации RPC имеют очень отличающуюся друг от дру- га архитектуру и разнятся в своих возможностях: одни реализуют ар- хитектуру SOA, другие CORBA или DCOM. На транспортном уровне
RPC используют в основном протоколы TCP и UDP, однако, некото- рые построены на основе HTTP (что нарушает архитектуру ISO/OSI, так как HTTP изначально не транспортный протокол).
Реализация технологии. Идея вызова удаленных процедур.
Идея вызова удалённых процедур (Remote Procedure Call —
RPC) состоит в расширении хорошо известного и понятного меха- низма передачи управления и данных внутри программы, выполняю- щейся на одной машине, на передачу управления и данных через сеть.
Средства удалённого вызова процедур предназначены для облегчения организации распределённых вычислений и создания распределенных клиент-серверных информационных систем. Наибольшая эффектив-
279 ность использования RPC достигается в тех приложениях, в которых существует интерактивная связь между удалёнными компонентами с небольшим временем ответов и относительно малым количеством пе- редаваемых данных. Такие приложения называются RPC- ориентированными.
Характерными чертами вызова удалённых процедур являются:
Асимметричность, то есть одна из взаимодействующих сторон является инициатором;
Синхронность, то есть выполнение вызывающей процеду- ры приостанавливается с момента выдачи запроса и возобновляется только после возврата из вызываемой процедуры.
Реализация удалённых вызовов существенно сложнее реализа- ции вызовов локальных процедур. Можно обозначить следующие проблемы и задачи, которые необходимо решить при реализации
RPC:
Так как вызывающая и вызываемая процедуры выполняются на разных машинах, то они имеют разные адресные пространства, и это создает проблемы при передаче параметров и результатов, особенно если машины находятся под управлением различных операционных систем или имеют различную архитектуру (например, используется прямой или обратный порядок байтов). Так как RPC не может рассчи- тывать на разделяемую память, то это означает, что параметры RPC не должны содержать указателей на ячейки нестековой памяти и что значения параметров должны копироваться с одного компьютера на другой. Для копирования параметров процедуры и результата выпол- нения через сеть выполняется их сериализация.
В отличие от локального вызова удалённый вызов процедур обязательно использует транспортный уровень сетевой архитектуры
(например TCP), однако это остается скрытым от разработчика.
Выполнение вызывающей программы и вызываемой локальной процедуры в одной машине реализуется в рамках единого процесса.
Но в реализации RPC участвуют как минимум два процесса — по од- ному в каждой машине. В случае, если один из них аварийно завер- шится, могут возникнуть следующие ситуации: при аварии вызыва-
280 ющей процедуры удалённо вызванные процедуры станут «осиротев- шими», а при аварийном завершении удалённых процедур станут
«обездоленными родителями» вызывающие процедуры, которые бу- дут безрезультатно ожидать ответа от удалённых процедур.
Существует ряд проблем, связанных с неоднородностью языков программирования и операционных сред: структуры данных и струк- туры вызова процедур, поддерживаемые в каком-либо одном языке программирования, не поддерживаются точно так же во всех других языках. Таким образом имеется проблема совместимости, до сих пор не решённая ни с помощью введения одного общепринятого стандар- та, ни с помощью реализации нескольких конкурирующих стандартов на всех архитектурах и во всех языках.
Существуют множество технологий, обеспечивающих RPC:
Sun RPC (бинарный протокол на базе TCP и UDP и XDR)
RFC-1831 второе название ONC RPC RFC-1833
.NET Remoting (бинарный протокол на базе TCP, UDP,
HTTP)
SOAP — Simple Object Access Protocol (текстовый прото- кол на базе HTTP) см. спецификацию: RFC-4227
XML RPC (текстовый протокол на базе HTTP) см. специ- фикацию: RFC-3529
Java RMI — Java Remote Method Invocation — см. специ- фикацию: http://java.sun.com/j2se/1.5.0/docs/guide/rmi/index.html
JSON-RPC— JavaScript Object Notation Remote Procedure
Calls (текстовый протокол на базе HTTP) см. спецификацию: RFC-
4627
DCE/RPC — Distributed Computing Environment / Remote
Procedure Calls (бинарный протокол на базе различных транспортных протоколов, в том числе TCP/IP и Named Pipes из протокола
SMB/CIFS)
DCOM — Distributed Component Object Model известный как MSRPC Microsoft Remote Procedure Call или «Network OLE» (объ- ектно-ориентированное расширение DCE RPC, позволяющее переда-
281 вать ссылки на объекты и вызывать методы объектов через таковые ссылки)
Routix.RPC
ZeroC ICE.
Взаимодействие программных компонентов при выполнении удаленного вызова процедуры иллюстрируется рисунком 5.1.
Рис. 5.1. Порядок удаленного вызова процедуры.
После того, как клиентский стаб был вызван программой- клиентом, его первой задачей является заполнение буфера отправляе- мым сообщением. В некоторых системах клиентский стаб имеет единственный буфер фиксированной длины, заполняемый каждый раз с самого начала при поступлении каждого нового запроса. В других системах буфер сообщения представляет собой пул буферов для от- дельных полей сообщения, причем некоторые из этих буферов уже заполнены. Этот метод особенно подходит для тех случаев, когда па- кет имеет формат, состоящий из большого числа полей, но значения многих из этих полей не меняются от вызова к вызову.
Затем параметры должны быть преобразованы в соответствую- щий формат и вставлены в буфер сообщения. К этому моменту со-
Понятие UNIX-подобных систем.
UNIX (читается ю́никс) — семейство переносимых, многоза- дачных и многопользовательских операционных систем.
Первая система UNIX была разработана в 1969 году в подраз- делении Bell Labs компании AT&T. С тех пор было создано большое количество различных UNIX-систем. Юридически лишь некоторые из них имеют полное право называться «UNIX»; остальные же, хотя и используют сходные концепции и технологии, объединяются терми- ном «UNIX-подобные» (англ. UNIX-like). Для краткости в данной статье под UNIX-системами подразумеваются как истинные UNIX, так и UNIX-подобные ОС.
Некоторые отличительные признаки UNIX-систем включают в себя:
Использование простых текстовых файлов для настройки и управления системой;
Широкое применение утилит, запускаемых в командной строке;
Взаимодействие с пользователем посредством виртуально- го устройства — терминала;
Представление физических и виртуальных устройств и не- которых средств межпроцессового взаимодействия как файлов;
273
Использование конвейеров из нескольких программ, каж- дая из которых выполняет одну задачу.
В настоящее время UNIX-системы используются в основном на серверах, а также как встроенные системы для различного оборудо- вания. На рынке ОС для рабочих станций и домашнего применения лидером является Microsoft Windows, UNIX занимает только второе
(Mac OS X), третье (GNU/Linux) и многие последующие места.
UNIX-системы имеют большую историческую важность, по- скольку благодаря им распространились некоторые популярные сего- дня концепции и подходы в области ОС и программного обеспечения.
Также, в ходе разработки Unix-систем был создан язык Си.
Среди примеров известных UNIX-подобных операционных си- стем: BSD, Solaris, Linux, Android, MeeGo, NeXTSTEP, Mac OS X,
Apple iOS.
UNIX-подобная операционная система (иногда сокр. *nix) — система, которая образовалась под влиянием UNIX. Термин включает свободные/открытые операционные системы, образованные от UNIX компании Bell Labs или эмулирующие его возможности, коммерче- ские и запатентованные разработки, а также версии, основанные на исходном коде UNIX. Нет стандарта, определяющего термин, и допу- стимы различные точки зрения о том, считать ли определённый про- дукт UNIX-подобным или нет.
Деннис Ритчи, один из создателей UNIX, выразил своё мнение, что UNIX-подобные системы, такие как Linux, являются де-факто
UNIX-системами. Эрик Рэймонд предложил разделить UNIX- подобные системы на 3 типа:
Генетический UNIX
Системы, исторически связанные с кодовой базой AT&T. Боль- шинство, но не все коммерческие дистрибутивы UNIX-систем попа- дают под эту категорию. Так же, как и BSD-системы, которые явля- ются результатами работы университета Беркли в поздних 1970-х и ранних 1980-х. В некоторых из этих систем отсутствует код AT&T, но до сих пор прослеживается происхождение от разработки AT&T.
UNIX по товарному знаку, или бренду
274
Эти системы, в основном коммерческого характера, были опре- делены The Open Group как соответствующие Единой спецификации
UNIX, и им разрешено носить имя UNIX. Большинство этих систем
— коммерческие производные кодовой базы UNIX System V в той или иной форме (например, Amiga UNIX), хотя некоторые (например, z/OS компании IBM) заслужили торговую марку через слой совме- стимости с POSIX, не являясь по сути UNIX. Многие старые UNIX- системы не подходят под это определение.
UNIX по функциональности
В целом, любая система, поведение которой примерно соответ- ствует спецификации UNIX. К таким системам можно отнести Linux и Minix, которые ведут себя подобно UNIX-системе, но не имеют ге- нетических связей с кодовой базой AT&T. Большинство свобод- ных/открытых реализаций UNIX, являясь генетическим UNIX или нет, подпадают под ограниченное определение этой категории в связи с дороговизной сертификации The Open Group, которая стоит не- сколько тысяч долларов.
Понятие фоновой службы
Фо́новая зада́ча (фоновой процесс) — это процесс, который ра- ботает в фоне, на заднем плане. Имеется в виду, что оболочка опера- ционной системы, которая выполняет фоновый процесс, не ждёт за- вершения или окончания процесса, как это происходит с обычными программами. Оболочка может запустить ещё много процессов сразу после запуска одного фонового так, что они будут выполняться одно- временно. На самом деле процессы будут выполняться поочерёдно то один, то другой, но скорость переключения между процессами слиш- ком быстра для человеческого восприятия, поэтому нам кажется, что они выполняются одновременно. Типичными фоновыми процессами, выполняющимися в системе, являются обработчики событий и си- стемные службы. В рамках выделенной оперативной памяти может выполняться любое желаемое количество процессов.
275
Как правило (например, в UNIX), деление процессов на фоно- вые и процессы переднего плана отражает только отношение процес- са к оболочке ОС и к драйверу терминала, а не особенности его ис- полнения внутри операционной среды и диспетчера.
Так, например, фоновый процесс, как правило, не имеет права принимать ввод пользователя, при попытке сделать это он останавли- вается и оболочка ОС выводит об этом сообщение пользователю.
Оболочка ОС UNIX подразделяет запущенные ей группы про- цессов на «переднего плана», «фоновые» и «приостановленные», и поддерживает перевод групп процессов из одного из выше названных классов в другой. Для этого используется & (амперсенд) в конце ко- мандной строки, клавиатурная комбинация Ctrl-Z (приостанавливает текущую группу процессов переднего плана), и команды jobs, fg и bg.
Отличие фоновых процессов от «демонов» (служб) ОС UNIX в том, что «демон» полностью утрачивает ассоциацию с пользователь- ским терминалом и оболочкой ОС, зачастую продолжая существовать и после выхода породившего его процесса оболочки. Фоновый же процесс по-прежнему сохраняет логическую ассоциацию с термина- лом и оболочкой.
Демон inetd управляет другими демонами. Он запускает демо- ны-клиенты, когда для них есть работа, а после выполнения задачи позволяет им тихо завершиться.
Демон inetd работает только с теми демонами, которые оказы- вают услуги по сети. Для того чтобы установить, не пытается ли кто- нибудь получить доступ к одному из его клиентов, демон inetd кон- тролирует те редко активизируемые сетевые порты, которые обслу- живаются обычно бездельничающими демонами. Когда устанавлива- ется соединение, демон inetd запускает соответствующий демон и со- единяет каналы его стандартного ввода-вывода с сетевым портом.
Это правило следует учитывать при написании демонов, совмести- мых с inetd.
Работа некоторых демонов (например, тех, что связаны с NIS и
NFS) основана на протоколе RPC, который был разработан и реализо- ван компанией Sun в качестве механизма совместного использования
276 информации в распределенной сетевой среде. Назначениями портов для RPC-демонов управляет демон portmap (иногда называется
rpcbind).
Многие демоны могут использоваться либо традиционным спо- собом (т.е. они запускаются однократно и работают до выключения системы), либо под контролем демона inetd.
Одной из распространённых задач администрирования является запуск каких-то задач в определённое время с заданной периодично- стью. В UNIX этой цели служит планировщик заданий cron.
За выполнением задач по расписанию следит демон, который обычно называется crond. Само расписание описывается в специаль- ных конфигурационных файлах — есть расписание общесистемных задач (/etc/crontab), а также персональное расписание задач (файл crontab) для каждого пользователя. Всем ли пользователям дозволяет- ся пользоваться выполнением задач по расписанию — определяет ад- министратор системы; зачастую для этого пользователей включают в специальную группу (например, cron).
Стандартные потоки ввода и вывода в UNIX/Linux наряду с файлами являются одним из наиболее распространённых средств для обмена информацией процессов с внешним миром, а перенаправле- ния >, >> и |, одной из самых популярных конструкций командного интерпретатора.
Процесс взаимодействия с пользователем выполняется в терми- нах записи и чтения в файл. То есть вывод на экран представляется как запись в файл, а ввод — как чтение файла. Файл, из которого осуществляется чтение, называется стандартным потоком ввода, а в который осуществляется запись — стандартным потоком вывода.
Стандартные потоки — воображаемые файлы, позволяющие осуществлять взаимодействие с пользователем как чтение и запись в файл. Кроме потоков ввода и вывода, существует еще и стандартный поток ошибок, на который выводятся все сообщения об ошибках и те информативные сообщения о ходе работы программы, которые не могут быть выведены в стандартный поток вывода.
277
Вывод данных на экран и чтение их с клавиатуры происходит потому, что по умолчанию стандартные потоки ассоциированы с тер- миналом пользователя. Это не является обязательным — потоки можно подключать к чему угодно — к файлам, программам и даже устройствам. В командном интерпретаторе bash такая операция назы- вается перенаправлением.
Стандартные потоки можно перенаправлять не только в файлы, но и на вход других программ. Если поток вывода одной программы соединить с потоком ввода другой программы, получится конструк- ция, называемая каналом, конвейером или пайпом (от англ. pipe, тру- ба).
В bash канал выглядит как последовательность команд, отде- ленных друг от друга символом |: команда1 | команда2 | команда3 ...
Стандартный поток вывода команды1 подключается к стан- дартному потоку ввода команды2, стандартный поток вывода коман- ды2 в свою очередь подключается к потоку ввода команды3 и т.д.
В UNIX/Linux существует целый класс команд, предназначен- ных для преобразования потоков данных в каналах. Такие программы известны как фильтры. Программа-фильтр читает данные, поступаю- щие со стандартного потока ввода (на вход), преобразовывает их тре- буемым образом и выводит на стандартный поток вывода (на выход).
Существует множество хорошо известных фильтров, призванных ре- шать определенные задачи, и являющихся незаменимым инструмен- том в руках пользователя ОС.
Каналы в ОС Linux являются одной из наиболее часто применя- емых конструкций, а фильтры — наиболее часто применяемых про- грамм. Большинство повседневных задач в Linux легко решаются при помощи конструкций построенных на основе нескольких фильтров.
Программы, образующие канал, выполняются параллельно как независимые процессы.
В UNIX/Linux существует целый класс команд, которые прини- мают данные со стандартного потока ввода, каким-то образом обра-
278 батывают их, и выдают результат на стандартный поток вывода. Та- кие программы называются программами-фильтрами.
Как правило, все эти программы работают как фильтры, если у них нет аргументов (опции могут быть), но как только им в качестве аргумента передаётся файл, они считывают данные из этого файла, а не со стандартного потока ввода (существуют и исключения, напри- мер, программа tr, которая обрабатывает данные поступающие ис- ключительно через стандартный поток ввода).
5.4. Технология RPC
Удалённый вызов процедур (или Вызов удалённых процедур)
(от англ. Remote Procedure Call (RPC)) — класс технологий, позволя- ющих компьютерным программам вызывать функции или процедуры в другом адресном пространстве (как правило, на удалённых компью- терах). Обычно, реализация RPC технологии включает в себя два компонента: сетевой протокол для обмена в режиме клиент-сервер и язык сериализации объектов (или структур, для необъектных RPC).
Различные реализации RPC имеют очень отличающуюся друг от дру- га архитектуру и разнятся в своих возможностях: одни реализуют ар- хитектуру SOA, другие CORBA или DCOM. На транспортном уровне
RPC используют в основном протоколы TCP и UDP, однако, некото- рые построены на основе HTTP (что нарушает архитектуру ISO/OSI, так как HTTP изначально не транспортный протокол).
Реализация технологии. Идея вызова удаленных процедур.
Идея вызова удалённых процедур (Remote Procedure Call —
RPC) состоит в расширении хорошо известного и понятного меха- низма передачи управления и данных внутри программы, выполняю- щейся на одной машине, на передачу управления и данных через сеть.
Средства удалённого вызова процедур предназначены для облегчения организации распределённых вычислений и создания распределенных клиент-серверных информационных систем. Наибольшая эффектив-
279 ность использования RPC достигается в тех приложениях, в которых существует интерактивная связь между удалёнными компонентами с небольшим временем ответов и относительно малым количеством пе- редаваемых данных. Такие приложения называются RPC- ориентированными.
Характерными чертами вызова удалённых процедур являются:
Асимметричность, то есть одна из взаимодействующих сторон является инициатором;
Синхронность, то есть выполнение вызывающей процеду- ры приостанавливается с момента выдачи запроса и возобновляется только после возврата из вызываемой процедуры.
Реализация удалённых вызовов существенно сложнее реализа- ции вызовов локальных процедур. Можно обозначить следующие проблемы и задачи, которые необходимо решить при реализации
RPC:
Так как вызывающая и вызываемая процедуры выполняются на разных машинах, то они имеют разные адресные пространства, и это создает проблемы при передаче параметров и результатов, особенно если машины находятся под управлением различных операционных систем или имеют различную архитектуру (например, используется прямой или обратный порядок байтов). Так как RPC не может рассчи- тывать на разделяемую память, то это означает, что параметры RPC не должны содержать указателей на ячейки нестековой памяти и что значения параметров должны копироваться с одного компьютера на другой. Для копирования параметров процедуры и результата выпол- нения через сеть выполняется их сериализация.
В отличие от локального вызова удалённый вызов процедур обязательно использует транспортный уровень сетевой архитектуры
(например TCP), однако это остается скрытым от разработчика.
Выполнение вызывающей программы и вызываемой локальной процедуры в одной машине реализуется в рамках единого процесса.
Но в реализации RPC участвуют как минимум два процесса — по од- ному в каждой машине. В случае, если один из них аварийно завер- шится, могут возникнуть следующие ситуации: при аварии вызыва-
280 ющей процедуры удалённо вызванные процедуры станут «осиротев- шими», а при аварийном завершении удалённых процедур станут
«обездоленными родителями» вызывающие процедуры, которые бу- дут безрезультатно ожидать ответа от удалённых процедур.
Существует ряд проблем, связанных с неоднородностью языков программирования и операционных сред: структуры данных и струк- туры вызова процедур, поддерживаемые в каком-либо одном языке программирования, не поддерживаются точно так же во всех других языках. Таким образом имеется проблема совместимости, до сих пор не решённая ни с помощью введения одного общепринятого стандар- та, ни с помощью реализации нескольких конкурирующих стандартов на всех архитектурах и во всех языках.
Существуют множество технологий, обеспечивающих RPC:
Sun RPC (бинарный протокол на базе TCP и UDP и XDR)
RFC-1831 второе название ONC RPC RFC-1833
.NET Remoting (бинарный протокол на базе TCP, UDP,
HTTP)
SOAP — Simple Object Access Protocol (текстовый прото- кол на базе HTTP) см. спецификацию: RFC-4227
XML RPC (текстовый протокол на базе HTTP) см. специ- фикацию: RFC-3529
Java RMI — Java Remote Method Invocation — см. специ- фикацию: http://java.sun.com/j2se/1.5.0/docs/guide/rmi/index.html
JSON-RPC— JavaScript Object Notation Remote Procedure
Calls (текстовый протокол на базе HTTP) см. спецификацию: RFC-
4627
DCE/RPC — Distributed Computing Environment / Remote
Procedure Calls (бинарный протокол на базе различных транспортных протоколов, в том числе TCP/IP и Named Pipes из протокола
SMB/CIFS)
DCOM — Distributed Component Object Model известный как MSRPC Microsoft Remote Procedure Call или «Network OLE» (объ- ектно-ориентированное расширение DCE RPC, позволяющее переда-
281 вать ссылки на объекты и вызывать методы объектов через таковые ссылки)
Routix.RPC
ZeroC ICE.
Взаимодействие программных компонентов при выполнении удаленного вызова процедуры иллюстрируется рисунком 5.1.
Рис. 5.1. Порядок удаленного вызова процедуры.
После того, как клиентский стаб был вызван программой- клиентом, его первой задачей является заполнение буфера отправляе- мым сообщением. В некоторых системах клиентский стаб имеет единственный буфер фиксированной длины, заполняемый каждый раз с самого начала при поступлении каждого нового запроса. В других системах буфер сообщения представляет собой пул буферов для от- дельных полей сообщения, причем некоторые из этих буферов уже заполнены. Этот метод особенно подходит для тех случаев, когда па- кет имеет формат, состоящий из большого числа полей, но значения многих из этих полей не меняются от вызова к вызову.
Затем параметры должны быть преобразованы в соответствую- щий формат и вставлены в буфер сообщения. К этому моменту со-