2.2.5 Файлы /etc/services и /etc/hosts

Очевидно, что использование в процессе сетевого обмена с помощью протоколов стека протоколов TCP/IP IP-адресов, состоящих из обезличенного набора чисел, не удобно с практической точки зрения. Точно так же, как и портам, IP-адресам можно присваивать символьные псевдонимы (символьные адреса). Широкоприменяемым способом трансляции символьных имен в соответствующие IP-адреса является использование DNS-серве-ров, что будем именовать динамической трансляцией. Статической трансляцией можно считать сопоставление символьным именам IP-адресов с помощью файла /etc/hosts.

Одним из способов создания символьных псевдонимов для целевых IP-адресов является, очевидно, редактирование файла /etc/hosts. Этот способ работает только в той вычислительной системе, файл /etc/hosts которой был отредактирован. Для редактирования файла /etc/hosts необходимы права суперпользователя.

2.2.6 Протокол udp

User Datagram Protocol (UDP) - протокол, не обеспечивающий гарантированную доставку данных с сохранением порядка отправления блоков данных. Передача данных по протоколу UDP осуществляется с помощью дейтаграмм, вследствие чего снижается общий объем пересылаемого трафика в надежных сетях по сравнению с протоколом TCP, так как виртуальный канал, создаваемый протоколом TCP, обеспечивается пересылкой различного рода служебных пакетов.

Структура заголовка пакета протокола UDP:

Source port

Destination port

Length

Checksum

Data

«Source port» - UDP-порт соответствующего сетевого интерфейса, через который процесс - отправитель посылает дейтаграмму;

«Destination port» - UDP-порт назначения соответствующего сетевого интерфейса удаленного сетевого узла. Процесс - получатель прослушивает данный порт в ожидании получения дейтаграммы;

«Length» - длина UDP-пакета в байтах;

«Checksum» - контрольная сумма пакета.

Поле «Data» содержит информацию, передаваемую процессом - отправителем UDP-пакета процессу - получателю UDP-пакета.

2.2.7 Программирование сетевого обмена с использованием протоколов udp и tcp

В программах на языке программирования C в ОС GNU/Linux для работы с протоколом UDP удобно использовать UDP-сокеты. Процесс обмена с использованием UDP-протокола в программах на языке C в ОС GNU/Linux выглядит следующим образом:

а) Создание сокета.

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

1) Идентификатор семейства протоколов, один из протоколов которого используется.

Возможные значения идентификатора семейства протоколов:

• AF_INET - стек протоколов TCP/IPv4;

• AF_UNIX и AF_LOCAL - протокол межпроцессной коммуникации между процессами одной операционной системы;

• AF_NETLINK - протокол межпроцессной коммуникации между процессами пользовательского пространства и процессами пространства ядра одной операционной системы;

• AF_PACKET - протоколы канального уровня сетевой модели OSI и некоторые протоколы сетевых уровней различных семейств протоколов;

• AF_X25, AF_AX25, AF_ATMPVC и AF_APPLETALK.

Для использования протокола UDP системному вызову socket необходимо передать первым параметром значение константы AF_NET;

2) Идентификатор режима передачи пакетов.

Возможные значения идентификатора режима передачи пакетов:

• SOCK_STREAM - режим с организацией виртуального канала;

• SOCK_DGRAM - режим с использованием дейтаграмм;

• SOCK_RAW - «сырые» сокеты. Программа получает доступ к заголовку пакета (то есть самостоятельно формирует заголовок при отправлении пакетов и получает заголовок в результирующем буфере при получении пакетов) и, следовательно, должна самостоятельно организовывать соответствующий режим передачи пакетов;

- SOCK_RDM, SOCK_SEQPACKET - вариации режима с использованием дейтаграмм;

- SOCK_PACKET - не рекомендующийся к использованию синоним AF_PACKET.

Для использования протокола UDP системному вызову socket необходимо передать вторым параметром значение константы SOCK_DGRAM;

3) Идентификатор протокола сетевого взаимодействия, сокет для использования которого создается.

Данный идентификатор может быть получен следующими способами:

