WWW.DISUS.RU

БЕСПЛАТНАЯ НАУЧНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА - Авторефераты, диссертации, методички

 

Pages:     || 2 | 3 |

«Е. Д. Жиганов А. П. Мощевикин Передача данных в компьютерных сетях Учебное пособие Петрозаводск Издательство ПетрГУ 2007 УДК 681.324 ББК 32.973.202 Ж68 Печатается по решению редакционно-издательского совета ...»

-- [ Страница 1 ] --

Федеральное агентство по образованию

Государственное образовательное учреждение

высшего профессионального образования

ПЕТРОЗАВОДСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

Е. Д. Жиганов

А. П. Мощевикин

Передача данных

в компьютерных сетях

Учебное пособие

Петрозаводск

Издательство ПетрГУ

2007

УДК 681.324 ББК 32.973.202 Ж68 Печатается по решению редакционно-издательского совета Петрозаводского государственного университета Рецензенты:

канд. т. н., ст. преподаватель Ю. В. Сидоров ст. преподаватель А. В. Соловьев CCNA сертифицированный инженер А. А. Корольков Жиганов, Е. Д.

Ж68 Передача данных в компьютерных сетях : учеб. пособие / Е. Д. Жиганов, А. П. Мощевикин. – Петрозаводск : Изд-во ПетрГУ, 2007. – 156 с.

ISBN 978-5-8021-0632- Учебное пособие предназначено для сопровождения лабораторного практикума по курсам, связанным с изучением сетевых технологий передачи данных и программированием сетевых интерфейсов. В издании приведены краткие сведения и справочные данные по некоторым сетевым технологиям, протоколам и утилитам, используемым в локальных и глобальных сетях, описаны способы создания сетевых приложений в Unix-подобных операционных системах; содержатся методические рекомендации и тексты заданий к лабораторным работам.

Пособие адресовано студентам физико-технического факультета, обучающимся по специальностям "Автоматизированные системы обработки информации и управления", "Информационно-измерительная техника и технологии", "Физическая электроника" и изучающим курсы "Сети ЭВМ и телекоммуникации" и "Сетевые технологии".

УДК 681. ББК 32.973. © Петрозаводский государственный ISBN 978-5-8021-0632-7 университет, Содержание ПРЕДИСЛОВИЕ

ЧАСТЬ I СЕТЕВЫЕ ТЕХНОЛОГИИ,

ПРОТОКОЛЫ, УТИЛИТЫ

ГЛАВА 1. ВВЕДЕНИЕ В КОНЦЕПЦИЮ OSI/RM, СТЕК ПРОТОКОЛОВ

1.1. Open System Interconnection Reference Model

1.2. Структура сетевых пакетов

ГЛАВА 2. ТЕХНОЛОГИЯ ETHERNET

2.1. Алгоритм CSMA/CD

2.2. Формат кадра Ethernet

2.3. Promiscuous mode (режим прослушивания сети)

ГЛАВА 3. ПРОТОКОЛЫ СТЕКА TCP/IP И ПРИКЛАДНОГО УРОВНЯ

3.1. Межсетевой протокол IP (Internet Protocol)

3.2. Протокол UDP (User Datagram Protocol)

3.3. Протокол TCP (Transmission Control Protocol)

3.4. Протокол ICMP (Internet Control Message Protocol)

3.5. Протоколы ARP и RARP (Address Resolution Protoco и Reversed ARP)

3.6. Процесс отправки, перенаправления и получения датаграмм

3.7. Установление и разрыв TCP-соединения

3.8. Hyper Text Transfer Protocol (HTTP)

3.9. Simple Mail Transfer Protocol (SMTP)

ГЛАВА 4. СРЕДСТВА И УТИЛИТЫ СЕТЕВОГО ТЕСТИРОВАНИЯ

4.1. ping

4.2. traceroute (tracert)

4.3. netstat

4.4. tcpdump

ЧАСТЬ II РАЗРАБОТКА СЕТЕВЫХ ПРИЛОЖЕНИЙ

В СРЕДЕ ОС UNIX

ГЛАВА 5. ОСНОВНЫЕ КОНЦЕПЦИИ ОРГАНИЗАЦИИ ВВОДА-ВЫВОДА И УПРАВЛЕНИЯ

ПРОЦЕССАМИ В ОС UNIX

5.1. Подсистема ввода-вывода в ОС UNIX

5.2. Подсистема управления процессами

5.3. Взаимосвязь подсистем ввода-вывода и управления процессами

ГЛАВА 6. СТРАТЕГИИ ОРГАНИЗАЦИИ ВВОДА-ВЫВОДА

В СРЕДЕ ОС UNIX

6.1. Многопроцессный подход

6.2. Мультиплексирование ввода-вывода в одном процессе

ГЛАВА 7. ПРИМЕРЫ ПРОГРАММ

7.1. Работа с процессами

7.2. Использование select() и poll()

7.3. Работа с сигналами

ГЛАВА 8. ТЕХНОЛОГИЯ КЛИЕНТ-СЕРВЕР

8.1. Архитектура "клиент-сервер"

8.2. Сетевой порядок байтов

8.3. Разработка программ-серверов

8.4. Пример программы-сервера

8.5. Разработка программ-клиентов

8.6. Работа с базами данных по узлам и службам сети Internet

8.7. Пример программы-клиента

ГЛАВА 9. НИЗКОУРОВНЕВЫЕ СОКЕТЫ И ПЕРЕХВАТ ПАКЕТОВ

9.1. Низкоуровневые сокеты

9.2. Перехват пакетов

ЧАСТЬ III ЛАБОРАТОРНЫЕ РАБОТЫ

ЛАБОРАТОРНАЯ РАБОТА №

ИЗУЧЕНИЕ ПРОТОКОЛА SMTP

(SIMPLE MAIL TRANSFER PROTOCOL)

ЛАБОРАТОРНАЯ РАБОТА №

ИЗУЧЕНИЕ ПРОТОКОЛА HTTP

(HYPER TEXT TRANSFER PROTOCOL)

ЛАБОРАТОРНАЯ РАБОТА №

ИССЛЕДОВАНИЕ КОНФИГУРАЦИИ СЕТИ УНИВЕРСИТЕТА

И КАРЕЛЬСКОГО СЕГМЕНТА РУНЕТА

ЛАБОРАТОРНАЯ РАБОТА №

ИССЛЕДОВАНИЕ ПРОПУСКНОЙ СПОСОБНОСТИ КОММУНИКАЦИОННОГО

ОБОРУДОВАНИЯ В СЕТЯХ ETHERNET

ЛАБОРАТОРНАЯ РАБОТА №

СЕТЕВОЕ ПРОГРАММИРОВАНИЕ

С ИСПОЛЬЗОВАНИЕМ RAW SOCKETS

ЛАБОРАТОРНАЯ РАБОТА №

АНАЛИЗАТОР СЕТЕВОГО ТРАФИКА

НА ОСНОВЕ БИБЛИОТЕКИ PCAP

ЛАБОРАТОРНАЯ РАБОТА №

ИЗУЧЕНИЕ ТЕХНОЛОГИИ КЛИЕНТ-СЕРВЕР

СПИСОК РЕКОМЕНДОВАННОЙ К ИЗУЧЕНИЮ ЛИТЕРАТУРЫ........ Предисловие Учебное пособие "Передача данных в компьютерных сетях" предназначено для студентов специальностей АСОИУ, ИИТТ, ФЭ и др., изучающих курсы "Сети ЭВМ и телекоммуникации" и "Сетевые технологии".

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

Издание подготовлено в рамках проекта "Научно-образовательный центр по фундаментальным проблемам приложений физики низкотемпературной плазмы" (RUX0-013-PZ-06), поддерживаемого Министерством образования и науки РФ, Американским фондом гражданских исследований и развития (CRDF) и Правительством Республики Карелия, а также программы Европейского Сообщества TACIS/Interreg.

Авторы выражают благодарность Л. Л. Пяхтину за сотрудничество при создании методических указаний к лабораторным работам № 5 и 6, Ю. В. Сидорову, А. В. Соловьеву и А. А. Королькову за рецензию, проверку текста и полезные рекомендации, а также И. М. Некрыловой за тщательную корректуру пособия.

ЧАСТЬ I

СЕТЕВЫЕ ТЕХНОЛОГИИ,

ПРОТОКОЛЫ, УТИЛИТЫ

Глава 1.

Введение в концепцию OSI/RM, стек протоколов В литературе по компьютерной и сетевой тематике слова "стандарт" и "протокол" упрощенно отражают принадлежность оборудования или программного обеспечения к тому или иному заранее определенному типу или классу. При этом задача классификации возложена на международные или национальные комитеты (консорциумы), которые фактически "законодательно" закрепляют пути развития техники и технологий. Как показывает опыт мирового экономического развития, на рынке выживают только компании, придерживающиеся этих законов, а выигрывает от этого именно потребитель. Единые стандарты порождают конкуренцию, облегчают изучение сходных по назначению продуктов технологического прогресса, позволяют заменять одни части и механизмы другими.

Простейшая вертикальная модель взаимодействия объектов в компьютерной архитектуре может быть описана так (сверху вниз):

прикладное программное обеспечение (ПО) пользователя;

операционная система;

драйверы;

аппаратура.

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

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

1.1. Open System Interconnection Reference Model Эталонная модель взаимодействия открытых систем (ЭМВОС, OSI/RM) предлагает несколько иную многоуровневую схему, именуемую стеком.

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

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

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

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

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

Канальный уровень чаще всего ответственен за формирование кадров (четко выдержанных по размеру многобайтовых структур), содержащих систему адресации (например, МАС-адрес1 источника, МАС-адрес назначения), поле управления и поле с данными более высокого уровня, сетевого. Канальный уровень разделен на два подуровня: нижний – MAC (Medium Access Control, управление доступом к среде) и верхний – LLC (Link Logical Control, логическое управление связью).

