Прежде чем ее интерпретировать нужно вообще сделать так, чтобы данные из транспортного уровня до нашего интерпретатора дошли.

Эту задачу надо решать.

Никто не знает, какой протокол прикладного уровня соержится внутри тцп ип соединения. Если интерпретация это дело приложения, то активация интерпретатор это дело все ещё операционной системы. Причем это может быть сделано множеством разных способов.

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

Вопрос как осуществляется доставка контента до приложения остается открытым.

Здесь надо сделать два отступления, которые знакомы части сидящих здесь по курсу архитектура или каким-либо другим, а именно о том, как вообще организованы системные службы в линукс системе.

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

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

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

C ltvjybxtcrjq ceoyjcnm. ,skb cdzpfys курьезные проблемы, история о проклятии почтового сервера особо ярыми пастырями.

Это действительно отдельная технология организации системных служб, которая осуществляется с помощью мутной процедуры демонизации. Три вещи -- выбраться из процесс группы, оторваться от терминала (причем почему-то двумя форками). В общем, в итоге получаем процесс, который застыл в каком-то состоянии, например в операции listen на сокете. Она не нагружает цпу, за него тцп ип стек занимается мониторингом сокета, на котором он висит. Сам процесс либо небольшой, либо если большой его можно откачать в пейджинг. Так что пока процесс не нуужен, оно особо не мешает.

С тех пор сохранились некоторые методы управления демонами. Стандартные ввод-вывод не годятся, надо заклинания читать. Поэтому обычно общаются, посылая сигнал командой kill. Например hangout перезапускает демон, так пошло со времен терминальных линий.

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

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

  1. Просто берем и в определенном порядке запускаем все нужные нам демоны. Единственное что важно -- пресловутый определенный порядок. И это все. Достаточно доовориться о последовательности запуска. Самая известная и очень старая схема по запуску служб таким образом называется sysvinit. У сисвинита был один недостаток, который надо было преодолеть для пущей прозрачности самой процедуры запуска. Поскольку мы должны строго соблюдать последовательность загрузки служб, то ничего более умного чем присвоить каждой процедуре запуска демон номер придумать нельзя. Долго так и поступали, но возникает вопрос, кто вообще эти номера придумывает? Линукс это сообщество, делается многими людьми. Служб чертова прорва и они все должны договориться кто за кем идет, что в принципе слабо возможно.
  2. Как это дело обходить? Да очень просто, ввести понятие зависимости. LSB, openrc итд. С точки зрения сети те демоны, которые запускаются, запускаются абы когда, но к моменту выхода на штатную работу. У этого способа есть слепое пятно. Процедура запуска демона занимает определенное время. Когда мы запускаем какую-то службу мы вынуждены выносить логику в сценраий на шелле, и он сам будет вызывать стартовые процедуры для проверки, убеждаться в запуске и так далее. Если же мы хотим писать все таки конфигурационный файл, то описание условий при которых у нас происходит запуск и его способ должны отражаться в конфигурационном файле. Здесь появляется еще одно средство запуска.
  3. systemd создание ситуации когда писать сценарии не надо. Добавляются условия запуска, и возможность запуска не демона. В чем главный недостаток такого дела? Всех под одну гребенку не подравняешь, для сложных демонов придется все равно писать шелл скрипт. Но в большинстве случаев можем сказать, что вот сервис, стандартный вывод у него идет в стдерр, и прежде чем его стартовать надо проверить то-то и это. Тем самым сэкономить время при старте. Для нас с вам важно то, что конфигурационный файл описывает условия запуска и возможность активизации сценария без демонизации.

Итого, либо щапускаем все демоны подряд, либо по дереву ависимости, либо зависимости + условия запуска + возможность запуска не демонов.

Запускается демон. Как обеспечить факт доставки трафика до этого демона. Вариант первый -- сам демон написан таким способм, что он занимается установкой сетевого соединения, создает сокет и нчинает его слушать.

Про сокет мы в прошлый раз говорили -- это объект который описывает, как устроен тцп или удп соединение.

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

