Околения компьютеров
 Скачать 1.67 Mb.
|
|
flags – может содержать комбинацию специальных опций. Нас будут интересовать две из них: MSG_OOB – этот флаг сообщает ОС, что процесс хочет осуществить прием/передачу экстренных сообщений MSG_PEEK – данный флаг может устанавливаться при вызове recv(). При этом процесс получает возможность прочитать порцию данных, не удаляя ее из сокета, таким образом, что последующий вызов recv() вновь вернет те же самые данные. Другая пара функций, которые могут использоваться при работе с сокетами с предварительно установленным соединением – это обычные read() и write(), в качестве дескриптора которым передается дескриптор сокета. И, наконец, пара функций, которая может быть использована как с сокетами с установлением соединения, так и с сокетами без установления соединения: #include #include Первые 4 аргумента у них такие же, как и у рассмотренных выше. В последних двух в функцию sendto() должны быть переданы указатель на структуру, содержащую адрес получателя, и ее размер, а функция recvfrom() в них возвращает соответственно указатель на структуру с адресом отправителя и ее реальный размер. Отметим, что перед вызовом recvfrom() параметр fromlen должен быть установлен равным первоначальному размеру структуры from. Здесь, как и в функции accept, если нас не интересует адрес отправителя, в качестве from можно передать NULL. Завершение работы с сокетом. Если процесс закончил прием либо передачу данных, ему следует закрыть соединение. Это можно сделать с помощью функции shutdown(): # include # include 6 Отметим, что, как уже говорилось, при использовании сокетов с установлением виртуального соединения границы сообщений не сохраняются, поэтому приложение, принимающее сообщения, может принимать данные совсем не теми же порциями, какими они были посланы. Вся работа по интерпретации сообщений возлагается на приложение. Помимо дескриптора сокета, ей передается целое число, которое определяет режим закрытия соединения. Если mode=0, то сокет закрывается для чтения, при этом все дальнейшие попытки чтения будут возвращать EOF. Если mode=1, то сокет закрывается для записи, и при осуществлении в дальнейшем попытки передать данные будет выдан кода неудачного завершения (-1). Если mode=2, то сокет закрывается и для чтения, и для записи. Аналогично файловому дескриптору, дескриптор сокета освобождается системным вызовом close(). При этом, разумеется, даже если до этого не был вызван shutdown(), соединение будет закрыто. Таким образом, в принципе, если по окончании работы с сокетом мы собираемся закрыть соединение и по чтению, и по записи, можно было бы сразу вызвать close() для дескриптора данного сокета, опустив вызов shutdown(). Однако, есть небольшое различие с тем случаем, когда предварительно был вызван shutdown(). Если используемый для соединения протокол гарантирует доставку данных (т.е. тип сокета – виртуальный канал), то вызов close() будет блокирован до тех пор, пока система будет пытаться доставить все данные, находящиеся «в пути» (если таковые имеются), в то время как вызов shutdown() извещает систему о том, что эти данные уже не нужны и можно не предпринимать попыток их доставить, и соединение закрывается немедленно. Таким образом, вызов shutdown() важен в первую очередь для закрытия соединения сокета с использованием виртуального канала. Резюме: общая схема работы с сокетами. Мы рассмотрели все основные функции работы с сокетами. Обобщая изложенное, можно изобразить общую схему работы с сокетами с установлением соединения в следующем виде: socket bind connect send recv shutdown close socket bind listen accept send recv shutdown close Серверный сокет Клиентский сокет новый сокет shutdown close Рис. 12 Схема работы с сокетами с установлением соединения БИЛЕТ 37 Общая схема работы с сокетами без предварительного установления соединения проще, она такова: socket sendto recvfrom shutdown bind close Рис. 13 Схема работы с сокетами без установления соединения Билет 38 ??????????????????????????????????????????????? ????? Билет 39. Основные правила работы с файлами. Типовые программные интерфейсы работы с файлами. Файловая система (ФС) - часть операционной системы, представляющая собой совокупность организованных наборов данных, хранящихся на внешних запоминающих устройствах, и программных средств, гарантирующих именованный доступ к этим данным и их защиту Возможности предоставляемые ФС определяют эксплутационные качества ФС. От оптимальности организации зависит область применимости ФС. ФС – компонент ОС обеспечивающий именованный доступ к данным. Данные называются файлами, их имена - именами файлов. Ранее работа с данными осуществлялась через координаты их на внешних носителях. Это было неудобно, т.к. надо было помнить о местонахождении данных, перемещение программы с одного носителя на другой тоже вызывало трудности. Если возникала потребность менять входные данные в программе, то это тоже было не легко. ФС совершила революцию. Появилась возможность ассоциировать с совокупностью данных некоторое имя и осуществлять доступ к данным через указатель имени. ОС брала на себя функции размещения данных, ассоциированных с именем, сохранение информации, соответствующей данному имени. Структурная организация файлов Существует множество разновидностей структурной организации файлов. Наиболее популярные: 1. Файл, как последовательность байтов (обмен от 1 до фиксированного числа байтов) Т.е. файл – это набор данных, практически не имеющих никакой структуры. Соответственно вопрос выделения логической структуры – это уже проблема пользователя. Пользователь записывает данные, как последовательность байтов, считывает их и сам уже интерпретирует. Как ни странно, на сегодняшний день – это одна из самых распространенных моделей структурной организации файлов. Таким образом организуются файловые системы Unix, Windows, т.е. файл там может быть представлен как просто последовательность байтов 2. Файл, как последовательность записей переменной длины (обмен в терминах записи, информация в виде последовательности записей, поле данных + символ конца записи, последовательный доступ) В этом случае каждая запись, кроме содержательной информации, должна была иметь некоторую специальную информацию. эта специальная информация могла быть либо полем, которому указывалась длина записи, либо специальная информация могла представляться в виде специального кода - маркера конца или начала записи. При такой организации внутренней фрагментации практически не было, за исключением тех потерь, которые приходились на разметку файла по записи, т.е. либо указатели длины, либо маркеры начала и конца. В этом плане эффективность организации хранения была относительно хорошей. С другой стороны такая организация исключала прямой доступ к записи. Т.е. для того, чтобы добраться до i-ой записи нужно было промотать все предыдущие: либо пересчитать маркеры начала и конца, либо пробежаться по списку через указатели длины. Файлы такой организации имели сложность с точки зрения редактирования, т.е. изменение длины существующей записи с большой вероятностью приводило к проблеме. Поскольку увеличение записи – это вообще затруднительная операция, а уменьшение – тоже есть некоторая проблема. Т.е. есть какая-то внутренняя проблема, которая приводила к неэффективности редактирования такого рода файлов. Записи постоянной длины организованы были так, что в пределах размера записи никаких проблем не возникало. Проблемы возникали только в том случае, если происходило либо удаление записи, либо вставка новой записи. 3. Файл, как последовательность записей постоянной длины (обмен в терминах записей постоянной длины) Исторически этот вариант структурной организации появился из-за использования такого носителя информации, как перфокарты. Т.е. было удобно делать файл, который был прямым аналогом колоды перфокарт. Соответственно это означает, что читать из файла или писать данные в этот файл система позволяла порциями размером в 80 байт. Понятно, что такая организации файла достаточно эффективна по скорости доступа, т.е. был прямой доступ к любой записи, потому что координаты записи внутри вычислялись всегда очень просто: (номер записи)*(размер записи). С другой стороны – внутренняя фрагментация. Один байт используется в записи и вся запись размером в 80 байтов становится занятой. 4. Иерархическая организация файла (дерево) (поиск, сортировка и т.д. осуществляется по ключам). Суть: структура файла представима в виде дерева. В каждом узле этого дерева находится информация о записи. Информация о записи – это два содержательных поля: поле ключа и поле данных. Соответственно дерево организовано таким образом, что в нем оптимизирован доступ к записям по указанию ключа, т.е. записи отсортированы по одинаковым ключам, и разные ключи отсортированы по возрастанию ключей. Поле данных может быть произвольного размера. Место расположения записи может быть в общем случае произвольно, т.е. ФС может разместить запись, где захочет, по своим каким-то критериям. имеются накладные расходы, связанные с древовидной организацией - с организацией ключей. Обычно, это достаточно специализированные ФС, которые используются или могут использоваться в высокопроизводительных, либо специальных ВС. Дерево, в узлах записи (возможно переменной длины) Атрибуты файла имя права доступа персонификация (создатель, владелец) тип файла размер записи размер файла указатель чтения / записи время создания время последней модификации время последнего обращения предельный размер файла ..... Полный состав атрибутов файла и способ их представления определяется конкретной файловой системой. О О с с н н о о в в н н ы ы е е п п р р а а в в и и л л а а р р а а б б о о т т ы ы с с ф ф а а й й л л а а м м и и Операционная система и файловая система обеспечивают регистрацию возможности того или иного процесса работать с содержимым файлов. «Сеанс работы» с содержимым файла: Начало «открытие» файла (регистрация в системе возможности работы процесса с содержимым файла) Открытие – создание внутрисистемной структуры данных, кот. описывает состояние этого файла, проверяет права доступа, объявляет операционной системе тот факт, что с данным файлом будет работать тот или иной процесс. При открытии файла система формирует внутренние наборы данных, необходимые для работы с содержимым файла. Работа с содержимым файла, с атрибутами файла Завершение «закрытие» файла – информация системе о завершении работы процесса с «открытым» файлом Закрытие файла. Закрытие файла - информация операционной системе о том, что работа с файлом завершена. Операция закрытия файла имеет 2 вида: закрыть и сохранить текущее содержимое файла; уничтожить файл. Типовые программные интерфейсы работы с файлами open – открытие / создание файла «r» - на чтение «w» - на запись … и т.д. close – закрытие read / write – читать, писать (относительно положения указателя чтения / запись, read/write по дескриптору а не по имени) delete – удалить файл из файловой системы (напрямую или дескриптор) seek – позиционирование указателя чтение/запись rename – переименование файла read / write _attributes – чтение, модификация атрибутов файла. Файловый дескриптор – системная структура данных, содержащая информацию о актуальном состоянии «открытого» файла. Файловый дескриптор содержит актуальную информацию о открытом файле. Через ФД можно получить информацию о значении указателей чтения\записи. В некоторых ФС каталог – отдельное внутреннее образование, в UNIX каталог – файл специального типа. Если это файл, то для него можно использовать программные интерфейсы для работы с файлами. Каталог – компонент файловой системы, содержащий информацию о содержащихся в файловой системе файлах. Специальные файлы – каталоги. Билет 40 .Файловые системы. Модели реализации файловых систем. Понятие индексного дескриптора. Файловый дескриптор – системная структура данных, содержащая информацию о актуальном состоянии «открытого» файла. Файловый дескриптор содержит актуальную информацию о открытом файле. Через ФД можно получить информацию о значении указателей чтения\записи. В некоторых ФС каталог – отдельное внутреннее образование, в UNIX каталог – файл специального типа. Если это файл, то для него можно использовать программные интерфейсы для работы с файлами. Каталог – компонент файловой системы, содержащий информацию о содержащихся в файловой системе файлах.Специальные файлы – каталоги. Модель одноуровневой файловой системы. Традиционно-простая организация каталога – одноуровневая модель ФС В ФС существует один каталог, в котором находятся все файлы находящиеся в системе. Проблемы: 1.Коллизия имен. Каждое имя должно быть единственно. 2. нагрузка на работу с системой, если много файлов. 3. неудобно структурировать. Модель двухуровневой файловой системы. Модель, которая появилась в реальных системах на начальных этапах после одноуровневой. В системе существует объединение каталогов пользователей, для каждого пользователя реализована одноуровневая модель. Проблемы 1 и 2 исчезают, а 3 остается. Иерархические файловые системы За основу логической организации такой файловой системы берется дерево. В корне дерева находится, так называемый, корень файловой системы - каталог нулевого уровня. В этом каталоге могут находиться либо файлы пользователей, либо каталоги первого уровня. Каталоги первого и следующих уровней организуются по аналогичному принципу. Файлы пользователя в этом дереве представляются листьями. Пустой каталог также может быть листом. Таким образом образуется древовидная структура файловой системы, где в узлах находятся каталоги, а листьями являются либо файлы, либо пустые каталоги. Остановимся на правилах именования в иерархической файловой системе. В данном случае используется механизм, основанный на понятии имени файла (name) и полного имени файла (path_name). Полное имя файла – это путь от корневого каталога до листа (такой путь всегда будет уникальным). Существует также относительное именование, т.е. когда нет необходимости указания полного пути при работе с файлами. Это происходит в случае, когда программа вызывает файл и подразумевается, что он находится в том же каталоге, что и программа. В данном случае появляется понятие текущего каталога, т. е. каталога, на работу с которым настроена файловая система в данный момент времени. В рамках одного каталога имена файлов одного уровня должны быть разными. Индексные узлы (дескрипторы) ФС организует кластеризованное, компактное хранение информации о размещении блоков файлов в специальной структуре, которая называется индексные узлы или индексные дескрипторы. В этой структуре находится информация о размещении блоков файлов по ФС. Т.е. соответственно есть таблица, в которой размещаются индексные узлы файла. При открытии файла осуществляется поиск по этой таблице соответствующего индексного узла, и после этого в памяти аккумулируется только индексный узел открытого файла, а не вся таблица. Достоинства: нет необходимости в размещении в ОЗУ информации всей FAT о все файлах системы, в памяти размещаются атрибуты, связанные только с открытыми файлами. Недостатки: размер файла и размер индексного узла (в общем случае прийти к размерам таблицы размещения). Решение: – ограничение размера файла – иерархическая организация индексных узлов Модели организации каталогов Каталог, кот. Представлен в виде таблицы: 1.Первая модель – простейший каталог. Каталог представляется в виде таблицы, которая содержит имя файла и его атрибуты. Соответственно каждая запись фиксированного размера. Проблема в том, что в этом случае каталог получается достаточно большой по объему, т.к. последовательность атрибутов может быть достаточно большой, в частности, в атрибуты может включаться и информация о размещении файла, о проблемах возникающих в таких случаях только что уже говорилось «-» каталог очень большой по объему. 2. Каталог содержит имя файла – поле фиксированного размера, и ссылку уже на системные структуры данных или системную структуру данных, в которых находятся атрибуты соответствующих файлов. В этом случае получается более менее гибкую организацию по части размера атрибутов (они здесь могут быть достаточно произвольной длины. «+» более гибкая организация по размеру атрибутов. Оба вида основаны на фиксированном размере записи каталога, есть ограничения на длину имени. Проблема длинных имен: короткие неудобны – размещаем суффиксы имени в атрибутах. Варианты соответствия: имя файла – содержимое файла Содержимому любого файла соответствует единственное имя файла. 1. Исторически было взаимно однозначное соответствие между именем и содержимым файла. Т.е. для каждого содержимого файла существовало единственное имя файла и для каждого зарегистрированного файла в ФС существовало единственное содержимое. Примеры: Содержимому файла может соответствовать два и более имен файла. 2. . В этом случае имя файла выносится на некоторый отдельный уровень из атрибутов, и получается, что есть содержимое файла, есть атрибут файла и может быть произвольное количество имен. Более того, эти имена могут размещаться в различных каталогах, если есть иерархическая ФС. Т.е. тем самым нарушается древообразность ФС “Жесткая” связь Для одного и того же содержимого файла может существовать>= 2 имен файла. Имя файла выносим из атрибутов. Есть содержимое файла, атрибуты и любое количество имен. |