Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 29)

#include <sys/types.h>

#include <sys/socket.h>

int bind(int sockfd, struct sockaddr *myaddr, int addrlen);

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

#include <sys/un.h>

struct sockaddr_un

{

short sun_family; /* == AF_UNIX */

char sun_path[108];

};

Первое поле в данной структуре — это код коммуникационного домена, а второе поле — это полное имя. Для домена AF_INET структура выглядит несколько иначе:

#include <netinet/in.h>

struct sockaddr_in

{

short sin_family; /* == AF_INET */

u_short sin_port; /* номер порта */

struct in_addr sin_addr; /* IP-адрес хоста */

char sin_zero[8]; /* не используется */

};

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

И, наконец, последний аргумент addrlen рассматриваемого системного вызова характеризует размер структуры второго аргумента (т.е. размер структуры sockaddr).

В случае успешного завершения данный вызов возвращает значение 0, иначе — -1.

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

1. Схема работы с сокетами с предварительным установлением соединения.

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

Каждый клиентский процесс создает свой сокет. Заметим, что на стороне клиента связывать сокет необязательно (поскольку сервер может работать с любым клиентом, в частности, и с «анонимным» клиентом). Затем клиентский процесс может передать серверному процессу сообщение, что он с ним хочет соединиться, т.е. передать запрос на соединение (посредством системного вызова connect()). В данном случае возможны три альтернативы.

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

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

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

Итак, данная схема организована таким образом, что к одному серверному узлу может иметь множество соединений. Для организации этой модели имеется системный вызов accept(), который работает следующим образом. При обращении к данному системному вызову, если в очереди имеется необработанная заявка на соединение, создается новый локальный сокет, который связывается с клиентом. После этого клиент может посылать сообщения серверу через этот новый сокет. А сервер, в свою очередь, получая через данный сокет сообщения от клиента, «понимает», от какого клиента пришло это сообщение (т.е. клиент получает некоторое внутрисистемное именование, даже если он не делал связывание своего сокета). И, соответственно, в этом случае сервер может посылать ответные сообщения клиенту.

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

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

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

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

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

Для посылки запроса на соединение используется системный вызов connect().

#include <sys/types.h>

#include <sys/socket.h>

int connect(int sockfd, struct sockaddr *serv_addr,

int addrlen);

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

В случае успешного завершения вызов возвращает значение 0, иначе возвращается -1, а в переменную errno заносится код ошибки.

Для перехода серверного процесса в режим прослушивания сокета используется системный вызов listen().

#include <sys/types.h>

#include <sys/socket.h>

int listen(int sockfd, int backlog);

Параметры вызова — дескриптор сокета и максимальный размер очереди необработанных запросов на соединение. В случае успешного завершения вызов возвращает значение 0, иначе возвращается -1, а в переменную errno заносится код ошибки.

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

#include <sys/types.h>

#include <sys/socket.h>

int accept (int sockfd, struct sockaddr *addr,

int *addrlen);

Первый параметр данной функции — дескриптор «главного» сокета. Второй параметр — указатель на структуру, в которой возвращается адрес клиентского сокета, с которым установлено соединение (если адрес клиента не интересует, передается NULL). В последнем параметре возвращается реальная длина упомянутой структуры.

Для модели с предварительным установлением соединения можно использовать системные вызовы чтения и записи в файл — соответственно, read() и write() (в качестве параметра этим функциям передается дескриптор сокета), а также системные вызовы send() (посылка сообщения) и recv() (прием сообщения).

#include <sys/types.h>

#include <sys/socket.h>

int send(int sockfd, const void *msg, int msglen,

unsigned int flags);

int recv(int sockfd, void *buf, int buflen, unsigned int flags);

Параметры: sockfd — дескриптор сокета, через который передаются данные; msg — указатель на начало сообщения; msglen — длина посылаемого сообщения; buf — указатель на буфер для приема сообщения; buflen — первоначальный размер буфера; и, наконец, параметр flags может содержать комбинацию специальных опций. Например:

• MSG_OOB — флаг сообщает ОС, что процесс хочет осуществить прием/передачу экстренных сообщений;

• MSG_PEEK — при вызове recv() процесс может прочитать порцию данных, не удаляя ее из сокета. Последующий вызов recv() вновь вернет те же самые данные.

Для организации приема и передачи сообщений в модели без предварительного установления соединения (Рис. 92.) используется пара системных вызовов sendto() и recvfrom().

#include <sys/types.h>

#include <sys/socket.h>

int sendto(int sockfd, const void *msg,

int msglen, unsigned int flags,

const struct sockaddr *to, int tolen);

int recvfrom(int sockfd, void *buf,

int buflen, unsigned int flags,

struct sockaddr *from, int *fromlen);

Первые четыре параметра каждого из вызовов имеют ту же семантику, что и параметры вызовов send() и recv() соответственно. Остальные параметры имеют следующий смысл: to — указатель на структуру, содержащую адрес получателя; tolen — размер структуры to; from — указатель на структуру с адресом отправителя; fromlen — размер структуры from.

1. Схема работы с сокетами без предварительного установления соединения.

Для завершения работы с сокетом используется системный вызов shutdown().

#include <sys/types.h>

#include <sys/socket.h>

int shutdown (int sockfd, int mode);

Первый параметр — дескриптор сокета, второй — режим закрытия соединения:

• 0 — сокет закрывается для чтения;

• 1 — сокет закрывается для записи;

• 2 — сокет закрывается и для чтения, и для записи.

Для закрытия сокета используется системный вызов close(), в котором в качестве параметра передается дескриптор сокета.

4Файловые системы

4.1Основные концепции

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

Характеристики

Список файлов лекций