Сетевой уровень также имеет свою систему адресации (например, IPадресация), поле управления и поле данных более высокого уровня, транспортного. Таким образом, в каждом кадре информация транспортМАС – Medium Access Control (управление доступом к среде); MAC-адрес канального уровня состоит из 6 байтов; существуют три типа MAC-адресов (в зависимости от значения самого старшего байта): уникальный, групповой рассылки и широковещательный; чаще всего этот адрес аппаратно закреплен за оборудованием, по его значению можно определить производителя сетевого устройства.

ного уровня инкапсулирована в поле данных сетевого уровня, а информация сетевого уровня – в поле данных канального уровня.

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

Во-первых, благодаря сложной иерархической структуре сетевого адреса (деление всего адресного пространства на сети и подсети;

особенно ярко это выражено для сетей IPv6 с адресным пространством 2128 сетевых интерфейсов) резко снижаются требования к аппаратному обеспечению маршрутизаторов и упрощается их настройка (очень сложно установить правила перенаправления пакетов, не имея средств для логического или физического разделения оконечных устройств на группы). И во-вторых, становится возможным построение глобальных сетей на гетерогенной аппаратной основе (поверх разных устройств канального уровня). Так, операционную систему, поддерживающую стек TCP/IP, можно установить на компьютеры с сетевой платой стандарта Ethernet, аналоговым модемом, цифровым интерфейсом ISDN, платой коммутации стандарта ATM и т. д.

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

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

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

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

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

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

На сеансовом уровне лежит задача организации сеанса связи (по уже установленному "каналу" на четырех нижних уровнях модели OSI/RM);

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

Обращаясь к стеку TCP/IP2, действие процедур сеансового уровня можно продемонстрировать на примере установления TCP-соединения.

Для этого сторона-инициатор должна отправить по определенному IPадресу на определенный TCP-порт специальный пакет с выставленным флагом синхронизации SYN (synchronization). Удаленная сторона ответит на этот пакет другим пакетом с флагом ACK (acknowledgement), подтверждающим прием SYN. Сторона-инициатор снова известит удаленную сторону о том, что его ACK получен. Таким образом, две стороны взаимодействия "договорятся" об установлении канала связи, конечными точками (параметрами) которого являются два IP-адреса (информация сетевого уровня) и два TCP-порта (информация транспортного уровня), по одному на каждой стороне.

Повторяя все вышесказанное в терминах TCP/IP, можно описать ситуацию следующим образом.

Пусть в компьютере включены несколько интерфейсов канального (и физического) уровней, например аналоговый модем и две сетевые платы. За каждым из этих устройств может быть закреплен свой адрес сетевого уровня (в данном случае IP-адрес). Функции сетевого уровня по приему данных выполняет операционная система, она анализирует все полученные пакеты и определяет те, информацию из которых TCP/IP – Transmission Control Protocol / Internet Protocol (протокол управления передачей / межсетевой протокол); стек протоколов, на котором базируется глобальная сеть Internet.

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

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

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

Поэтому сформированный кадр выглядит следующим образом:

К – заголовок и трейлер канального уровня;

С – заголовок сетевого уровня;

Т – заголовок транспортного уровня;

С – заголовок сеансового уровня;

П – заголовок уровня представления данных;

П – заголовок прикладного уровня.

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

Контрольные вопросы к главе 1. Перечислите назначение и функциональные признаки всех семи уровней по модели OSI/RM.

2. Для какой цели существуют каждая из систем адресации на канальном, сетевом и прикладном (доменные имена) уровнях?

3. Что такое TCP-порт?

4. Опишите структуру сетевых пакетов.

Глава 2.

Технология Ethernet Ethernet – технология (сетевая архитектура) локальных вычислительных сетей, описанная стандартами физического и канального уровней модели OSI/RM. При построении сети на коммутаторах и репитерах (повторителях, хабах) Ethernet строится по физической топологии "звезда"; логическая топология этой архитектуры вне зависимости от кабельной разводки всегда остается "шиной" (в случае использования CSMA/CD в качестве метода доступа к среде передачи)3.

Скорость передачи данных определяется спецификацией и может равняться 10 Мбит/с, 100 Мбит/с (Fast Ethernet), 1 Гбит/с (Gigabit Ethernet), 10 Гбит/с (10 Gigabit Ethernet). Внутри каждой спецификации существует еще несколько подвидов (например, 100Base-TX, 100BaseFX для Fast Ethernet), характеризуемых разными видами подключения к среде передачи (оптоволокно, витая пара, коаксиальный кабель), а также методами кодирования сигнала и включением/выключением тех или иных коммуникационных опций.

Как уже было сказано, на канальном уровне все устройства имеют свой адрес, обычно определенный аппаратно. В технологии Ethernet в качестве адреса используется 6-байтовый идентификатор МАС (medium access control, например 00:00:C0:5E:83:0E).

Различают широковещательные (broadcast), уникальные (unicast) MACадреса и МАС-адреса групповой рассылки (multicast). Первый состоит из 1 во всех 48 разрядах (FF:FF:FF:FF:FF:FF), у второго самый левый (старший) бит всегда 0. МАС-адрес групповой рассылки обязательно Физическая топология – вид кабельной разводки и подключения оконечных узлов к коммутационному оборудованию.

Логическая топология – метод и способ доступа к среде передачи.

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

Шина характеризует такой способ подключения устройств, при котором можно выделить разделяемую всеми среду передачи (например, коаксиальный кабель в технологии "тонкий Ethernet 10Base-2", если говорить о физической топологии) и/или способ взаимодействия, при котором оконечные равноправные устройства "прослушивают" сеть, ожидая момент разрешения начала передачи, когда среда становится свободной.

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

В качестве алгоритма доступа к среде передачи используется метод CSMA/CD (Carrier Sense Multiple Access with Collision Detection, множественный доступ с прослушиванием несущей и обнаружением коллизий).

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

2.1. Алгоритм CSMA/CD 1. Перед началом передачи станция должна определить, "свободна" ли среда передачи (прослушивание несущей).

2. Если чужой сигнал в среде не обнаружен, станция может начать передачу.

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

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

5. После выхода из режима ожидания станция снова может начинать передачу (переход на пункт 1).

Метод доступа к среде в сетях Ethernet (CSMA/CD) носит конкурентный характер. Станции прослушивают среду, и если она свободна, имеют право начать передачу. Из-за неопределенности этого момента и достаточно большой длины кабельной системы в среде могут возникать коллизии (то есть "столкновения" сигналов). Это приводит к необходимости повторной передачи через некоторый, случайным образом выбранный, интервал времени. Коллизии уменьшают общую пропускную способность сети.

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

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

рис.):

a) коллизий не существует (сетевые карты работают в дуплексном режиме);

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

в) домен коллизий ограничен кабелем от сетевой карты до коммутатора (сетевые карты работают в полудуплексном режиме).

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

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

2.2. Формат кадра Ethernet Существует 4 различных вида кадров Ethernet, их общий вид представлен ниже.

• DA – адрес назначения (Destination Address, 6 байтов);

• SA – адрес источника (Source Address, 6 байтов);

• L/T – длина или тип кадра (Length/Type, 2 байта);

• Data – данные верхнего уровня (например, IP-уровня, 46– байтов);

• CRC – поле контрольной суммы (Cyclical Redundancy Check, 4 байта).

Необходимо также отметить, что перед каждым кадром станцияотправитель добавляет преамбулу и начальный ограничитель кадра (8 байтов). Кроме того, все станции должны выдерживать межкадровые промежутки в 96 тактов (например, 9.6 мкс при битовой скорости 10 Мбит/с).

2.3. Promiscuous mode (режим прослушивания сети) В обычном режиме функционирования сетевого интерфейса при получении кадра данные (46–1500 байтов) будут переданы обработчику верхнего уровня только в случаях, если адрес назначения, установленный в поле DA, широковещательный либо он совпадет с уникальным МАС-адресом принимающей станции.

Однако каждый адаптер Ethernet может быть переведен в режим, в котором будут обрабатываться все кадры, поступающие из среды передачи. На английском языке такой режим носит название "promiscuous", что переводится как "безразличный" или "неразборчивый". Этим свойством сетевых адаптеров можно пользоваться, например, для создания программных анализаторов сетевого трафика (tcpdump, см. главу с описанием сетевых утилит).

Контрольные вопросы к главе 1. Опишите метод доступа к среде передачи CSMA/CD, используемый в Ethernet.

2. Что такое МАС-адрес? Укажите уровень по модели OSI/RM, в рамках которого уместно упоминать MAC-адрес.

3. В чем разница между физической и логической топологиями посроения сетей?

4. Рассчитайте полезную пропускную способность сети Fast Ethernet (100 Мбит/с), учитывая в качестве накладных расходов межкадровые промежутки, преамбулу кадра и заголовки канального уровня.

5. В каком случае при поступлении кадра с физического уровня станция будет "изучать" поле канального уровня?

6. Что такое promiscuous режим?

7. Укажите максимальное количество возможных уникальных (unicast) МАС-адресов.

Глава 3.

Протоколы стека TCP/IP и прикладного уровня Стек TCP/IP (Transmission Control Protocol / Internet Protocol, протокол управления передачей / межсетевой протокол) в отличие от OSI/RM содержит всего 4 уровня: I – прикладной, II – транспортный, III – межсетевой, IV – физический (физического интерфейса). Все они в той или иной степени соответствуют уровням идеальной модели, то есть выполняют похожие функции.

TCP UDP II

IP ICMP

Уровень физического интерфейса в TCP/IP не регламентирован, в качестве него может выступать одна из сетевых архитектур, обеспечивающая передачу/прием кадров канального уровня (Ethernet, Token Ring, ATM, FDDI, ADSL, PPP, ISDN, RPR и т. д.). Верхний подуровень канального (Data link) уровня, именуемый LLC, обеспечивает связку между IV и III уровнями стека TCP/IP. Следует отметить, что во многих случаях IP-уровень может быть расположен непосредственно над уровнем физического интерфейса (минуя подуровень LLC).

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