• С помощью безымянного объединения (enum), описанного в заголовочном файле <linux/in.h>;

• С помощью файла /etc/protocols;

• С помощью функции getprotobyname() библиотеки GLIBC¹.

В данной лабораторной работе для использования протокола UDP в качестве третьего параметра системному вызову socket необходимо передать значение IPPROTO_UDP безымянного объединения, описанного в заголовочном файле <linux/in.h>.

Таким образом, для создания UDP-сокета процесс должен выполнить системный вызов socket с параметрам AF_INET, SOCK_DGRAM и IPPROTO_UDP.

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

Библиотека GLIBC предоставляет обертку для данного системного вызова, для использования которой необходимо включить в файл исходного кода программы заголовочные файлы <sys/types.h> и <sys/socket.h>;

б) Запись данных в сокет (отправление данных процессу удаленного сетевого узла).

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

1) Номер дескриптора сокета в таблице файловых дескрипторов процесса;

¹Функция getprotobyname оперирует, в конечном счете, файлом /etc/protocols.

2) Указатель на буфер, в который помещено содержимое поля «Data» отправ-ляемого пакета;

3) Размер в байтах поля «Data» отправляемого пакета (не превышает размер

буфера);

4) Флаги.

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

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

5) Адрес целевого сетевого узла.

Данный параметр суть есть указатель на экземпляр структуры данных sockaddr. В случае использования IPv4-адресации сетевых узлов в качестве указателя на экземпляр структуры данных sockaddr передается указатель на экземпляр структуры данных sockaddr_in. Указатель на экземпляр структуры данных sockaddr_in явно приводится к указателю на экземпляр структуры данных sockaddr.

Структура данных sockaddr_in состоит из следующих полей:

• sin_family - идентификатор используемого семейства протоколов (должно быть установлено в AF_INET);

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

Номер порта записывается в сетевом порядке байт.

^хКод ошибки - EWOULDBLOCK, сохраняемый в переменной errno, определенной в заголовочном файле <errno.h>.

Для приведения номера порта к сетевому порядку байт необходимо воспользоваться функцией htons() библиотеки GLIBC, определенной в заголовочном файле <arpa/inet.h>, принимающей единственным параметром 16-ти битовое целое беззнаковое число - номер порта в порядке байт хоста, и возвращающей 16-ти битовое целое беззнаковое число - номер порта в сетевом порядке байт;

- sin_addr - Ш^^-адрес целевого узла сети, записанный в сетевом порядке байт.

Для преобразования Ш^^-адреса, записанного в стандартной нотации (чис-ло.число.число.число) и сохраненного в строке, в соответствие этого адреса, записанное в беззнаковом целом с использованием сетевого порядка байт, используется функция inet_addr() библиотеки GLIBC. Для использование означенной функции в программе в файл исходного кода программы необходимо включить заголовочные файлы <sys/socket.h>, <netinet/in.h> и <arpa/inet.h>. Функция inet_addr() принимает единственным параметром строку с Ш^^-адресом целевого узла сети и возвращает значение типа in_addr_t. Значение in_addr_t должно быть записано в поле sin_addr.s_addr;

6) Размер в байтах описателя адреса целевого сетевого узла.

В данном случае в качестве значения данного параметра передается sizeof(struct sockaddr_in).

Системный вызов sendto возвращает количество отправленных байт из буфера buf (значение типа ssize_t, что соответствует целому знаковому числу) в случае своего успешного выполнения и -1 в случае неудачи.

Библиотека GLIBC предоставляет обертку для данного системного вызова, для использования которой необходимо включить в файл исходного кода программы заголовочные файлы <sys/types.h> и <sys/socket.h>;

в) Чтение данных из сокета (получение данных от процесса удаленного сетевого узла).

Для получения данных от процесса удаленного сетевого узла в случае протоколов TCP и UDP удобно пользоваться системным вызовом recv, принимающим следующие параметры:

1. Номер дескриптора сокета в таблице файловых дескрипторов процесса;

2. Указатель на буфер, в который будет помещено содержимое поля «Data» принимаемого пакета;

