Ответы, отчеты, курсовые, лекции 1-3 курс (1, 2, 3, 4, 5 семестр) ЧГУ КТ-43-15 / 5 семестр / Операционные системы и сети (Димитриев)

DoS (от англ. Denial of Service — отказ в обслуживании) — хакерская атака на вычислительную систему с целью довести её до отказа, то есть создание таких условий, при которых добросовестные пользователи системы не могут получить доступ к предоставляемым системным ресурсам (серверам), либо этот доступ затруднён. Отказ «вражеской» системы может быть и шагом к овладению системой (если в нештатной ситуации ПО выдаёт какую-либо критическую информацию — например, версию, часть программного кода и т. д.). Но чаще это мера экономического давления: потеря простой службы, приносящей доход, счета от провайдера и меры по уходу от атаки ощутимо бьют «цель» по карману. DoS и DDoS-атаки наиболее популярны, так как позволяют довести до отказа практически любую систему, не оставляя юридически значимых улик.

Обычно злоумышленники пользуются флудом (англ. flood — «наводнение», «переполнение») — атака, связанная с большим количеством обычно бессмысленных или сформированных в неправильном формате запросов к компьютерной системе или сетевому оборудованию, имеющая своей целью или приведшая к отказу в работе системы из-за исчерпания системных ресурсов

Ботнет (англ. botnet, МФА: [ˈbɒtnɛt]; произошло от слов robot и network) — компьютерная сеть, состоящая из некоторого количества хостов, с запущенными ботами — автономным программным обеспечением. Чаще всего бот в составе ботнета является программой, скрытно устанавливаемой на устройство жертвы и позволяющей злоумышленнику выполнять некие действия с использованием ресурсов заражённого компьютера. Обычно используются для нелегальной или неодобряемой деятельности — рассылки спама, перебора паролей на удалённой системе, атак на отказ в обслуживании (DoS и DDoS атаки).

Боты, как таковые, не являются вирусами. Они представляют собой набор программного обеспечения, который может состоять из вирусов, брандмауэров, программ для удаленного управления компьютером, а также инструментов для скрытия от операционной системы[1].

Хакерская атака - действие, целью которого является захват контроля (повышение прав) над удалённой/локальной вычислительной системой, либо её дестабилизация, либо отказ в обслуживании

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

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

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

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

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

Обычно уязвимость позволяет атакующему «обмануть» операционную систему — заставить её совершить действие, на которое нет прав. Это делается путём внедрения каким-либо образом в модули данных или кода в такие места, что операционная система воспримет их как «свои». Некоторые уязвимости появляются из-за недостаточной проверки данных, вводимых пользователем, и позволяют вставить в интерпретируемый код произвольные команды (SQL-инъекция, XSS). Другие уязвимости появляются из-за более сложных проблем, таких как запись данных в буфер без проверки его границ (переполнение буфера).

Наиболее распространённая в настоящее время на подключенных к интернету компьютерах операционная система Microsoft Windows содержит множественные опасные уязвимости. Чаще всего хакерами используются уязвимости в IIS, MS SQL и Internet Explorer, а также системах обработки файлов и сервисах сообщений самой операционной системы.

72. Модель Белла-Ла-Падулы. Модель Биба.

Модель Белла — Лападулы — модель контроля и управления доступом, основанная на мандатной модели управления доступом. В модели анализируются условия, при которых невозможно создание информационных потоков от субъектов с более высоким уровнем доступа к субъектам с более низким уровнем доступа.

Модель Белла — Лападулы является моделью разграничения доступа к защищаемой информации. Она описывается конечным автоматом с допустимым набором состояний, в которых может находиться информационная система. Все элементы, входящие в состав информационной системы, разделены на две категории — субъекты и объекты. Каждому субъекту присваивается свой уровень доступа, соответствующий степени конфиденциальности. Аналогично, объекту присваивается уровень секретности. Понятие защищённой системы определяется следующим образом: каждое состояние системы должно соответствовать политике безопасности, установленной для данной информационной системы. Переход между состояниями описывается функциями перехода. Система находится в безопасном состоянии в том случае, если у каждого субъекта имеется доступ только к тем объектам, к которым разрешен доступ на основе текущей политики безопасности. Для определения, имеет ли субъект права на получение определенного вида доступа к объекту, уровень секретности субъекта сравнивается с уровнем секретности объекта, и на основе этого сравнения решается вопрос, предоставить или нет запрашиваемый доступ. Наборы уровень доступа/уровень секретности описываются с помощью матрицы доступа.