ARP/RARP4 – протокол, заголовки и данные которого инкапсулированы непосредственно в кадр канального уровня, а не в IP-датаграмму5, предназначен для взаимосвязи адресации канального (чаще всего MACадресация) и сетевого уровней (IP-адресация). ICMP6 инкапсулирован в ARP/RARP – Address Resolution Protocol / Reversed ARP (протокол распознавания адреса / протокол обратного распознавания адреса).

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

ICMP – Internet Control Message Protocol (межсетевой протокол управляющих сообщений).

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

Транспортный уровень представлен двумя способами организации связи: с гарантированной (TCP) и негарантированной (UDP7) доставкой данных.

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

3.1. Межсетевой протокол IP (Internet Protocol) Протокол IP – это протокол сетевого уровня по модели OSI/RM.

Формат IP-датаграммы представлен ниже; каждая строчка содержит 32 бита (4 байта).

Version – версия IP-протокола (для IPv4 в это поле заносится 4, что соответствует в бинарном виде 0100 в старшем полубайте первого октета датаграммы);

IHL – длина заголовка в 32-битовых словах (Internet Header Length, 4 бита; в случае IPv4 и длины заголовка в 32-битовых словах, равной 5, в первом байте IP-датаграммы содержится 0x45);

TOS – тип сервиса (Type of Service, 1 байт);

TL – полная длина IP-датаграммы в байтах (Total Length, 2 байта);

Identification – 16-битовое число, одинаковое для всех фрагментов одной датаграммы (2 байта);

Flags – флаги (DF – не фрагментировать, MF – еще фрагменты, 3 бита, один флаг зарезервирован);

UDP – User Datagram Protocol (протокол пользовательских датаграмм).

Fragment Offset – смещение фрагмента внутри датаграммы в 8 байтовых единицах (13 битов);

TTL – время жизни IP-датаграммы (Time To Live, значение в этом поле уменьшается на 1 при прохождении через очередной маршрутизатор, 1 байт);

Protocol – протокол верхнего уровня (например, 0x06 для TCP, 0x для UDP, 0x01 для ICMP, 1 байт);

Header Checksum – контрольная сумма заголовков IP-датаграммы (2 байта);

Source Address – IP-адрес источника (4 байта);

Destination Address – IP-адрес назначения (4 байта);

Options – опции (если есть);

Padding – байты выравнивания поля опций до 32-битового слова;

Data – данные верхнего уровня.

3.2. Протокол UDP (User Datagram Protocol) Протокол передачи пользовательских датаграмм UDP – протокол транспортного уровня по модели OSI/RM. Формат UDP-датаграммы представлен ниже.

• Source Port – порт источника (2 байта);

• Destination Port – порт назначения (2 байта);

• Length – полная длина UDP-пакета (2 байта);

• Checksum – контрольная сумма (2 байта);

• Data – данные, инкапсулированные в UDP-пакет.

3.3. Протокол TCP (Transmission Control Protocol) Протокол управления передачей TCP – протокол транспортного и сеансового уровней по модели OSI/RM. Формат TCP-сегмента представлен ниже.

• Source Port – порт источника (2 байта);

• Destination Port – порт назначения (2 байта);

• Sequence Number – номер последовательности (4 байта);

• Acknowledgement Number – номер подтверждения (4 байта), оба этих числа используются для контроля правильности приема переданных данных;

• Data Offset – длина TCP-заголовков в 32-битовых словах (4 бита);

• однобитовые TCP-флаги (U, A, P, R, S, F);

• Window – размер окна в байтах (2 байта);

• Checksum – контрольная сумма TCP-сегмента и псевдозаголовков • Urgent pointer – указатель срочности (2 байта);

• Option-kind, Option-length и Option-data – тип (1 байт), длина (1 байт) и данные опций TCP;

• Padding – поле заполнения до 32-битового слова;

• Data – данные верхнего уровня, инкапсулированные в TCP-сегмент.

TCP-флаги:

URG (urgent) – флаг срочности, указывает на использование поля Urgent Pointer (например, при нажатии Ctrl-C в сеансе telnet или при передаче файла в поле Urgent Pointer записывается смещение передаваемых в этом сегменте данных относительно номера последовательности);

ACK (acknowledgement) – флаг подтверждения, указывает на подтверждение приема данных и необходимость использования Acknowledgement Number;

PSH (push) – указатель немедленной передачи инкапсулированных данных приложению на стороне получателя (например, в сеансе telnet для отправки сегментов, содержащих отдельные буквы, при побайтовой отсылке на сервер);

RST (reset) – флаг сброса соединения;

SYN (synchronization) – флаг инициирования соединения, указывает на необходимость использования Sequence Number;

FIN (finish) – флаг запроса закрытия соединения.

3.4. Протокол ICMP (Internet Control Message Protocol) ICMP (протокол управляющих сообщений в сети Internet) инкапсулирован в IP-датаграмму (при этом поле Protocol в IP-заголовках содержит 0x01).

• Type – тип ICMP-сообщения (1 байт);

• Code – код сообщения (зависит от значения поля Type, 1 байт);

• Checksum – контрольная сумма;

• Data – данные.

3.5. Протоколы ARP и RARP (Address Resolution Protocol и Reversed ARP) Протоколы ARP (распознавания МАС-адреса по известному IP-адресу) и RARP (распознавания IP-адреса по известному МАС-адресу) связывают канальный и сетевой уровни в модели OSI/RM. Оба протокола носят широковещательный характер, поэтому используются только в локальных сетях (в пределах одного сегмента сетевой архитектуры канального уровня, что называется "до первого маршрутизатора").

Необходимо обратить внимание, что ARP и RARP организуют взаимосвязь не только для Ethernet – IP, но и для других сетевых архитектур и протоколов сетевого уровня; формат ARP и RARP пакетов представлен ниже.

Sender Protocol Address (bytes 3-4) • Hardware Type – тип сетевой архитектуры (канальный уровень, 0x0001 для 10 Mb Ethernet);

• Protocol Type – идентификатор протокола сетевого уровня ( • HW Address Length – длина адреса канального уровня (006 для MAC-адреса);

• Protocol Address Length – длина адреса сетевого уровня (004 для IP-адреса);

• Opcode – код операции (1 – ARP-запрос, 2 – ARP-ответ, 3 – RARPзапрос, 4 – RARP-ответ);

• Sender и Target HW Address и Protocol Address – адреса канального и сетевого уровней источника и приемника соответственно.

Часть полей может быть пустой. Так, при формировании ARP-запроса поле Target HW Address остается незаполненным. Станция, имеющая такую информацию, сформирует ARP-ответ, в котором укажет искомый адрес канального уровня.

3.6. Процесс отправки, перенаправления и получения датаграмм Процесс отправки, перенаправления и получения датаграммы сетевого уровня можно рассмотреть на примере приведенного рисунка.

На схеме слева и справа изображены два компьютера, у каждого есть интерфейс канального уровня (например, сетевой адаптер стандарта Ethernet) с уникальными адресами МАС1 и МАС4 соответственно.

Между ними находится маршрутизатор (устройство сетевого уровня по модели OSI/RM), в задачу которого входит перенаправление датаграмм с одного из физических интерфейсов (МАС2, МАС3) на другой.

Основанием для перенаправления является соответствие сетевого адреса назначения, считанного из заголовков сетевого уровня датаграммы, сети назначения, указанной в таблице маршрутизации. При этом компьютер 1 и левый физический интерфейс маршрутизатора имеют разные адреса сетевого уровня и входят в одну сеть net1, а компьютер и правый интерфейс маршрутизатора – в сеть net2.

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

Во время подготовки датаграммы отправителю становятся известны адреса источника net1.ip1 (свой) и получателя net2.ip2 на сетевом уровне (например, удаленный адрес сетевого уровня можно узнать, воспользовавшись службой DNS). Сформированная датаграмма записывается в поле данных кадра канального уровня. Свой адрес канального уровня МАС1 отправителю, понятно, известен. Драйвер сетевой платы записывает его в поле SA (Source Address). Проблема возникает с тем, что писать в поле DA (Destination Address) и куда отправлять кадр с данными. Ответ очевиден: на маршрутизатор по умолчанию, коим является интерфейс сетевого уровня с адресом net1.ip2. МАС-адрес этого сетевого интерфейса можно узнать, воспользовавшись службой ARP (Address Resolution Protocol). Компьютер формирует широковещательный на канальном уровне ARP-запрос (только в пределах левого сегмента, маршрутизатор не пропустит сквозь себя широковещательные кадры канального уровня) для того, чтобы по известному адресу сетевого уровня (net1.ip2) узнать его МАС-адрес.

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

Маршрутизатор получает кадр с левого (на рисунке) интерфейса, вскрывает его и находит датаграмму сетевого уровня, в которой указан адрес назначения net2.ip2. По своей таблице маршрутизации, пользуясь маской сетевого адреса, он определяет, что датаграмму необходимо переслать на интерфейс с МАС-адресом МАС3. Поскольку компьютер 2 включен логически в сеть (на сетевом уровне модели OSI/RM), непосредственно подсоединенной к маршрутизатору, последний сформирует ARP-запрос на адрес назначения net2.ip2. В ответ ему придет информация о МАС4. Он сформирует новый кадр канального уровня, вложив в него исходную неизмененную датаграмму.

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

3.7. Установление и разрыв TCP-соединения Для того чтобы установить TCP-соединение, необходимо проделать следующие действия.

1. Сторона-инициатор соединения (клиент) отправляет SYN-сегмент (выставленный бит SYN в поле флагов заголовков TCP), указывая номер порта сервера, к которому клиент хочет подсоединиться, и исходный номер последовательности клиента (поле Sequence Number в заголовках TCP).

2. Сервер отвечает сегментом SYN, содержащим свой исходный номер последовательности сервера вместе с выставленным флагом SYN. Также он выставляет флаг ACK и заполняет поле "номер подтверждения" (Acknowledgement number), вставляя в него полученный от клиента номер последовательности + 1.

3. Клиент должен подтвердить приход SYN-сегмента от сервера с использованием ACK-флага и нового значения в поле подтверждения (полученный от сервера номер последовательности +1).

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

При одностороннем закрытии соединения сторона-инициатор закрытия должна послать по установленному соединению FIN-сегмент (выставленный флаг FIN), а также получить ACK-ответ от удаленной стороны с уведомлением о получении FIN-сегмента.

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

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

Таким образом, при установлении соединения двум сторонам необходимо послать и принять 3 сегмента, при его разрыве – 4.

3.8. Hyper Text Transfer Protocol (HTTP) Под аббревиатурой HTTP (протокол доставки гипертекстовых документов) понимается протокол, обеспечивающий функционирование Сети и являющийся его базовой транспортной подсистемой. На данный момент все средства просмотра страниц в Internet должны соответствовать спецификации HTTP/1.1, представленной в июне 1999 г. (RFC 2616).

Любой стандарт, связанный с Internet, публикуется в виде RFCдокументов (Request for Comments, запрос на рецензию и комментарии).

Основным разработчиком алгоритмов и процедурных правил клиентсерверного Web-взаимодействия следует признать Тима Бернерс-Ли (T. Berners-Lee), участвовавшего в создании всех версий протокола HTTP, начиная с HTTP/0.9 (1991 г.), HTTP/1.0 (окончательно утвержденного в RFC 1945 в мае 1996 г.) и заканчивая HTTP/1.1 (RFC и RFC 2616). Все упомянутые RFC-документы можно найти по адресу:

http://www.ietf.org/ ("штаб-квартира" WWW).

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

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

Протокол HTTP описывает порядок действий клиентского программного обеспечения в момент запроса им гипертекстовых документов и другой информации у серверов, а также отправку ответов этими серверами. Ранние версии протокола позволяли строить запрос в упрощенной форме, тогда как HTTP/1.1 требует, чтобы были явно указаны несколько полей внутри него, например обязательное поле host.

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

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

Вот так, например, выглядит HTTP-запрос, посылаемый браузером открытым текстом по предварительно установленному TCP-каналу:

GET /index.shtml HTTP/1. Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT;

DigExt) Host: thermo.karelia.ru Connection: Keep-Alive Cookie: voted=21; uid= В нем запрашивается index.shtml – главная страница сервера thermo.karelia.ru. При этом указываются:

• версия HTTP;

• возможность gzip- и deflate-компрессии;

• сигнатура браузера, сформировавшего запрос (Mozilla/4. (compatible; MSIE 5.0; Windows NT; DigExt));

• имя Web-сервера (thermo.karelia.ru);

• правило поддержания общения между браузером и Web-сервером (постоянное соединение);

• полученные ранее этим пользователем файлы персонализации (voted со значением "21" и uid со значением "45639").

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

Для того чтобы сформировать веб-серверу простейший (пусть даже некорректный) запрос, достаточно создать tcp-соединение с 80-м портом сервера (чаще всего именно этому порту приписан сервис httpd) и послать ему следующую команду:

GET / HTTP/1. и нажать два раза Enter () В ответ сервер, скорее всего, выдаст сообщение об ошибке.

3.9. Simple Mail Transfer Protocol (SMTP) В качестве транспортного средства доставки сообщений в Internet выступает SMTP (simple mail transfer protocol, простой протокол передачи почты), который был стандартизован в виде RFC 821 (Request For Comments).

Упрощенно схема взаимодействия представлена на следующем рисунке (объемными стрелками показано направление движения почтовых сообщений).

клиент Со стороны пользователя обычно одна и та же программа выступает в роли и POP3-клиента и SMTP-клиента отправителя. Наиболее распространенными на данный момент являются MS Outlook, The Bat, Netscape Messenger, Eudora, Pegasus mail, Mutt, Pine и др. При нажатии в них на кнопочку "отправить" происходит формирование очереди сообщений (если посылается не одно письмо) и установление двустороннего сеанса общения с SMTP-сервером провайдера. На схеме представлено так, что у пользователя есть клиентское ПО, а у провайдера – серверная часть приложения. На самом деле это немного не так.

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

Если на каком-нибудь этапе передачи SMTP-клиент обнаружит невозможность подключиться к следующему серверу (например, компьютер отправили на профилактику или аппаратура связи вышла из строя), он будет пытаться отправить сообщение через некоторое время – 1 час, 4 часа, день и т. д., до 4 суток в общем случае. Причем временные отрезки между попытками, как правило, зависят от настроек программы-пересыльщика почты. Одновременно такой сервер должен уведомить отправителя сообщения о невозможности доставить почту, послав ему стандартное письмо "Failed delivery" (доставка невозможна) и рассказав о графике дальнейших попыток по продвижению исходного сообщения. Если канал связи не восстановится за указанный большой промежуток времени (например, 4 дня), посланная информация будет считаться утерянной.

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

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

Получить эту информацию можно в "Свойствах письма", кликнув правой кнопкой мыши на самом письме в MS Outlook, нажав Ctrl + Shift + H в The Bat или совершив нечто подобное в других почтовых клиентах.

Received: from mx10.mail.ru (mx10.mail.ru [194.67.57.20]) by dfe3300.karelia.ru (8.9.0/8.9.0) with ESMTP id JAA Thu, 18 Apr 2002 09:19:13 +0400 (????) Received: from f5.int ([10.0.0.57] helo=f5.mail.ru) by mx10.mail.ru with esmtp (Exim MX.A) id 16y46p-0002ox- for somebody@dfe3300.karelia.ru; Thu, 18 Apr 2002 09:05: + Received: from mail by f5.mail.ru with local (Exim FE.5) id 16y46o-000CfY- for somebody@dfe3300.karelia.ru; Thu, 18 Apr 2002 09:05: + Received: from [213.59.200.7] by win.mail.ru with HTTP;

Thu, 18 Apr 2002 09:05:26 + From: "Testing" To: somebody@dfe3300.karelia.ru Subject: For testing purposes only Mime-Version: 1. X-Mailer: mPOP Web-Mail 2. X-Originating-IP: [213.59.200.7] Date: Thu, 18 Apr 2002 09:05:26 + Reply-To: "Testing" Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-Id:

X-UIDL: 74fb663e2be8352b3a0b88ca08030c1e Тестовое сообщение.

Данный пример показывает четкую структуру письма. Тело почтового сообщения состоит из заголовочной части и текста (в данном случае слова "Тестовое сообщение") плюс вложения. До слова "From:" информация заносится промежуточными SMTP-серверами, каждый из которых добавляет свои данные в самое начало, тем самым постоянно увеличивая количество передаваемых далее байтов. Средняя заголовочная часть (начиная с "From:" и заканчивая "X-UIDL") почти полностью формируется почтовым агентом отправителя. Исключение составляет, например, поле "Message-Id:", которое было сформировано первым по пути следования SMTP-сервером – f5.mail.ru. Некоторые поля являются стандартизованными и желательными для употребления, например From, To, Subject, Reply-To… А некоторые являются дополнительными по отношению к описанным в стандарте текстовых сообщений в среде Internet (RFC 822) и необязательными. Такие поля начинаются с "X-" и служат, например, для идентификации самого почтового клиента.

[213.59.200.7] by win.mail.ru with HTTP; говорят о том, что письмо было отослано с помощью браузера с использованием протокола HTTP (hypertext transfer protocol). На пути от win.mail.ru к dfe3300.karelia.ru встретилось два транзитных SMTP-сервера: f5.mail.ru и mx10.mail.ru.

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

Составляя почтовое сообщение, пользователь должен заполнить поле "To", куда заносится адрес назначения (запись "From" подставится в заголовки письма автоматически). В Internet существуют правила хорошего тона, которые рекомендуют также указывать тему сообщения (поле "Subject").

Если необходимо разослать почту по нескольким адресам "в открытую", необходимо воспользоваться полем "CC" (carbon copy) или дописать их через запятую в поле "To". Слова "в открытую" означают, что человек, получивший такое письмо и просмотревший его заголовки, может определить, кому еще оно было послано в качестве копии. Если вдруг возникнет необходимость доставить один и тот же текст нескольким людям, но так, чтобы каждый из них не знал, кому еще адресовано это письмо, придется воспользоваться полем "BCC" (blind carbon copy – слепая копия). В этом случае все адресаты, указанные в поле "BCC" через запятую, получат сообщение, как если бы оно предназначалось только им. Эту работу по "размножению" почты выполняют незаметно для глаз пользователя почтовый клиент пользователя и первый по пути следования SMTP-агент. Они анализируют заголовочную часть письма, и если обнаруживают заполненные поля "CC", "BCC", то действуют в соответствии со своими алгоритмами обработки почтовых сообщений.

Теперь более подробно рассмотрим клиент-серверное взаимодействие по протоколу SMTP. Программа пользователя, выбрав для связи соответствующий почтовый сервер, устанавливает с ним контакт на транспортном и сеансовом уровнях эталонной модели взаимодействия открытых систем OSI/RM (в терминах TCP/IP (transmission control protocol / internet protocol) это – TCP-уровень). Взаимодействие на более низких уровнях (канальном, сетевом) происходит прозрачно для обеих сторон. Протокол SMTP – протокол прикладного уровня и базируется поверх TCP. В его рамках не оговариваются ни размер сегментов данных, ни правила квитирования, ни отслеживание ошибок, возникающих при передаче информации.

Итак, по уже установленному соединению клиентское ПО передает команды SMTP-серверу, ожидая тут же получить ответы. В арсенал SMTP-клиента, равно как и сервера, входит около 10 команд, но воспользовавшись только пятью из них, уже можно легально послать почтовое сообщение, это HELO, MAIL, RCPT, DATA, QUIT. Их использование подразумевается именно в такой последовательности.

HELO (усеченная форма от hello, приветствие) предназначена для идентификации отправителя, MAIL указывает адрес отправителя, RCPT (от англ. recipient – принимающий) – адрес назначения. После команды DATA и ответа на нее клиент посылает серверу тело сообщения, которое должно заканчиваться строкой, содержащей лишь одну точку.