3. Максимально допустимый размер в байтах поля «Data» принимаемого пакета (не превышает размер буфера);

4. Флаги.

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

В случае протокола UDP процессу - получателю может потребоваться определить IP-адрес удаленного сетевого узла, на котором запущен процесс - отправитель, и номер порта соответствующего сетевого интерфейса, с которого процесс - отправитель отправил полученную дейтаграмму. Для одновременных считывания содержимого поля «Data» полученного пакета и определения IP-адреса удаленного сетевого узла и соответствующего номера порта соответствующего сетевого интерфейса удаленного сетевого узла процесс может воспользоваться системным вызовом recvfrom. Системный вызов recvfrom принимает те же параметры, что и системный вызов recv, а также два дополнительных параметра:

1) Указатель на экземпляр структуры данных sockaddr_in, в который будетпомещен IP-адрес удаленного сетевого узла и номер порта соответствующе-го сетевого интерфейса, с которого процесс - отправитель отправил дейта-грамму.

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

Для получения представления IP-адреса в стандартной нотации в виде текстовой строки можно воспользоваться функцией inet_ntoa() библиотеки GLIBC, единственным параметром в которую необходимо передать значение поля sin_addr экземпляра структуры данных sockaddr_in. Функция inet_ntoa() возвращает указатель на строку, содержащую представление IP-адреса в стандартной нотации. Для использования функции inet_ntoa() в файл исходного кода программы необходимо включить заголовочные файлы <sys/socket.h> и <netinet/in.h>.

Для преобразования номера порта из сетевого порядка байт в порядок байт хоста можно воспользоваться функцией ntohs() библиотеки GLIBC, единственным параметром в которую необходимо передать номер порта, записанный в сетевом порядке байт. Функция ntohs() возвращает номер порта, записанный в порядке байт хоста. Для использования функции ntohs() в файл исходного кода программы необходимо включить заголовочный файл <arpa/inet.h>;

2) Указатель на целочисленную переменную типа socklen_t, в которой будетсохранен размер в байтах экземпляра структуры данных sockaddr_in.

Системные вызовы recv и recvfrom возвращают количество полученных байт (значение типа ssize_t, что соответствует целому знаковому числу) в случае своего успешного выполнения и -1 в случае неудачи.

Библиотека GLIBC предоставляет обертки для данных системных вызовов, для использования которых необходимо включить в файл исходного кода программы заголовочные файлы <sys/types.h> и <sys/socket.h>;

г) Уничтожение сокета.

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

Библиотека GLIBC предоставляет обертку для данного системного вызова, для использования которой необходимо включить в файл исходного кода программы заголовочный файл <unistd.h>.

Протокол TCP

Transmission Control Protocol (TCP) - протокол, обеспечивающий гарантированную доставку данных с сохранением порядка отправления блоков данных за счет создания виртуального канала передачи данных.

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

а) Процесс - сервер занимает некоторый TCP-порт своего сетевого интерфейса иначинает прослушивать данный порт в ожидании поступления запроса на установсоединения от процесса - клиента;

б) Процесс - клиент занимает TCP-порт своего сетевого интерфейса и отправляетчерез данный порт процессу - серверу запрос на установ соединения;

в) Процесс - сервер принимает решение: возможен ли установ соединения? Если про-цесс - сервер решил установить соединение, то он занимает отдельный TCP-портсвоего сетевого интерфейса и начинает обмен данными с процессом - клиентом;

г) Процесс - клиент в случае, если процесс - сервер подтвердил установ соединения,начинает обмен данными с процессом - сервером;

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

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

На программном уровне обмен между процессами по протоколу TCP организуется с помощью TCP-сокетов.

Процесс - сервер работает по следующему алгоритму:

а) Создание сокета.

Для создания сокета необходимо использовать системный вызов socket, описанный ранее при рассмотрении протокола UDP, и принимающий, в случае протокола TCP, следующие значения параметров:

1. Идентификатор семейства протоколов - AF_INET, что соответствует стеку протоколов TCP/IPv4;