МОДЕЛЬ БИБА

Модель Биба (Biba), предложенная Кеннетом Биба в 1977 году, также является формальной моделью безопасного управления доступом, однако под безопасностью в этом случае понимается целостность.

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

73. Разграничение полномочий. Дискреционное и мандатное управление доступом.

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

Согласно требованиям ФСТЭК мандатное управление доступом или «метки доступа» являются ключевым отличием систем защиты Государственной Тайны РФ старших классов 1В и 1Б от младших классов защитных систем на классическом разделении прав по матрице доступа.

Пример: субъект «Пользователь № 2», имеющий допуск уровня «не секретно», не может получить доступ к объекту, имеющему метку «для служебного пользования». В то же время, субъект «Пользователь № 1» с допуском уровня «секретно» право доступа к объекту с меткой «для служебного пользования» имеет.

Избирательное управление доступом (англ. discretionary access control, DAC) — управление доступом субъектов к объектам на основе списков управления доступом или матрицы доступа. Также используются названия «дискреционное управление доступом», «контролируемое управление доступом» или «разграничительное управление доступом».

Субъект доступа «Пользователь № 1» имеет право доступа только к объекту доступа № 3, поэтому его запрос к объекту доступа № 2 отклоняется. Субъект «Пользователь № 2» имеет право доступа как к объекту доступа № 1, так и к объекту доступа № 2, поэтому его запросы к данным объектам не отклоняются.

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

Возможны несколько подходов к построению дискреционного управления доступом: Каждый объект системы имеет привязанного к нему субъекта, называемого владельцем. Именно владелец устанавливает права доступа к объекту. Система имеет одного выделенного субъекта — суперпользователя, который имеет право устанавливать права владения для всех остальных субъектов системы. Субъект с определённым правом доступа может передать это право любому другому субъекту

74. Алгоритмы шифрования.

Сегодня криптосистемы используются повсеместно. Самым ярким примером можно считать, скажем, алгоритм шифрования AES256, являющийся международным стандартом. С точки зрения компьютерной терминологии, он позволяет использовать ключ длиной 256 бит. Вообще современные алгоритмы шифрования достаточно разнообразны, а разделить их условно можно на два больших класса: симметричные и асимметричные. Они, в зависимости от области назначения, сегодня применяются очень широко. И выбор алгоритма шифрования напрямую зависит от поставленных задач и метода восстановления информации в исходном виде. Симметричный алгоритм шифрования DES, разработанный еще в 1977 году, подразумевает наличие единого ключа, который, предположительно, известен двум заинтересованным сторонам. Зная такой ключ, нетрудно применить его на практике, чтобы прочитать тот же бессмысленный набор символов, приведя его, так сказать, в читабельный вид. В Асимметричных алгоритмах шифрования применяются два ключа, то есть для кодирования исходной информации использует один, для расшифровки содержимого – другой, причем совершенно необязательно, чтобы они совпадали или одновременно находились у кодирующей и декодирующей стороны. Для каждой из них достаточно одного. Таким образом, в очень высокой степени исключается попадание обоих ключей в третьи руки.

75. Антивирусное программное обеспечение.

Антивирусные программы, предназначены для обнаружения и удаления компьютерных вирусов. Детекторы. Эти программы обнаруживают загрузочные вирусы в системных областях дискет и дисков, сканируют файлы на магнитных дисках с целью обнаружения фрагментов кодов (сигнатур) уже известных вирусов. Функция детектирования включается во все современные антивирусные программы. Фаги способны не только обнаружить, но и уничтожить вирус, удалив код вируса из инфицированного файла и восстановив работоспособность программы. Ревизоры контролируют пути распространения вирусов, являются самыми надежными. Эти программы используют средства слежения за изменениями файлов и системных областей дисков, прием информации из Интернета. Однако такая защита замедляет работу компьютера, поэтому эти программы мало распространены. Фильтры располагаются в оперативной памяти резидентно и контролируют операции с файлами, выводят сообщения для пользователя об операции. Так как обычные программы тоже выполняют операции с файлами, вывод сообщений раздражает пользователей, и они редко применяют эти антивирусные программы. Вакцины ведут себя подобно вирусам, но вреда не причиняют. Предохраняют файлы от изменений со стороны уже известного вируса, способны обнаружить и иногда вылечить файл. Вакцины модифицируют программу или диск так, чтобы вирус считал их уже зараженными и не пытался внедриться. В настоящее время применяются редко.