Что бывает, когда подключение заканчивается? Есть несколько вариантов.

  1. демон выключается. Например, потому что его потом запустит другой демон. Можно вообразить такую извращенную реализацию фтп -- управление принимает один демон, а данные другой.
  2. Что делать после закрытия соединения? Надо начинать опять слушать сокет или вообще не прекращать его слушать. Обычно отдельный процесс или тред вешается на прослушивание соединения, и по необходимости создаем тред обслуживающий соединение, а сами продолжаем слушать дальше.
  3. обслуживание нскольких соединения. Кстати не всегда надо, иногда надо отказывать соединениям, если одно уже активно. Если надо обслуживать несколько соединений, то другая проблема -- а если их 100500? Помимо обслуживания нескольких соединений необходимо подумать, как их ограничивать.

Метадемон

Метадемон это как раз и есть сетевая обвязка интерпретатора который работает со стандартным вводов, выводом выводм ошибок. inetd xinetd.

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

Что мы должны надежно представлять?

  1. Конечно же возможности по определнию сколько каких подключений мы можем позвоить у нас ограничены, потому что лезть в прикладной трафик на уровне инетд мы не можем.
  2. Второй недостаток, хотя его наверно можно преодолеть.. Вот у вас есть интерпретатор прикладного протокола -- такая мощная животина. И увас 10 000 подключений в секунду,, и это нормально. В случае если мы написали собственный демон, и в нем один процесс слушает на этом порту и на каждое подключение запускает интерпретатор из файла да еще и организовывает канал, то получается большая нагрузка на систему.

Что можно себе вообразить еще на эту тему?

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

У системд есть сокет активация. Заранее создаем сокет, кстати, он не обязан быть сетевым. Сокет активация

  1. запуск демонов
  2. запуск интепретаторов
  3. запуск сетевых служб без демонизации

Часто приходится добавлять специальную систему для управления демонами.

Например, надо остановить вебсервер. Надо послать сигналы процессаМ, которые относятся к вебсерверу и только к нему. Как определить эти процессы без доп информации -- непонятно.

Помимо всего прочего сложные демоны должны поддердживать сами процедуру управления собой.

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

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

Вообще говоря возможность отвзяать запуск сетевой службы от ненужных вещей для ней и оставить нужные.

Мы говорили о ситуации когда задача связывания трафика на сетевом уровне и на прикладном уже решена. Мы уже знали к какому порту адо подключиться чтобы получить обслуживание со стороны ос. Для этого есть пачка зарегистрированных портов за определенными службами. Это отражено в файле /etc/services. Но, есть три проблемы, связанные с статической регистрацией определенных служб с определенными портами.

  1. мы можем захотеть не определенный проотокол, а определенной функцией в протоколе или не в проотоколе. Это немножко в стороне от общих сетевых технологий, скорее возникло в распределенных вычислениях. Но сути это не меняет, вмест о обслуживания по какому то проотколу мы хотим получить какую-то функцию, причем мы сами картируем функции удаленных компьютеров, после чего кним обрааемся сообразно картированию. Мы получаем невозможность зарегистрировать все службы один раз и мы не имеем возможность сделать этостатически. У нас проблема с
    1. нерегистрацией
    2. динамическая привзяка к порту. Порт получателя перестал быть жестко привязанным.
    3. у функции могут быть разные версии. проверка наличия функции на компьютере и его версии
    4. анонс
    RPC это технология сводящаяся к вышеописанному.Есть некий протокол, позволяющий картировать, проверять, версионировать и описывать формат передаваемых данных. В чем идея рпц? Запускаете специальный демон rpc mapper и он занимается картированием. Каждая служба ходит и говорит "я служба такая-то, отдаю функцию такую-то". Перечислены в файле /etc/rpс. На 111 порту сидит портмаппер. И дальше она начинает раздавать порты. Помимо номера и имени сервиса в портмаппере регистрируются также версии.

Соответственно командочка rpcinfo вам расскажет довольно много о том на каких портах какие функции обслуживаются в вашей системе.

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

Проблемы анонсирования мы обсудим в следующий раз.

LecturesCMC/LinuxNetwork2013/Conspects/07 (last edited 2013-11-16 11:02:58 by Allena)