2. Идентификатор режима передачи пакетов - SOCK_STREAM, что соответствует передаче пакетов через виртуальный канал;

3. Идентификатор протокола сетевого взаимодействия - IPPROTO_TCP, описанный в заголовочном файле <linux/in.h>;

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

Привязка сокета к порту осуществляется с помощью системного вызова bind, имеющего следующие параметры:

1. Номер дескриптора сокета в таблице файловых дескрипторов процесса;

2. Адрес целевого сетевого интерфейса и номер занимаемого порта целевого сетевого интерфейса.

Данный параметр суть есть указатель на экземпляр структуры данных sockaddr. В случае использования IPv4-адресации сетевых узлов в качестве указателя на экземпляр структуры данных sockaddr системному вызову bind передается указатель на экземпляр структуры данных sockaddr_in. Указатель на экземпляр структуры данных sockaddr_in явно приводится к указателю на экземпляр структуры данных sockaddr.

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

3) Размер в байтах описателя адреса целевого сетевого интерфейса.

В данном случае в качестве значения данного параметра передается sizeof(struct sockaddr_in).

Системный вызов bind возвращает 0 в случае успешной привязки сокета к порту и -1 в случае неудачного завершения означенной операции.

Библиотека GLIBC предоставляет обертку для данного системного вызова, для использования которой необходимо включить в файл исходного кода программы заголовочные файлы <sys/types.h> и <sys/socket.h>;

в) Перевод сокета в режим прослушивания порта.

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

1. Номер дескриптора сокета в таблице файловых дескрипторов процесса;

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

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

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

Системный вызов listen возвращает 0 в случае успешного перевода сокета в режим прослушивания порта и -1 в случае неудачного завершения означенной операции.

Библиотека GLIBC предоставляет обертку для данного системного вызова, для использования которой необходимо включить в файл исходного кода программы заголовочные файлы <sys/types.h> и <sys/socket.h>;

г) Установ соединения с очередным процессом - клиентом.

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

1. Номер дескриптора сокета в таблице файловых дескрипторов процесса;

2. Указатель на описатель адреса сетевого узла.

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

Необходимо помнить, что IP-адрес и номер порта в экземпляре структуры данных sockaddr_in хранятся в сетевом порядке байт. Для преобразования IP-адреса в строковое представление в стандартной нотации и для преобразования номера порта из сетевого порядка байт в порядок байт хоста необходимо воспользоваться функциями inet_ntoa() и ntohs() соответственно. Данные функции были описаны ранее.

Допускается передача значения NULL в качестве значения указателя на описатель адреса сетевого узла;

3) Указатель на целочисленную переменную типа socklen_t, в которой будет сохранен размер в байтах описателя адреса сетевого узла.

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

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

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

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

Библиотека GLIBC предоставляет обертки для данных системных вызовов, для использования которых необходимо включить в файл исходного кода программы заголовочные файлы <sys/types.h> и <sys/socket.h>. Для использования обертки к системному вызову accept4 в файле исходного кода программы перед включением в означенный файл заголовочного файла <sys/socket.h> необходимо определить константу компилятора «_GNU_SOURCE» с помощью директивы «#define» препроцессора;

д) Запись данных в сокет (отправление данных процессу удаленного сетевого узла).

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

1. Номер дескриптора сокета в таблице файловых дескрипторов процесса;

1. Указатель на буфер, в который помещено содержимое поля «Data» отправляемого пакета;

переменная errno, определенная в заголовочном файле <errno.h>, будет установлена в значение кода

ошибки EWOULDBLOCK.

3) Размер в байтах поля «Data» отправляемого пакета (не превышает размер

буфера);

4) Флаги.

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

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

Системный вызов send возвращает количество отправленных байт из буфера buf (значение типа ssize_t, что соответствует целому знаковому числу) в случае своего успешного выполнения и -1 в случае неудачи.

Библиотека GLIBC предоставляет обертку для данного системного вызова, для использования которой необходимо включить в файл исходного кода программы заголовочные файлы <sys/types.h> и <sys/socket.h>;

е) Чтение данных из сокета (получение данных от процесса удаленного сетевого узла).