Выражаясь языком программистов, сервер узнает о прекращении посылки сообщения, встретив следующий набор символов "\r\n.\r\n" или "." (CRLF – так называемый возврат каретки с переходом на новую строчку, обычно такое получается при нажатии клавиши Enter во многих редакторах).

Для демонстрации вышесказанного можно воспользоваться программой telnet (ssh). Если выполнить в командной строке Unix-подобных операционных систем следующую команду:

telnet name_of_mail_server.ru или, нажав Пуск / Выполнить, ввести telnet name_of_mail_server.ru (для пользователей Windows), то установится TCP-соединение с 25-м портом указанного сервера (естественно, вместо слов name_of_mail_server следует набрать имя почтового сервера). Этот TCPпорт служит для обеспечения взаимодействия по протоколу SMTP (например, 80-й TCP-порт обычно закреплен за веб-сервером, принимающим и отсылающим информацию по HTTP-протоколу). Если не будет видно набираемых символов в сеансе telnet, попробуйте изменить параметры вывода на экран (Параметры / Отображение ввода).

В следующем примере приведен telnet-сеанс общения с несуществующим public_mail_server.ru, абонентом которого является некто с именем test_only, ему и предназначается почтовое сообщение.

220 ESMTP PUBLIC_MAIL_SERVER.RU Thu, 25 Apr 2002 14:15:50 + helo my_comp.ru 250 public_mail_server.ru Hello as1-52.dialup.onego.ru [195.161.137.53] mail from: me@my_comp.ru 250 is syntactically correct rcpt to: test_only@public_mail_server.ru 250 verified data 354 Enter message, ending with "." on a line by itself body of the test message from me@my_comp.ru to test_only@public_mail_server.ru 250 OK id=170gLG-000FEI- quit Непосредственно после установления соединения сервер выдает строчку с кодом ответа 220. В ответ на нее клиент может инициировать сеанс связи по протоколу SMTP, послав команду HELO (можно маленькими буквами) и указав у нее в аргументах имя своего компьютера. Сюда можно писать все, что вздумается, потому что по принятии команды HELO сервер обязан сделать запрос в DNS и, если это возможно, по IP-адресу определить доменное имя компьютера клиента. (IPадрес уже известен на момент установления соединения по протоколу TCP.) Именно поэтому в строчке "250 public_…" присутствует имя as1dialup.onego.ru, соответствующее одному из IP-адресов модемного пула провайдера, а не my_comp.ru, как было указано на стадии приветствия.

Далее в команде "MAIL FROM:" клиент сообщает обратный адрес отправителя, который проверяется обычно только на корректность (это зависит от настроек SMTP-сервера). После слов "RCPT TO:" следует набрать адрес электронной почты абонента на данном сервере. Ответ "250 verified" свидетельствует о существовании логина с именем test_only. Клиент отсылает команду DATA и ждет приглашения начать пересылку тела письма (код 354).

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

Как будут действовать пользовательское и серверное ПО в случае необходимости "массовой" рассылки? Если клиент посылает сообщение, у которого в заголовочной части в поле CC указаны несколько e-mail адресов, первый по пути следования SMTP-сервер должен будет в общем случае установить сеанс продвижения почты с каждым из серверов данного списка и отослать точную копию письма каждому. В случае использования поля BCC клиент, формирующий сообщение, уничтожит запись BCC в теле сообщения и несколько раз (по количеству адресатов) отошлет первому SMTP-серверу команду "RCPT TO:" каждый раз с новым адресом в качестве аргумента. Таким образом, сервер получит указание разослать почту по многим адресатам. Причем в этом случае получатели писем ничего не будут знать друг о друге, т. к. рассылка осуществляется посредством команд SMTP-протокола (без использования информации в заголовочной части письма).

Что будет, если попробовать соединиться с каким-нибудь мейлсервером и через него передать почту, предназначенную другому?

(В предыдущем примере адресатом был test_only@public_mail_server.ru, поэтому устанавливалось соединение именно с public_mail_server.ru.) Чаще всего на ввод команды "RCPT TO:" в ответ вы получите "relaying denied" (пересылка запрещена). Сделано это с целью борьбы с неконтролируемыми и несанкционированными почтовыми рассылками.

В принципе, эта ситуация очень похожа на простое использование транзитных серверов исходящих сообщений. Вы указываете один компьютер в качестве следующего пункта пересылки, а сообщение предназначается другому. Поэтому при настройке почтовых серверов администраторами вводятся ограничения на круг IP-адресов и доменных имен, для которых работает пересылка. Если этого не сделать, их сервер сразу же попадет в черный список, используемый при фильтрации такими гигантами, как hotmail.com, yahoo.com, mail.com и почта от абонентов "проштрафившихся" адресов будет блокироваться.

Протокол SMTP существует достаточно давно – с 1982 года (RFC 821);

впоследствии в него были внесены некоторые дополнения, выразившиеся в появлении ESMTP (Extended SMTP, RFC 1425; 1993 год). Если клиент поддерживает ESMTP, его первая команда будет EHLO (Extended Hello), а не HELO. Сервер в ответ на нее должен выдать список всех дополнительных команд, которые он умеет обрабатывать.

Клиент может ими воспользоваться, а может проигнорировать, послав сообщение продемонстрированным выше способом.

Контрольные вопросы к главе 1. Укажите положение в стеке OSI/RM следующих протоколов: IP, TCP, UDP, ARP/RARP, ICMP.

2. Что такое датаграмма?

3. На каких уровнях по модели OSI/RM для стека TCP/IP может применяться (обычно применяется) контроль качества переданной информации?

4. Как узнать длину поля "данные" в TCP-сегменте?

5. Что такое фрагментация IP-датаграмм? Какие механизмы существуют для поддержки фрагментации?

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

7. Опишите схему действий устройств, изображенных на рисунке в разделе 3.6, при отправке, перенаправлении и получении датаграмм.

8. Опишите схему действий устройств, изображенных на рисунке в разделе 3.6, при отправке, перенаправлении и получении датаграмм в случае, если добавлен еще один маршрутизатор между изображенным маршрутизатором и компьютером 2.

9. Опишите схему действий устройств, изображенных на рисунке в разделе 3.6, при установлении TCP-соединения между компьютерами 1 и 2 (в пояснениях следует затронуть транспортно-сеансовый, сетевой и канальный уровни).

10. Каким образом происходит подтверждение приема данных при общении по протоколу TCP?

Глава 4.

Средства и утилиты сетевого тестирования 4.1. ping Программа ping предназначена для проверки доступности удаленного хоста или сетевой службы и часто используется в качестве самой первичной диагностики неисправностей (отсутствия связи) в глобальных и локальных сетях. Программа посылает ICMP (Internet Control Message Protocol) эхо-запрос на хост и ожидает возврата ICMP эхоотклика. Время между посылкой ICMP-запроса и получением ответа может свидетельствовать о пропускной способности канала связи.

Программа ping реализована во всех сетевых операционных системах.

С ее помощью можно тестировать сеть IP-пакетами любой длины от минимальной (64 байта) до максимально допустимой (~64 килобайтов) (длина пакета задается опциями в командной строке).

Следует также помнить, что во многих случая ping-пакеты могут блокироваться промежуточными маршрутизаторами, а хосты – пункты назначения могут быть сконфигурированы на запрет приема / отправки ICMP-сообщений.

Результат выполнения команды ping приведен ниже.

[alexmou@plasma alexmou]$ ping -c 3 localhost PING localhost.localdomain (127.0.0.1) from 127.0.0.1 : 56(84) bytes of data.

64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=0 ttl= time=134 usec 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl= time=155 usec 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=2 ttl= time=106 usec --- localhost.localdomain ping statistics --packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/mdev = 0.106/0.131/0.155/0.024 ms В последней строке указывается время обращения ICMP-пакетов (минимальное / среднее / максимальное для нескольких пакетов и отклонение от среднего). Это время складывается из двойного времени прохождения по сети и времени обработки пакета на удаленной стороне и промежуточных маршрутизаторах (usec обозначает микросекунды).

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

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

Внимание! При посылке ICMP-пакета длиной более 1.5 кбайта в сетях Ethernet он будет дробиться на более мелкие фрагменты.

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

traceroute, как и ping, использует ICMP и поле TTL в IP-заголовке.

Поле TTL (время жизни) – это 8-битовое поле, в которое отправитель записывает конкретное значение (зависит от операционной системы).

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

На хост назначения отправляется IP(UDP)-датаграмма 1 с TTL, установленным в единицу. Первый маршрутизатор, который должен обработать датаграмму 1, уничтожает ее (так как TTL равно 1) и отправляет ICMP-сообщение 2 об истечении времени (time exceeded).

ICMP-сообщение инкапсулировано в IP-датаграмму 2, следовательно, отправитель изначальной UDP-датаграммы 1 всегда знает IP-адрес отправителя 2. Таким образом определяется первый маршрутизатор по пути следования.

Затем traceroute отправляет датаграмму с TTL, равным 2, что позволяет получить IP-адрес второго маршрутизатора. Это продолжается до тех пор, пока датаграмма не достигнет хоста назначения. Однако если датаграмма прибыла именно на хост назначения, он не уничтожит ее и не сгенерирует ICMP-сообщение об истечении времени, так как датаграмма достигла своего конечного пункта назначения.

В UDP-датаграммах (User Datagram Protocol), которые посылает traceroute, устанавливается, например, неиспользуемый номер UDPпорта (больше чем 30000), что делает невозможным обработку этой датаграммы каким-либо приложением. Поэтому, когда прибывает подобная датаграмма, UDP-модуль хоста назначения генерирует ICMPсообщение другого типа: "порт недоступен" (port unreachable).

Результат выполнения команды может содержать строки со звездочками. Они говорят о том, что пакет либо утерян (отброшен вследствие загруженности маршрутизаторов), либо маршрутизатор не имеет права отсылать ICMP-сообщение "time exceeded" (в случае * * *) 12 * bubble-gum.net (211.10.11.170) 187.258 ms 163.876 ms 14 www.star-systems.com (64.78.63.91) 223.622 ms * 260.829 ms 4.3. netstat Программа netstat показывает текущее состояние различных структур данных, связанных с сетевым взаимодействием. В зависимости от выбранных опций можно узнать информацию о таблице маршрутизации (-r), текущих TCP-соединениях (-a), статистическую информацию попротокольно (-s).