76. Сетевые ОС и распределенные ОС.

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

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

77.Функциональные компоненты сетевой ОС

1) Средства управления локальными ресурсами - реализуют все функции автономного компьютера

a.Распределение памятью;

b.Планирование и диспетчеризацию процессов;

c.Управление внешней памятью;

d. Интерфейс с пользователем и пр.

2) Сетевые средства можно разделить на три компонента:

a.Серверная часть ОС - предоставляет локальные ресурсы в общее пользование;

b.Клиентская часть ОС - средства доступа к удаленным ресурсам и услугам;

c.Транспортные средства ОС, которые совместно с коммуникационной системой обеспечивает передачу сообщений в сети. Совокупность серверных и клиентских частей ОС, которая предоставляет доступ конкретному типу ресурса ЭВМ через сеть, называется сетевой службой, сетевая служба в свою очередь предоставляет набор услуг пользователю, который называется сетевой сервис. Каждая служба связана с определенным типом сетевых ресурсов и (или) определенным способом доступа к этим ресурсам. Наиболее важными для пользователей ОС является файловая служба и службы печати. Файловая служба – совокупность клиентской и серверной части ОС, которая обеспечивает доступ через сеть файловой системы ЭВМ. Чаще всего файловая система ЭВМ древовидная (иерархическая). Среди сетевой службы особое место занимают такие, которые ориентированы для администрирования. Сетевые службы по своей природе являются клиент – серверными системами, т.е. инициатором выполнения работы сетевой службы всегда выступает клиент, а сервер всегда находится в режиме пассивного ожидания. Обязательные условия таких систем, что клиент и сервер поддерживают один стандартный протокол взаимодействия. От набора услуг, который предлагает ОС конечному пользователю, зависимость ее позиции в ряду СОС. На практике сложилось несколько подходов к построению сетевых операционных систем, различающихся глубиной внедрения сетевых служб в операционную систему: 1.сетевые службы глубоко встроены в ОС. 2.сетевые службы объединены в виде некоторого набора – оболочки 3.сетевые службы производятся и поставляются в виде отдельного продукта.

Сетевые оболочки часто подразделяются на клиентские и серверные. Оболочка, которая преимущественно содержит клиентские части сетевых служб, называется клиентской. Например, типичным набором программного обеспечения рабочей станции в сети NetWare является система MS-DOS с установленной над ней клиентской оболочкой NetWare, состоящей из клиентских частей файловой службы и службы печати, а также компонента, поддерживающего пользовательский интерфейс. Серверная сетевая оболочка, ориентирована на выполнение серверных функций. Серверная оболочка как минимум содержит серверные компоненты двух основных сетевых служб - файловой службы и службы печати. Некоторые же оболочки содержат настолько широкий набор сетевых служб, что их называют сетевыми операционными системами. Таким образом, термин «сетевая операционная система» приобретает еще

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

78. Модель разделения приложений на части. Трехзвенные системы.

Трёхуровневая архитектура - архитектурная модель программного комплекса, предполагающая наличие в нём трёх компонентов: клиента, сервера приложений (к которому подключено клиентское приложение) и сервера баз данных (с которым работает сервер приложений).

Клиент (слой клиента) — это интерфейсный (обычно графический) компонент комплекса, предоставляемый конечному пользователю. Этот уровень не должен иметь прямых связей с базой данных (по требованиям безопасности и масштабируемости), быть нагруженным основной бизнес-логикой (по требованиям масштабируемости) и хранить состояние приложения (по требованиям надёжности). На этот уровень обычно выносится только простейшая бизнес-логика: интерфейс авторизации, алгоритмы шифрования, проверка вводимых значений на допустимость и соответствие формату, несложные операции с данными (сортировка, группировка, подсчёт значений), уже загруженными на терминал.

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

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