Для чтения данных из сокета процесс - сервер может воспользоваться системным вызовом recv, описанным ранее при рассмотрении протокола UDP;

ж) Уничтожение сокета.

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

¹Код ошибки - EWOULDBLOCK, сохраняемый в переменной errno, определенной в заголовочном файле <errno.h>.

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

Библиотека GLIBC предоставляет обертку для данного системного вызова, для использования которой необходимо включить в файл исходного кода программы заголовочный файл <unistd.h>.

Процесс - клиент работает по следующему алгоритму:

а) Создание сокета.

Для создания сокета необходимо использовать системный вызов socket, описанный ранее при рассмотрении протокола UDP, и принимающий, в случае протокола TCP, значения параметров, перечисленные при рассмотрении алгоритма работы процесса - сервера;

б) Установ соединения с процессом - сервером.

Для установа соединения с процессом - сервером процесс - клиент может воспользоваться системным вызовом connect, принимающим следующие параметры:

• Номер дескриптора сокета в таблице файловых дескрипторов процесса;

• Адрес целевого сетевого узла и номер прослушиваемого процессом - сервером порта соответствующего сетевого интерфейса целевого сетевого узла.

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

- Размер в байтах экземпляра структуры данных sockaddr_in, равный sizeof(struct sockaddr_in).

Системный вызов connect производит запрос на подключение процесса - клиента к процессу - серверу и блокируется в ожидании удовлетворения запроса или удаления запроса из очереди запросов на подключение процесса - сервера. В случае удовлетворения запроса на подключение системный вызов connect возвращает 0, в противном случае системный вызов connect возвращает -1.

Библиотека GLIBC предоставляет обертку для данного системного вызова, для использования которой необходимо включить в файл исходного кода программы заголовочные файлы <sys/types.h> и <sys/socket.h>;

в) Запись данных в сокет (отправление данных процессу удаленного сетевого узла).

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

г) Чтение данных из сокета (получение данных от процесса удаленного сетевого уз-ла).

Для чтения данных из сокета процесс - клиент может воспользоваться системным вызовом recv, описанным ранее при рассмотрении протокола UDP;

д) Уничтожение сокета.

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

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

Библиотека GLIBC предоставляет обертку для данного системного вызова, для использования которой необходимо включить в файл исходного кода программы заголовочный файл <unistd.h>.

Практическая часть

Предварительная подготовка

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

Утилиты netstat и ncat. Файлы /etc/protocols и /etc/hosts

Необходимо выполнить следующие задания:

а) Запустить TCP-сервер на периферийном сетевом узле 10.0.1.128;

б) Запустить TCP-сервер на центральном сетевом узле;

в) Выполнить подключения к TCP-серверам, работающим на центральном сетевомузле и периферийном сетевом узле 10.0.1.128, с периферийного сетевого узла10.0.2.128 и центрального сетевого узла соответственно;

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

д) Получить список всех TCP-портов центрального сетевого узла, прослушиваемыхпроцессами - серверами, запущенными на центральном сетевом узле;

е) Получить список всех TCP-портов периферийного сетевого узла 10.0.2.128, про-слушиваемых процессами - серверами, запущенными на периферийном сетевом

узле 10.0.2.128;

ж) Завершить выполнение TCP-серверов, работающих на центральном сетевом узле и периферийном сетевом узле 10.0.1.128;

з) Добавить для центрального сетевого узла символьные псевдонимы для IP-адресовобоих периферийных сетевых узлов.

Псевдонимы должны быть образованы от порядкового номера студента в журнале группы следующим образом: «lab-2-N-host-M», где N - порядковый номер студента в журнале группы, M - порядковый номер периферийного сетевого узла;

и) Проверить доступность центральному сетевому узлу периферийного сетевого узла10.0.1.128 с помощью утилиты ping, пример использования которой был приведенв первой лабораторной работе.

При проверки доступности центральному сетевому узлу периферийного сетевого узла 10.0.1.128 необходимо использовать символьный псевдоним IP-адреса периферийного сетевого узла 10.0.1.128;

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