Для сокетов TCP (просмотр с опцией -a) допустимы следующие состояния:

CLOSED

LISTEN

SYN_SENT – процесс начальной синхронизации соединения;

SYN RECEIVED

ESTABLISHED

CLOSE_WAIT FIN_WAIT_ LAST_ACK FIN_WAIT_ TIME_WAIT 4.4. tcpdump Утилита tcpdump используется для перехвата трафика, получаемого (отсылаемого) конкретным интерфейсом канального уровня (например, сетевой платой стандарта Ethernet) благодаря переводу его в специальный режим promiscuous.

В Unix-подобных операционных системах эта утилита находится в каталоге /usr/sbin/ и обычно запускается с правами суперпользователя.

Наиболее часто используемый вызов утилиты tcpdump выглядит следующим образом:

tcpdump [-c count] [-s snaplen] [-w file] [expression] При этом в файл file будут записаны несколько (count) первых отловленных кадров, удовлетворяющих маске expression (например, not port 25). Причем если длина кадра была более snaplen, то он будет усечен до этой величины.

Начало созданного файла будет содержать заголовки библиотеки pcap (24 байта), а далее последовательно будут расположены кадры, каждому из которых предшествует временная метка (8 байт), полная длина кадра (4 байта) и длина захваченной части кадра (4 байта). Таким образом, начало первого Ethernet кадра (MAC-адрес назначения) будет находиться по смещению 40 относительно начала файла. Формат заголовка всего файла и заголовка кадра можно посмотреть в заголовочном файле pcap.h.