79. Двухзвенные системы. Файл-сервер, эмуляция терминала, клиент-сервер.

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

Файл-сервер.

В данном случае сервер, на котором лежит база данных, является исключительно хранилищем и не обладает каким-либо функционалом, позволяющим производить математические и/или логические вычисления. Поэтому в файл-серверной архитектуре формирование отчета выглядит так: вся таблица с продажами за весь период, какой бы большой он ни был, по сети копируется на компьютер, запросивший формирование отчета. Когда передача этого файла закончена, непосредственно компьютер пользователя приступает к первичной фильтрации таблицы и последующему суммированию нужной колонки. Логично предположить, что файл-серверная технология применима исключительно при работе с небольшими объемами данных, поскольку если объем данных будет велик, то это грозит существенными задержками работы сети и непосредственно пользовательских компьютеров, которые, как известно, изначально не предполагают больших нагрузок, и имеют довольно таки невысокую производительность.

Технологию файл-сервер используют все программы 1С версии 7.7 и ранее, а так же некоторые версии 8.х Клиент-сервер

При использовании клиент-серверной технологии, на самом сервере, содержащим базу данных, функционирует некоторое программное обеспечение, которое называется "Сервером баз данных" или "Сервером БД". Благодаря технологии клиент-сервер, формирование отчета выглядит более "умно": сервер БД получает запрос на формирование отчета, сам фильтрует таблицу, сам суммирует колонку и пользователю по сети отдается уже готовый результат! Таким образом, архитектура клиент-сервер адаптирована для работы с большими объемами данных - сеть нагружается меньше, требования к пользовательским компьютерам, с точки зрения производи-

тельности, минимизируется. Однако возрастают требования к серверу, содержащему базу данных, поскольку теперь он один тянет нагрузку всех пользователей.По технологии клиент-сервер работают программы 1С 8.х, использующие в качестве сервера БД

MS SQL Server.

Терминал-сервер Технология терминал-сервер принципиально отличается от двух предыдущих, тем, что конечному пользователю по сети переда-

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

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

80.Базовые примитивы передачи сообщений в распределенных системах

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

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

Несмотря на концептуальную простоту этих системных вызовов - ПОСЛАТЬ и ПОЛУЧИТЬ - существуют различные варианты их реализации, от правильного выбора которых зависит эффективность работы сети. В частности, эффективность коммуникаций в сети зависит от способа задания адреса, от того, является ли системный вызов блокирующим или неблокирующим, какие выбраны способы буферизации сообщений и насколько надежным является протокол обмена сообщениями.

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

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

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

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

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

Буферизуемые и не буферизуемые примитивы Примитивы, которые были описаны, являются не буферизуемыми примитивами. Это означает, что вызов ПОЛУЧИТЬ сообщает ядру

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

Эта схема работает прекрасно при условии, что получатель выполняет вызов ПОЛУЧИТЬ раньше, чем отправитель выполняет вызов ПОСЛАТЬ. Вызов ПОЛУЧИТЬ сообщает ядру машины, на которой выполняется, по какому адресу должно поступить ожидаемое сообщение, и в какую область памяти необходимо его поместить. Проблема возникает тогда, когда вызов ПОСЛАТЬ сделан раньше вызова ПОЛУЧИТЬ. Каким образом сможет узнать ядро на машине получателя, какому процессу адресовано вновь поступившее сообщение, если их несколько? И как оно узнает, куда его скопировать?

Один из вариантов - просто отказаться от сообщения, позволить отправителю взять тайм-аут и надеяться, что получатель все-таки выполнит вызов ПОЛУЧИТЬ перед повторной передачей сообщения. Этот подход не сложен в реализации, но, к сожалению, отправитель (или скорее ядро его машины) может сделать несколько таких безуспешных попыток. Еще хуже то, что после достаточно большого числа безуспешных попыток ядро отправителя может сделать неправильный вывод об аварии на машине получателя или о неправильности использованного адреса.

