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

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

После такого обмена протокол TCP хоста A уверен, что удаленный протокол работает и готов к получению данных. Как только устанавливается это соединение, можно обмениваться данными. Когда протоколы решат завершить обмен, они опять обмениваются сегментами с установленным биом “Нет больше данных для передачи” (FIN, “No more data from sender”). Таким образом они закрывают соединение. Весь этот обмен (до и после передачи данных) необходим для логического соединения между двумя системами.

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

8.3.4.3Сравнение протоколов TCP и UDP

Зачем в TCP/IP два базовых протокола транспортного уровня?

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

8.3.5Уровень прикладных программ

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

8.3.5.1Протоколы, опирающиеся на TCP

TELNET (Network Terminal Protocol), Протокол сетевого терминала, разработан для удаленного доступа к компьютерам сети (remote login).

FTP (File Transfer Protocol), Протокол передачи файлов, используется для интерактивной передачи файлов между компьютерами сети.

SMTP (Simple Mail Transfer Protocol), Простой протокол передачи почты. Основной протокол для обмена почтой, использующийся в Internet.

8.3.5.2Протоколы, опирающиеся на UDP

DNS (Domain Name Service), Служба имен доменов, или просто Служба именования. С помощью этого протокола устанавливается взаимно однозначное соответствие между IP-адресами сетевых устройств и их именами. Об этом протоколе и о системе именования вообще речь пойдет дальше.

RIP (Routing Information Protocol), Протокол информации о маршрутизации. Маршрутизация данных (поиск путей их передачи от хоста-отправителя к хосту-получателю) в Internet является одной из важнейших функций семейства протоколов

TCP/IP. RIP используется сетевыми устройствами для обмена информацией о маршрутизации. Маршрутизация тоже будет подробно рассмотрена дальше.

NFS (Network File System), сетевая файловая система. С помощью этого протокола компьютеры могут совместно использовать файлы, разбросанные по сети.

9Средства взаимодействия процессов в сети.

9.1Сокеты.

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

Обозначенные проблемы был призван решить механизм, впервые появившийся в Берклиевском UNIX – BSD, начиная с версии 4.2, и названный сокетами (sockets). Ниже подробно рассмотривается этот механизм.

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

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

9.1.1Типы сокетов. Коммуникационный домен.

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

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

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

Поскольку сокеты могут использоваться как для локального, так и для удаленного взаимодействия, встает вопрос о пространстве адресов сокетов. При создании сокета указывается т.н. коммуникационный домен, к которому данный сокет будет принадлежать. Коммуникационный домен определяет форматы адресов и правила их интерпретации. Мы будем рассматривать два основных домена: для локального взаимодействия – домен AF_UNIX и для взаимодействия в рамках сети – домен AF_INET (префикс AF обозначает сокращение от address family – семейство адресов). В домене AF_UNIX формат адреса – это допустимое имя файла, в домене AF_INET адрес образуют имя хоста + номер порта.

Заметим, что фактически коммуникационный домен определяет также используемые семейства протоколов. Так, для домена AF_UNIX это будут внутренние протоколы ОС, для домена AF_INET – протоколы семейства TCP/IP. BSD UNIX поддерживает также третий домен – AF_NS, использующий протоколы удаленного взаимодействия Xerox NS, но мы его рассматривать не будем.

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

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

#include <sys/types.h>

#include <sys/socket.h>

int socket (int domain, int type, int protocol)

Функция создания сокета так и называется – socket(). У нее имеется три аргумента. Первый аргумент – domain – обозначает коммуникационный домен, к которому должен принадлежать создаваемый сокет. Для двух рассмотренных нами доменов соответствующие константы будут равны, как мы уже говорили, AF_UNIX и AF_INET. Второй аргумент – type – определяет тип соединения, которым будет пользоваться сокет (и, соответственно, тип сокета). Для двух основных рассматриваемых нами типов сокетов это будут константы SOCK_STREAM для соединения с установлением виртуального канала и SOCK_DGRAM для датаграмм⁴. Третий аргумент – protocol – задает конкретный протокол, который будет использоваться в рамках данного коммуникационного домена для создания соединения. Если установить значение данного аргумента в 0, система автоматически выберет подходящий протокол. В наших примерах мы так и будем поступать. Однако здесь для справки приведем константы для протоколов, используемых в домене AF_INET:

IPPROTO_TCP – обозначает протокол TCP (корректно при создании сокета типа SOCK_STREAM)

IPPROTO_UDP – обозначает протокол UDP (корректно при создании сокета типа SOCK_DGRAM)

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

9.1.3Связывание.

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

#include <sys/types.h>

#include <sys/socket.h>

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

Первый аргумент функции – дескриптор сокета, возвращенный функцией socket(); второй аргумент – указатель на структуру, содержащую адрес сокета. Для домена AF_UNIX формат структуры описан в <sys/un.h> и выглядит следующим образом:

#include <sys/un.h>

struct sockaddr_un {

short sun_family; /* == AF_UNIX */

char sun_path[108];

};

Для домена AF_INET формат структуры описан в <netinet/in.h> и выглядит следующим образом:

#include <netinet/in.h>

struct sockaddr_in {

short sin_family; /* == AF_INET */

u_short sin_port; /* port number */

struct in_addr sin_addr; /* host IP address */

char sin_zero[8]; /* not used */

};

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

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