Анализируя значение 13-го и 14-го байтов внутри каждого кадра, можно узнать, например, каков был протокол верхнего уровня по отношению к канальному ( 0 ) { // родительский процесс // здесь, например, можно проверить // что дочерний процесс успешно проинициализировался exit(0); // родительский процесс завершается } else { // pid == 0, дочерний процесс close(STDIN_FILENO);

close(STDOUT_FILENO);

close(STDERR_FILENO);

// после закрытия стандартных устройств ввода-вывода // и создания сессии дочерний процесс является "демоном" // здесь можно запустить на исполнение // какую-то другую программу Пояснения к примеру "демонизации". В ОС семейства Unix процессы могут объединяться в группы. Это сделано для того, чтобы можно было послать сигнал не отдельному процессу, а группе. Все процессы, входящие в группу, имеют одинаковый идентификатор группы. У группы процессов имеется лидер группы. Это такой процесс, идентификатор группы которого совпадает с идентификатором этого процесса. В свою очередь группы процессов могут объединяться в так называемые "сеансы" или "сессии". Аналогично группам, в сеанс входят все процессы, у которых идентификатор сеанса одинаков. Один из процессов, входящих в сеанс, является его лидером. Сеанс может иметь управляющий терминал, что используется для организации интерактивного взаимодействия с пользователем. Создание сеанса (сессии) производится, как уже упоминалось, с помощью системного вызова setsid(). Создать сессию не может процесс, являющийся лидером группы.

Именно по этой причине в приведенном примере перед "демонизацией" используется fork() - когда родительский процесс завершается, дочерний становится потомком процесса init, что гарантирует то, что этот потомок после этого не является лидером группы. После вызова setsid(), то есть после создания сеанса, данный процесс становится лидером этого нового сеанса и лидером группы.

Замечание по поводу закрытия стандартных потоков ввода-вывода.

Иногда рекомендуют не закрывать их, а перенаправить все эти потоки в псевдоустройство /dev/null. Это делается из опасения, что какаянибудь функция из используемых программой библиотек (или же сама программа, вследствие неаккуратности программиста) может выводить данные в стандартный поток вывода или в стандартный поток диагностического вывода. Если речь идет о серверах, то потоки с дескрипторами 1 и 2 могут соответствовать сокетам, поэтому запись в эти потоки "случайной" информации будет нарушением протокола взаимодействия.

Если же мы перенаправим эти потоки, то этим самым мы гарантируем, что потоки с дескрипторами 0, 1, 2 остаются открытыми и поэтому никакой сокет не будет иметь такой дескриптор.

В заключение этого раздела отметим, что в стандартной библиотеке имеется функция daemon(), которая выполняет "демонизацию", при этом имеется возможность указать, что нужно сделать с дескрипторами 0, 1 и 2 - просто закрыть их или же перенаправить в /dev/null.

7.2. Использование select() и poll() В этом разделе рассматривается вопрос о том, как организовать работу с более чем одним дескриптором потока ввода-вывода при помощи вызовов select() и poll(). Эти системные вызовы используются для синхронного мультиплексирования ввода-вывода. Рассмотрим сначала вызов select().

Для удобства его использования имеется ряд вспомогательных макроопределений (FD_CLR, FD_ISSET, FD_SET, FD_ZERO), которые применяются для манипуляций так называемыми наборами дескрипторов. Набор дескрипторов – это битовый массив, каждый бит которого определяет, входит ли данный дескриптор в набор или не входит. Набор дескрипторов представлен типом fd_set; иными словами, в программе набор дескрипторов – это переменная обозначенного типа.

Первые три макроопределения (FD_CLR, FD_ISSET, FD_SET) имеют два параметра, дескриптор и указатель на набор дескрипторов. Они производят следующие действия: первый исключает данный дескриптор из данного набора, второй проверяет, входит ли данный дескриптор в данный набор и, наконец, третий включает данный дескриптор в данный набор. Последнее макроопределение (FD_ZERO) имеет один параметр – указатель на набор дескрипторов; оно очищает данный набор, то есть удаляет из него все дескрипторы.

Прототип вызова select() имеет следующий вид:

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

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

Для выявления того, какие дескрипторы остались в наборе, а значит, готовы к той или иной операции, используйте FD_ISSET. Не забывайте отслеживать максимальный по величине дескриптор: полагаться на то, что самый "большой" дескриптор – это тот, который был возвращен самым последним вызовом open() или socket(), не следует, потому что некоторые из созданных ранее дескрипторов уже могли быть закрыты и их номера могли быть повторно использованы для вновь создаваемых дескрипторов.

Пример использования select() имеется в страничке руководства программиста, посвященной этому системному вызову (man select), а также в разделе 8.4, в котором приведен пример программы-сервера.

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

Первый набор – дескрипторы, проверяемые на наличие данных для чтения. Для терминалов и обычных сокетов наличие дескриптора в этом наборе после возврата select() означает, собственно, то, что имеются данные для чтения (вызов read() или recv() не заблокируется).

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

Перейдем теперь к рассмотрению вызова poll(). Как уже говорилось, он предназначен для достижения тех же целей, что и вызов select().

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

Элементами массива (первого параметра вызова) являются структуры следующего вида:

struct pollfd { Первый элемент структуры – собственно сам файловый дескриптор, второй – битовая маска событий, которые подлежат отслеживанию для этого дескриптора, третий – какие события реально произошли (тоже битовая маска). Второй элемент является входным параметром, а третий – выходным. В качестве событий для отслеживания можно указывать POLLIN (есть данные для чтения), POLLPRI (есть срочные данные для чтения), POLLOUT (запись не будет заблокирована); в качестве выходных событий могут встретиться три упомянутые (из числа тех, которые были запрошены, естественно), а также дополнительно POLLERR (ошибка), POLLHUP (связь разорвана), POLLINVAL (неправильный запрос, открытого файла с таким дескриптором нет). Запрос на отслеживание нескольких типов событий формируется из упомянутых констант посредством операции побитового ИЛИ. Например, POLLIN | POLLPRI – будем отслеживать, когда появятся данные для чтения или срочные данные для чтения.

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

#include #include #include struct pollfd stdinfd = {0,POLLIN,0};

одна структура struct pollfd;

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

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

int poll_ret;

char buf[1024];

int timeout = 7000; /* 7s */ int delta = 1000;

int main(void) poll_ret = poll(&stdinfd, 1, timeout);

printf("TIMED OUT, nuthin entered, bye :-P\n");

Программа работает с одним дескриптором (0, стандартный ввод).

Просит ввести что-нибудь; если в течение заданного тайм-аута ничего не вводилось, завершается. Тайм-аут все время уменьшается. Для терминала наличие данных для чтения означает, что была нажата клавиша Enter. Программа не проверяет, какое именно событие произошло (не анализирует поле stdinfd[0].revents).

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

Процесс может отреагировать на сигнал тремя "способами", а именно:

он может отреагировать стандартно (вызывается стандартный обработчик), может проигнорировать сигнал (никакой обработчик не вызывается) и, наконец, он может реагировать произвольным образом (вызывается нестандартный обработчик, то есть обработчик, определенный программистом, разрабатывающим программу). Однако не для всех сигналов у процессов имеется такая свобода выбора. Для некоторых сигналов реакция фиксирована (SIGKILL, SIGSTOP, SIGCONT). Такие сигналы нельзя перехватывать (задавать собственный обработчик для них) и их также нельзя игнорировать. Кроме того, есть сигналы, игнорирование которых возможно, но не рекомендуется, ибо приводит к неопределенному поведению (например, SIGSEGV, SIGFPE, SIGILL).

Рассмотрим примитивы работы с сигналами, определенные стандартом POSIX. Процесс может определить реакцию на сигнал, может послать сигнал какому-либо процессу (в частности, самому себе), может ждать прихода сигнала, а может блокировать сигналы и деблокировать их.

Для определения реакции на сигнал (установки обработчика) используется системный вызов sigaction(). Напомним, что речь идет именно о стандарте POSIX; в стандарте ANSI C для этих целей используется вызов signal(), который мы рассматривать не будем.

Вызов sigaction() имеет 3 параметра: первый задает номер сигнала, на который устанавливается реакция, второй задает, собственно, эту реакцию в виде указателя на некоторую структуру, третий параметр (указатель такого же типа) используется для возвращения информации о старом обработчике. Сигнал, на который определяется реакция, может быть любым допустимым в данной системе сигналом, кроме SIGKILL, SIGSTOP и SIGCONT. Структура, в которой содержится информация об обработчике сигнала, содержит 5 полей:

struct sigaction { void (*sa_handler)(int);

void (*sa_sigaction)(int, siginfo_t *, void *);

void (*sa_restorer)(void);

Последний элемент считается устаревшим, использовать его не следует.

Первый элемент – указатель на функцию-обработчик сигнала; он может также иметь значения SIG_DFL (установить на данный сигнал реакцию по умолчанию) и SIG_IGN (игнорировать данный сигнал). Третий элемент задает набор сигналов, которые будут блокированы во время работы обработчика. Блокирован будет (по умолчанию) также сигнал, который обрабатывается. Четвертый элемент – набор флагов, модифицирующих поведение подсистем ОС и libc, ответственных за управление сигналами. Он формируется посредством операции побитового "ИЛИ" из следующих возможных флагов.

• Флаг SA_NOCLDSTOP означает, что не надо посылать сигнал SIGCHLD, когда процесс-потомок останавливается.

• Флаг SA_ONESHOT (SA_RESETHAND) означает, что после того, как обработчик сигнала один раз проделает свою работу, в качестве реакции на данный исгнал устанавливается реакция «по умолчанию»; интыми словами, обработчик, определенный пользователем, будет вызван только один раз, в дальнейшем будет вызываться обработчик по умолчанию.

• Флаг SA_RESTART означает, что если во время исполнения системных вызовов приходит сигнал и его обработчик нормально возвращается, то вызов производится повторно; в случае, если этот флаг не установлен, прерванный сигналом системный вызов завершается с ошибкой (errno при этом принимает значение EINTR).

• Флаг SA_NOMASK означает, что сигнал не будет блокироваться во время работы его обработчика.

• Флаг SA_SIGINFO говорит о том, что обработчик сигнала будет принимать не один параметр, а три.

Важно отметить, что если флаг SA_SIGINFO установлен, то в структуре struct sigaction перед вызовом sigaction() необходимо вместо элемента sa_handler заполнять элемент sa_sigaction. В этом случае обработчику сигнала будет передан указатель на некоторую структуру. Эта структура содержит массу информации, в частности номер сигнала, значение errno, PID процесса, который послал сигнал, номер файлового дескриптора (для случая сигнала SIGIO).

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

Для посылки сигналов используется вызов kill(); отметим, что он одинаков в обоих упомянутых стандартах. Вызов имеет два параметра.

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

Перед тем как продолжить рассмотрение действий по отношению к сигналам, опишем вспомогательные функции, определенные стандартом POSIX и предназначенные для манипуляций так называемыми наборами сигналов. Всего их 5, называются они sigemptyset(), sigfillset(), sigaddset(), sigdelset(), sigismember().

Первые две имеют один параметр – указатель на набор сигналов;

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

Названия этих функций говорят сами за себя: sigemptyset() очищает заданный набор сигналов, то есть удаляет из него все сигналы;

sigfillset() включает в заданный набор все возможные сигналы;

sigaddset() добавляет заданный сигнал в заданный набор;

sigdelset() удаляет заданный сигнал из заданного набора;

sigismember() проверяет, входит ли заданный сигнал в заданный набор. Все функции, кроме последней, возвращают –1 при ошибке и при успешном завершении. Последняя возвращает 1, если сигнал имеется в наборе, 0 – если не имеется и –1 при ошибке. Три системных вызова для работы с сигналами по стандарту POSIX имеют хотя бы один параметр, представляющий собой указатель на набор сигналов.

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

Продолжим теперь рассмотрение действий, которые можно осуществлять по отношению к сигналам. Сигналы можно блокировать и деблокировать. Когда сигнал заблокирован, его обработчик не вызывается, даже если имеется сигнал, требующий обработки. Сигнал как бы ожидает обработки (на английском языке такой сигнал называется "pending signal" – "сигнал, ожидающий обработки", "висячий сигнал").

Обработчик сигнала будет вызван сразу, как только процесс разблокирует этот сигнал.

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

Совокупность всех сигналов, которые в данный момент времени заблокированы, – маска сигналов. У каждого процесса, естественно, своя маска сигналов; при создании процесса она наследуется от родительского процесса. Для манипуляций с маской сигналов предназначен системный вызов sigprocmask(). Не следует путать их с описанными выше манипуляциями над наборами сигналов, которые ничего не блокируют и не деблокируют.

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

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

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

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

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

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

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

Наконец, в третьем случае маска сигналов заменяется указанным набором. Если неинтересно, какая была маска до вызова, в качестве третьего параметра передаем NULL. Если не желаем ничего менять, а просто нужно знать, какая сейчас маска, передаем в качестве второго параметра NULL. Вызов возвращает 0, если все нормально, –1 при ошибке. Если вызов приводит к разблокированию сигналов, которые уже ожидали обработки, то он возвращается только после того, как будет вызван, по крайней мере, один из обработчиков этих сигналов.

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

Нам осталось рассмотреть операцию ожидания прихода сигнала. Ее можно производить с помощью двух вызовов: pause() и sigsuspend(). Первый определен также в стандарте ANSI C.

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

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

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

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

#include #include extern const char * const sys_siglist[];

void print_blocked(void) int nblocked = 0;

sigset_t blocked;

// get signal mask ret = sigprocmask(SIG_BLOCK, NULL, &blocked);

perror("sigprocmask()");

for ( sig = 0; sig < NSIG; sig++ ) { if ( sys_siglist[sig] ) { if ( nblocked ) printf(" total %d signal(s) blocked } \n\n", sigset_t blocked_orig;

sigset_t blocked_new;

int ret;

int main(void) printf("\nsigprocmask() example\n\ ~~~~~~~~~~~~~~~~~~~~~\n\n");

printf(" { originally blocked signals:\n");

print_blocked();

// формируем набор сигналов, // содержащий SIGINT, SIGTERM, SIGSEGV ret = sigemptyset(&blocked_new);

ret = sigaddset(&blocked_new, SIGINT);

ret = sigaddset(&blocked_new, SIGTERM);

ret = sigaddset(&blocked_new, SIGSEGV);

// блокируем SIGINT, SIGTERM, SIGSEGV, // сохраняем первоначальную маску сигналов ret = sigprocmask(SIG_BLOCK, &blocked_new, &blocked_orig);

perror("sigprocmask()");

printf(" { currently blocked signals:\n");

print_blocked();

ret = sigdelset(&blocked_new, SIGINT);

ret = sigdelset(&blocked_new, SIGTERM);

// SIGSEGV все еще в наборе // разблокируем SIGSEGV, сохраняем маску ret = sigprocmask(SIG_UNBLOCK, &blocked_new, NULL);

perror("sigprocmask()");

printf(" { currently blocked signals:\n");

print_blocked();

// восстанавливаем первоначальную маску сигналов ret = sigprocmask(SIG_SETMASK, &blocked_orig, NULL);

perror("sigprocmask()");

return 0;

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

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

#define _GNU_SOURCE #include #include #include #include #include #include #include void io_handler(int sig, siginfo_t* sinfo, void * add_info);

struct sigaction io_action;

struct sigaction io_action_old;

sigset_t blocked;

int main(void) printf("\nsigaction() (interrupt i/o) exersise\n");

if ( fcntl(STDIN_FILENO, F_SETFL, O_ASYNC) == -1 ) { perror("fcntl/F_SETFL");



Pages:     || 2 | 3 |


Похожие работы:

«Таблица – Сведения об учебно-методической, методической и иной документации, разработанной образовательной организацией для обеспечения образовательного процесса по направлению подготовки 081100.62 Государственное и муниципальное управление № Наименование дисциплины по учебному Наименование учебно-методических, методических и иных материалов (авторов, место п\п плану издания, год издания, тираж) История 1) Учебно-методический комплекс по дисциплине История, 2013 г.; 1 2) Отечественная история...»

«ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ РФ КУЛЬТУРА РУССКОЙ РЕЧИ Учебно-методическое пособие для вузов Составители: Н.А. Козельская, А.В. Рудакова Воронеж 2007 2 Утверждено Научно-методическим советом филологического факультета 21 декабря 2006 г., протокол № 2. Рецензент канд. филол. наук, доцент кафедры современного русского языка Воронежского государственного педагогического университета Е.С. Большакова Учебно-методическое пособие подготовлено на кафедре общего языкознания и стилистики...»

«Уважаемые выпускники! В перечисленных ниже изданиях содержатся методические рекомендации, которые помогут должным образом подготовить, оформить и успешно защитить выпускную квалификационную работу. Рыжков, И. Б. Основы научных исследований и изобретательства [Электронный ресурс] : [учебное пособие для студентов вузов, обучающихся по направлению подготовки (специальностям) 280400 — Природообустройство, 280300 — Водные ресурсы и водопользование] / И. Б. Рыжков.— Санкт-Петербург [и др.] : Лань,...»

«Министерство образования и науки Российской Федерации САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ ПОЛИТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ РЕКЛАМА И СВЯЗИ С ОБЩЕСТВЕННОСТЬЮ Методические указания для студентов (курсовая работа) Санкт-Петербург Издательство Политехнического университета 2012 УДК 32.01 (075.8) ББК 66.0 я 73 Т 41 Тимерманис И.Е., Евсеева Л.И., Башкарев А.А., Матвеевская А.С., Тараканова Т.С. Реклама и связи с общественностью: методические указания для студентов (курсовая работа). СПб.: Изд-во Политехн....»

«0 Министерство образования и науки РФ ГОУ ВПО Сочинский государственный университет туризма и курортного дела ГОУ ВПО Филиал Сочинского государственного университета туризма и курортного дела в г. Нижний Новгород Каулина Е.М., Судонина М.Л., Карачарова С.В., Куприянова Е. М. КОНТРОЛЬНЫЕ РАБОТЫ, КУРСОВЫЕ РАБОТЫ, КУРСОВЫЕ ПРОЕКТЫ ПО СПЕЦИАЛЬНОСТИ 032102: методика подготовки и оформление Методическое пособие для студентов всех форм обучения специальности Физическая культура для лиц с отклонениями...»

«Руководителям муниципальных библиотечных организаций Белгородской области Методические рекомендации по введению эффективного контракта В соответствии с Указом Президента Российской Федерации от 07.05.2012 г. № 597 О мероприятиях по реализации государственной социальной политики, Программой поэтапного совершенствования системы оплаты труда в государственных (муниципальных) учреждениях на 2012–2018 годы, утвержденной распоряжением Правительства Российской Федерации от 26.11.2012 г. № 2190-р...»

«ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ Федеральное государственное автономное образовательное учреждение высшего профессионального образования Сибирский федеральный университет ОРГАНИЗАЦИЯ ПРЕДПРИНИМАТЕЛЬСКОЙ ДЕЯТЕЛЬНОСТИ Учебное пособие Красноярск 2010 2 Рецензенты: Организация предпринимательской деятельности: учебное пособие / И. Л. Голянд, К. А. Мухина, К. Н. Захарьин – Красноярск, 2010. ISBN Авторский коллектив: Ирина Леонидовна Голянд, Ксения Александровна Мухина Кирилл Николаевич Захарьин...»

«МИНИСТЕРСТВО ЗДРАВООХРАНЕНИЯ РЕСПУБЛИКИ БЕЛАРУСЬ БЕЛОРУССКИЙ ГОСУДАРСТВЕННЫЙ МЕДИЦИНСКИЙ УНИВЕРСИТЕТ КАФЕДРА ГИГИЕНЫ ДЕТЕЙ И ПОДРОСТКОВ Г.В. Лавриненко, Е.О. Гузик ПРОФЕССИОНАЛЬНАЯ ОРИЕНТАЦИЯ И ВРАЧЕБНО-ПРОФЕССИОНАЛЬНАЯ КОНСУЛЬТАЦИЯ ПОДРОСТКОВ Методические рекомендации Минск 2005 УДК 613.6-053.5 (075.8) ББК 51.24 я 73 Л 13 Утверждено Научно-методическим советом университета в качестве методических рекомендаций 14.12.2004 г., протокол № 4 А в т о р ы : Г.В. Лавриненко, Е.О. Гузик Р е ц е н з е н...»

«ФГУ ГНИИ ИТТ Информика Система аттестации и регистрации специалистов в области ИКТ Правила аттестации и сертификации специалистов в области ИКТ гармонизированные с требованиями Европейской организации по качеству Москва 2011 г. Этот документ является контролируемым и действителен только в оригинале или подписанная копия. Любая другая копия может быть использована лишь для получения информации. Последнее издание можно получить у менеджера по качеству. ФГУ ГНИИ ИТТ Информика Система аттестации и...»

«МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ УКРАИНЫ ДОНБАССКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ Г.Г. Литвинский УСТОЙЧИВОСТЬ ПОРОДНЫХ ОБНАЖЕНИЙ ГОРНЫХ ВЫРАБОТОК Модуль 3. Методические указания к изучению курса Механика подземных сооружений (для студентов горных специальностей) Утверждено на заседании кафедры Строительные геотехнологии Протокол N 3 от 12.04.13. Алчевск ДонГТУ 2013 УДК 622.013.2 Методические указания к изучению курса Механика подземных сооружений - Устойчивость породных обнажений...»

«В.И. ПОДОЛЬСКИЙ, Г.В. ФЕДОРОВА ИНФОРМАЦИОННЫЕ И СПРАВОЧНЫЕ ПРАВОВЫЕ СИСТЕМЫ УЧЕБНОЕ ПОСОБИЕ Москва Издательский дом БИНФА 2011 Подольский В.И., Федорова Г.В. Информационные и справочные правовые системы: Учеб. пособие Рассмотрены информационные системы в экономике, включая определение экономической информации, ее состав и структуру. Отдельная глава посвящена справочным правовым информационным системам, функциональным возможностям наиболее известных из них и критериям их выбора. В трех...»

«Федеральное агентство по образованию ГОУ ВПО Уральский государственный технический университет – УПИ Нижнетагильский технологический институт (филиал) УГТУ-УПИ УПРАВЛЕНИЕ ПРОИЗВОДСТВОМ Методические указания по самостоятельной работе студентов всех форм обучения специальностей 150101 Металлургия черных металлов, 150104 Литейное производство, 150106 Обработка металлов давлением Нижний Тагил 2008 Составитель: Л. В. Юрьева Научный редактор: доцент, канд. экон. наук М. М. Щербинин Рецензент: доцент,...»

«Любовь Яковлевна Желтовская Обучение в 4-м классе по учебнику Русский язык Л. Я. Желтовской Обучение в 4 классе по учебнику Русский язык Л.Я. Желтовской: Астрель, АСТ; Москва; 2008 ISBN 978-5-271-17874-0, 978-5-17-045286-6 Аннотация Издание содержит программу, методические рекомендации и тематическое планирование к учебнику Русский язык. 4 класс Л.Я.Желтовской. Л. Я. Желтовская. Обучение в 4-м классе по учебнику Русский язык Л. Я. Желтовской Содержание От автора 3 О необходимости усиления...»

«УДК 621.3 ББК 31.27 К 64 Рецензенты: зав. кафедрой Электроснабжение сельского хозяйства Московского агроинженерного университета им. В. П. Горячкина д-р техн. наук проф. Т. Б. Лещинская; преподаватель Республиканского заочного политехникума В. И. Арсентьев Конюхова Е. А. К 64 Электроснабжение объектов: Учеб. пособие для студ. учреждений сред. проф. образования. - М.: Издательство Мастерство, 2002.-320 с: ил. ISBN 5-294-00063-6 Рассмотрено электроснабжение промышленных и коммунально-бытовых...»

«Уважаемые выпускники! В перечисленных ниже изданиях содержатся методические рекомендации, которые помогут должным образом подготовить, оформить и успешно защитить выпускную квалификационную работу. Рыжков, И. Б. Основы научных исследований и изобретательства [Электронный ресурс] : [учебное пособие для студентов вузов, обучающихся по направлению подготовки (специальностям) 280400 — Природообустройство, 280300 — Водные ресурсы и водопользование] / И. Б. Рыжков.— СанктПетербург [и др.] : Лань,...»

«БИБЛИОГРАФИЧЕСКИЙ УКАЗАТЕЛЬ КНИГ, ПОСТУПИВШИХ В БИБЛИОТЕКУ (июнь-август) АВТОМАТИКА (681.5) 1. 681.5 П 78 Проблемы автоматизации и управления в технических системах : сборник статей Международной научно-технической конференции (Пенза, 23-25 апреля 2013 г.) / Пенз. гос. ун-т ; под ред. д.т.н., проф. М. А. Щер бакова. – Пенза : Изд-во Пенз. гос. ун-та, 2013. – 514 с. : ил. Экземпляры: всего:2 - хр1(2) БИБЛИОГРАФИЯ (01) 2. 016:9 П 91 А.С. Пушкин и декабристы : библиографический указатель / Научная...»

«МИНИСТЕРСТВО КУРОРТОВ И ТУРИЗМА КРЫМА КРЫМСКАЯ АССОЦИАЦИЯ СЕЛЬСКОГО ЗЕЛЕНОГО ТУРИЗМА ЮЖНЫЙ ФИЛИАЛ НАЦИОНАЛЬНЫЙ УНИВЕРСИТЕТ БИОРЕСУРСОВ И ПРИРОДОПОЛЬЗОВАНИЯ УКРАИНЫ КРЫМСКИЙ АГРОТЕХНОЛОГИЧЕСКИЙ УНИВЕРСИТЕТ Информационно-консультационный центр ОРГАНИЗАЦИОННО-ПРАВОВЫЕ ВОПРОСЫ РАЗВИТИЯ СЕЛЬСКОГО ЗЕЛЕНОГО ТУРИЗМА Симферополь, 2008 Методические указания Организационно-правовые вопросы развития сельского зеленого туризма разработаны в соответствии с заказом Министерства курортов и туризма Крыма....»

«Министерство образования Республики Беларусь Учреждение образования БЕЛОРУССКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНОЛОГИЧЕСКИЙ УНИВЕРСИТЕТ Кафедра экономической теории и маркетинга ОСНОВЫ МАРКЕТИНГА Учебно-методическое пособие по выполнению контрольных работ и проведению практических занятий для студентов специальностей 1-25 01 07, 1-25 01 08, 1-26 02 02, 1-26 02 03 заочной формы обучения Минск 2004 УДК 338.242 Рассмотрено и рекомендовано к изданию редакционноиздательским советом университета Составители:...»

«Министерство образования Республики Беларусь Учреждение образования Полоцкий государственный университет В. Н. КОРОВКИН, Н. А. КУЛИК ТЕОРЕТИЧЕСКАЯ МЕХАНИКА Учебно-методический комплекс для студентов строительных специальностей Под общей редакцией Н. А. Кулик Новополоцк ПГУ 2009 УДК 531(075.8) ББК 22.21я73 К68 Рекомендовано к изданию методической комиссией строительного факультета в качестве учебно-методического комплекса (протокол № 9 от 26.06.2009) АВТОРЫ: В. Н. КОРОВКИН (разделы 1, 3); Н. А....»

«Федеральное агентство по образованию Государственное образовательное учреждение высшего профессионального образования Рязанский государственный университет имени С.А. Есенина Утверждено на заседании кафедры романских языков Протокол № 12 от 25.06.08. Зав. кафедрой Л.В. Абракова ТЕОРИЯ И ПРАКТИКА ПЕРЕВОДА Учебно-методические материалы Для специальности 033200.00 — иностранный язык с дополнительной специальностью Факультет иностранных языков Курс 5, семестры 9, 10 Всего часов, включая...»










 
2014 www.av.disus.ru - «Бесплатная электронная библиотека - Авторефераты, Диссертации, Монографии, Программы»

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