Второй подход к этой проблеме заключается в том, чтобы хранить хотя бы некоторое время, поступающие сообщения в ядре получателя на тот случай, что вскоре будет выполнен соответствующий вызов ПОЛУЧИТЬ. Каждый раз, когда поступает такое "неожидаемое" сообщение, включается таймер. Если заданный временной интервал истекает раньше, чем происходит соответствующий вызов ПОЛУЧИТЬ, то сообщение теряется. Хотя этот метод и уменьшает вероятность потери сообщений, он порождает проблему хранения и управления преждевременно поступившими сообщениями. Необходимы буферы, которые следует где-то размещать, освобождать, в общем, которыми нужно управлять. Концептуально простым способом управления буферами является определение новой структуры данных, называемой почтовым ящиком. Процесс, который заинтересован в получении сообщений, обращается к ядру с запросом о создании для него почтового ящика и сообщает адрес, по которому ему могут поступать сетевые пакеты, после чего все сообщения с данным адресом будут помещены в его почтовый ящик. Такой способ часто называют буферизуемым примитивом.

81.Блокирующие и неблокирующие примитивы

Примитивы бывают блокирующими и неблокирующими, иногда они называются соответственно синхронными и асинхронными. При использовании блокирующего примитива, процесс, выдавший запрос на его выполнение, приостанавливается до полного завершения примитива. Например, вызов примитива ПОЛУЧИТЬ приостанавливает вызывающий процесс до получения сообщения. При использовании неблокирующего примитива управление возвращается вызывающему процессу немедленно, еще до того, как требуемая работа будет выполнена. Преимуществом этой схемы является параллельное выполнение вызывающего процесса и процесса передачи сообщения. Обычно в ОС имеется один из двух видов примитивов и очень редко - оба. Однако выигрыш в производительности при использовании неблокирующих примитивов компенсируется серьезным недостатком: отправитель не может модифицировать буфер сообщения, пока сообщение не отправлено, а узнать, отправлено ли сообщение, отправитель не может. Отсюда сложности в построении программ, которые передают последовательность сообщений с помощью неблокирующих примитивов.

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

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

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

82. Понятие сокета. Механизм сокетов ОС UNIX

Со́кет (англ. socket — разъём) — название программного интерфейса для обеспечения обмена данными между процессами. Процессы при таком обмене могут исполняться как на одной ЭВМ, так и на различных ЭВМ, связанных между собой сетью. Сокет — абстрактный объект, представляющий конечную точку соединения.

Следует различать клиентские и серверные сокеты. Клиентские сокеты грубо можно сравнить с конечными аппаратами телефонной сети, а серверные — с коммутаторами. Клиентское приложение (например, браузер) использует только клиентские сокеты, а серверное (например, веб-сервер, которому браузер посылает запросы) — как клиентские, так и серверные сокеты.

Интерфейс сокетов впервые появился в BSD Unix. Программный интерфейс сокетов описан в стандарте POSIX.1 и в той или иной мере поддерживается всеми современными операционными системами.

Как известно, для взаимодействия между машинами с помощью стека протоколов TCP/IP используются адреса и порты. Первое на текущий момент представляет собой 32-битный адрес (для протокола IPv4, 128-битный для IPv6), наиболее часто его представляют в символьной форме mmm.nnn.ppp.qqq (адрес, разбитый на четыре поля, разделённых точками, по одному байту в поле).

Второе — это номер порта в диапазоне от 0 до 65535 (для протокола TCP). Эта пара и есть сокет («гнездо», соответствующее адресу и порту).

В процессе обмена, как правило, используется два сокета — сокет отправителя и сокет получателя. Например, при обращении к серверу на HTTP-порт сокет будет выглядеть так: 194.106.118.30:80, а ответ будет поступать на mmm.nnn.ppp.qqq: xxxxx.

Каждый процесс может создать «слушающий» сокет (серверный сокет) и привязать его к какому-нибудь порту операционной системы (в UNIX непривилегированные процессы не могут использовать порты меньше 1024).

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

Механизм сокетов (sockets) впервые появился в версии 4.3 BSD UNIX (Berkeley Software Distribution UNIX — ветвь UNIX, начавшая развиваться в калифорнийском университете Беркли). Позже он превратился в одну из самых популярных систем сетевого обмена сообщениями. Сегодня этот механизм реализован во многих операционных системах, иногда его по-прежнему называют Berkeley Sockets, отдавая дань уважения его создателям, хотя существует большое количество его реализаций как для различных ОС семейства UNIX, так и для других ОС, например для ОС семейства Windows, где он носит название Windows Sockets (WinSock).

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