«lab-2-N-port-Q» портов с номерами Q₁ и Q₂, где Q = 1 или 2, Q₁ = 50070 + (N mod 6 + 1) * 10, Q2 = Qi + 1;

л) Запустить TCP-сервер на периферийном сетевом узле 10.0.2.128 на Q₁-м порту;

м) Запустить TCP-сервер на центральном сетевом узле на порту;

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

Для подключения к периферийному сетевому узлу 10.0.2.128 необходимо использовать символьный псевдоним IP-адреса данного сетевого узла;

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

п) Получить список всех TCP-портов центрального сетевого узла, прослушиваемых процессами - серверами, запущенными на центральном сетевом узле;

р) Удалить добавленные в ходе выполнения лабораторной работы символьные псевдонимы IP-адресов периферийных сетевых узлов и символьные псевдонимы TCP-портов центрального сетевого узла.

Сетевое программирование с использованием протоколов TCP и UDP

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

- Серверная компонента, запускаемая на периферийном сетевом узле 10.0.1.128, и выполняющая команды, передаваемые ей управляющей компонентой по протоколу UDP.

После выполнения очередной команды серверная компонента должна выводить соответствующее сообщение в стандартный поток вывода;

- Серверная компонента, запускаемая на периферийном сетевом узле 10.0.2.128, и выполняющая команды, передаваемые ей управляющей компонентой по протоколу TCP;

После выполнения очередной команды серверная компонента должна выводить соответствующее сообщение в стандартный поток вывода;

- Управляющая компонента, запускаемая на центральном сетевом узле.

Управляющая компонента должна выполнять обмен с серверными компонентами по указанным протоколам в соответствии с командами оператора, должна получать сообщения о результатах выполнения команд и выводить соответствующие сообщения в стандартный поток вывода;

б) Запустить серверные компоненты на периферийных сетевых узлах 10.0.1.128 и

10.0.2.128;

в) Запустить управляющую компоненту на центральном сетевом узле;

г) Продемонстрировать функционирование программного комплекса в соответствиис указаниями преподавателя;

д) Завершить функционирование серверных компонент программного комплекса пополучению управляющей компонентой соответствующей команды от оператора;

е) Завершить выполнение управляющей компоненты программного комплекса.

Управляющая компонента разрабатываемого программного комплекса должна принимать следующие команды оператора центрального сетевого узла:

• «halt» - команда завершения выполнения всех компонент программного комплекса;

• «ping NODE» - команда запроса ответа от серверной компоненты периферийного узла с номером NODE. Серверная компонента должна незамедлительно ответить произвольным ответным сообщением, факт получения которого должен быть зафиксирован управляющей компонентой выводом соответствующего сообщения в стандартный поток вывода;

• «rand» - запрос у обоих серверных компонент случайного 32-х битового целого числа. После получения случайных чисел управляющая компонента должна выполнить над ними операцию побитового исключающего и, результат которой управляющая компонента должна вывести в стандартный поток вывода;

• «stat» - вывод статистической информации о количестве выполненных управляющей компонентой команд.

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

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

Подготовка отчета по лабораторной работе

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

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

защита отчета по лабораторной работе

Одно из следующих заданий может быть предложено в качестве задания для защиты отчета по лабораторной работе:

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

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

в) Добавление функционала обработки управляющей компонентой одной из следую-щих команд:

• «get NODE FILE_IN FILE_OUT» - команда запроса у серверной компоненты, запущенной на периферийном сетевом узле с номером NODE, содержимого файла FILE_IN и сохранение полученной информации на центральном сетевом узле в файле FILE_OUT;

• «put NODE FILE_IN FILE_OUT» - копирование файла FILE_IN центрального сетевого узла в файл FILE_OUT периферийного сетевого узла с номером NODE;

- «route NODE» - запрос у серверной компоненты, функционирующей на периферийном сетевом узле с номером NODE, таблицы маршрутизации данного периферийного сетевого узла;

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

д) Добавление поддержки симметричного шифрования данных, пересылаемых меж-ду серверными и управляющей компонентами.

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

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

21