Независимость от нижележащих сетевых протоколов и технологий. Для этого используется понятие коммуникационный домен. Коммуникационный домен обладает некоторым набором коммуникационных свойств, определяющих способ именования сетевых узлов и ресурсов, характеристики сетевых соединений.Одним из наиболее популярных доменов является домен Интернета с протоколами стека TCP/IP.

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

Сокет может иметь как высокоуровневое символьное имя (адрес), так и низкоуровневое, отражающее специфику адресации определенного коммуникационного домена. Например, в домене Интернета низкоуровневое имя представлено парой (IP-адрес, порт).

Для каждого коммуникационного домена могут существовать сокеты различных типов. С помощью типа сокета можно задавать определенный вид взаимодействия, имеющий смысл для домена. Так, во многих доменах существуют дейтаграммные соединения (datagram) и соединения потоковые (stream), гарантирующие надежную упорядоченную доставку.

Для обмена сообщениями механизм сокетов предлагает следующие примитивы, реализованные как системные вызовы. Создание сокета:

Процесс должен создать сокет перед началом его использования. Системный вызов socket создает новый сокет с параметрами, определяющими коммуникационный домен (domain), тип соединения, поддерживаемого сокетом (type), и транспортный протокол (например, TCP или UDP), который будет поддерживать это соединение. Если транспортный протокол не задан, то система сама выбирает протокол, соответствующий типу сокета. Указание домена определяет возможные значения остальных двух параметров. Системный вызов socket возвращает дескриптор созданного сокета, который используется как идентификатор сокета в последующих операциях.

Связывание сокета с адресом:

Системный вызов bind связывает созданный сокет с его высокоуровневым именем либо с низкоуровневым адресом. Адрес addrотносится к тому узлу, на котором расположен сокет. Для низкоуровневого адреса домена Интернета адресом будет пара (IP-адрес, порт). Третий параметр делает адрес доменно-независимым, позволяя задавать адреса различных типов, в том числе символьные. Связывать сокет с адресом необходимо только в том случае, если на данный сокет будут приниматься сообщения.

Запрос на установление соединения с удаленным сокетом:

Системный вызов connect используется только в том случае, если предполагается передавать сообщения в потоковом режиме, который требует установления соединения. Процедура установления несимметрична: один процесс (процесс-сервер) ждет запроса на установление соединения, а второй (процесс-клиент) — инициирует соединение, посылая такой запрос. Системный вызов connect является запросом клиента на установление соединения с сервером. Второй и третий аргументы вызова указывают адрес сокета сервера, с которым устанавливается соединение. После установления соединения сообщения по нему могут передаваться в дуплексном режиме, то есть в любом направлении. Системный вызов write, используемый для передачи сообщений в рамках установленного соединения, не требует указания адреса сокета получателя, так как локальный сокет, через который сообщение отправляется, уже соединен с определенным удаленным сокетом. Способ, с помощью которого клиенты узнают адрес сокета сервера, не стандартизован.

Ожидание запроса на установление соединения:

Системный вызов listen используется для организации режима ожидания сервером запросов на установление соединения. Система обмена сообщениями после отработки данного системного вызова будет принимать запросы на установление, имеющие адрес сокета s, и передавать их на обработку другому системному вызову — accept, который решает, принимать их или отвергать.

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

Принятие запроса на установление соединения:

Системный вызов accept используется сервером для приема запроса на установление соединения, поступившего от системного вызова listen через сокет s от клиента с адресом client_addr (если этот аргумент опущен, то принимается запрос от любого клиента). При этом создается новый сокет snew, через который и устанавливается соединение с данным клиентом. Таким образом, сокет s используется сервером для приема запросов на установление соединения от клиентов, а сокеты snew — для обмена сообщениями с клиентами по индивидуальным соединениям.

Отправка сообщения по установленному соединению:

Сообщение длиной msg_len, хранящееся в буфере message, отправляется получателю, с которым предварительно соединен сокет s. Прием сообщения по установленному соединению:

Сообщение, поступившее через сокет snew, с которым предварительно соединен отправитель, принимается в буфер buffer размером amount. Если сообщений нет, то процесс-получатель блокируется.

Отправка сообщения без установления соединения:

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

Прием сообщения без установления соединения:

Аналогично предыдущему вызову при приеме без установленного соединения в каждом вызове recvfrom указывается адрес сокета отправителя, от которого нужно принять сообщение. Если сообщений нет, то процесс-получатель блокируется.

83.Основные концепции удаленного вызова процедур. Базовые операции RPC.

Концепция удаленного вызова процедур

Идея вызова удаленных процедур (Remote Procedure Call - RPC) состоит в расширении хорошо извест-

ного и понятного механизма передачи управления и данных внутри программы, выполняющейся на одной ма-

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

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

большим временем ответов и относительно малым количеством передаваемых данных. Такие приложения называются RPC-ориентированными.

Характерными чертами вызова локальных процедур являются:

Асимметричность, то есть одна из взаимодействующих сторон является инициатором;

Синхронность, то есть выполнение вызывающей процедуры при останавливается с момента выдачи за-

проса и возобновляется только после возврата из вызываемой процедуры.

Реализация удаленных вызовов существенно сложнее реализации вызовов локальных процедур. Начнем с того, что поскольку вызывающая и вызываемая процедуры выполняются на разных машинах, то они имеют разные адресные пространства, и это создает проблемы при передаче параметров и результатов, особенно если машины не идентичны. Так как RPC не может рассчитывать на разделяемую память, то это означает, что па-

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

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

нение вызывающей программы и вызываемой локальной процедуры в одной машине реализуется в рамках единого процесса. Но в реализации RPC участвуют как минимум два процесса - по одному в каждой машине.

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

ющей процедуры удаленно вызванные процедуры станут "осиротевшими", а при аварийном завершении уда-

ленных процедур станут "обездоленными родителями" вызывающие процедуры, которые будут безрезуль-

татно ожидать ответа от удаленных процедур.

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

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

Эти и некоторые другие проблемы решает широко распространенная технология RPC, лежащая в основе многих распределенных операционных систем.

Базовые операции RPC

Чтобы понять работу RPC, рассмотрим вначале выполнение вызова локальной процедуры в обычной машине, работающей автономно. Пусть это, например, будет системный вызов

count=read (fd,buf,nbytes);

где fd - целое число, buf - массив символов, nbytes - целое число.

Чтобы осуществить вызов, вызывающая процедура заталкивает параметры в стек в обратном порядке

(рисунок 3.1). После того, как вызов read выполнен, он помещает возвращаемое значение в регистр, переме-

щает адрес возврата и возвращает управление вызывающей процедуре, которая выбирает параметры из стека,

возвращая его в исходное состояние. Заметим, что в языке С параметры могут вызываться или по ссылке (by name), или по значению (by value). По отношению к вызываемой процедуре параметры-значения являются инициализируемыми локальными переменными. Вызываемая процедура может изменить их, и это не повлияет на значение оригиналов этих переменных в вызывающей процедуре.

Если в вызываемую процедуру передается указатель на переменную, то изменение значения этой пере-

менной вызываемой процедурой влечет изменение значения этой переменной и для вызывающей процедуры.

Этот факт весьма существенен для RPC.

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

вается call-by-copy/restore и состоит в необходимости копирования вызывающей программой переменных в стек в виде значений, а затем копирования назад после выполнения вызова поверх оригинальных значений вызывающей процедуры.

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

Идея, положенная в основу RPC, состоит в том, чтобы сделать вызов удаленной процедуры выглядящим по возможности также, как и вызов локальной процедуры. Другими словами - сделать RPC прозрачным: вы-

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

ентским стабом (stub - заглушка). Подобно оригинальной процедуре, стаб вызывается с использованием вызы-

вающей последовательности (как на рисунке 3.1), так же происходит прерывание при обращении к ядру.

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

84.Методы генерации стабов. Формат сообщений RPC. Реализация RPC.

Генерация стабов Стабы могут генерироваться либо вручную, либо автоматически. В первом случае программист исполь-

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

граммист при этом способе получает большую свободу в выборе способа передачи параметров вызова и при-

менении тех или иных примитивов передачи сообщений, однако этот способ связан с большим объемом руч-

ного труда.

Автоматический способ основан на применении специального языка определения интерфейса (Interface Definition Language, IDL). С помощью этого языка программист описывает интерфейс между клиентом и сер-

вером RPC. Описание включает список имен процедур, выполнение которых клиент может запросить у сер-

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

следовательности. Кроме того, описание интерфейса содержит некоторую дополнительную информацию, по-

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

ной или играющий и ту, и другую роли (входной аргумент передается от клиента серверу, а выходной — в

обратном направлении). Интерфейс может включать также описание общих для клиента и сервера констант.

Необходимо подчеркнуть, что обычно интерфейс RPC включает не одну, а некоторый набор процедур, выпол-

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

Поэтому при вызове удаленной процедуры обычно необходимо каким-то образом задать нужный интерфейс,

а также конкретную процедуру, поддерживаемую этим интерфейсом. Часто интерфейс также называют серве-

ром RPC, например файловый сервер, сервер печати.

После того как описание интерфейса составлено программистом, оно компилируется специальным IDL-

компилятором, который вырабатывает исходные модули клиентских и серверных стабов для указанных в опи-

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

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

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

ложение наряду с любыми другими модулями как написанными программистом, так и библиотечными, ком-

пилироваться и связываться в исполняемую программу стандартными средствами инструментальной системы программирования.

Формат сообщений RPC

Механизм RPC оперирует двумя типами сообщений: сообщениями-вызовами, с помощью которых кли-

ент запрашивает у сервера выполнение определенной удаленной процедуры и передает ее аргументы; сообще-

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

Спомощью этих сообщений реализуется протокол RPC, определяющий способ взаимодействия клиента

ссервером. Протокол RPC обычно не зависит от транспортных протоколов, с помощью которых сообщения

RPC доставляются по сети от клиента к серверу и обратно. При использования в сети стека протоколов TCP/IP

это могут быть протоколы TCP или UDP, в локальных сетях часто ис1 пользуется также NetBEUI/NetBIOS или

IPX/SPX.

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

нерации стабов присваивает им IDL-компилятор, а при ручной — программист). Поле аргументов имеет пере-

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

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

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

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

рах аутентификации клиента, если эти процедуры предусмотрены протоколом RPC.

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

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

мальному выполнению процедуры. Такие ситуации могут возникнуть еще до выполнения, так как клиенту мо-

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

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

Для устойчивой работы серверов и клиентов RPC необходимо каким-то образом обрабатывать ситуа-

ции, связанные с потерями сообщений, которые происходят из-за ошибок сети (эти ошибки транспортные про-

токолы пытаются компенсировать, но все равно некоторая вероятность потерь все же остается) или же по при-

чине краха операционной системы и перезагрузки компьютера (здесь транспортные протоколы исправить си-

туацию не могут). Протокол RPC использует в таких случаях механизм тайм-аутов с повторной передачей сообщений. Для того чтобы сервер мог повторно переслать клиенту потерянный результат без необходимости передачи от клиента повторного вызова, в протокол RPC иногда добавляется специальное сообщение — под-

тверждение клиента, которое тот посылает при получении ответа от сервера.

Связывание клиента с сервером Рассмотрим вопрос о том, как клиент узнает место расположения сервера, которому необходимо послать со-

общение-вызов. Процедура, устанавливающая соответствие между клиентом и сервером RPC, носит название связывание (binding). Методы связывания, применяемые в различных реализациях RPC, отличаются:

-способом задания сервера, с которым хотел бы быть связанным клиент;

-способом обнаружения сетевого адреса (места расположения) требуемого сервера процессом связыва-

ния;

- стадией, на которой происходит связывание.

Метод связывания тесно связан с принятым методом именования сервера. В наиболее простом случае имя или адрес сервера RPC задается в явной форме, в качестве аргумента клиентского стаба или программы-

сервера, реализующей интерфейс определенного типа. Например, можно использовать в качестве такого аргу-

мента IP-адрес компьютера, на котором работает некоторый RPC-сервер, и номер TCP/UDP порта, через кото-

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

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

фического представления имеющихся в сети разделяемых файловых систем (набор этих файловых систем мо-

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

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

мого сервера на основании заранее известной ему информации об адресе или имени сервера.

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