Опции

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

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

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

Options (опции) поле переменной длины. Опции могут появиться в датаграммах, а могут и не появляться. Признаком наличия опций является превышение указанной в первом байте длины заголовка значения длины фиксированной части заголовка (=20).

Длина поля опций Lopc определяется по следующей формуле:

Lopc=4*Lzag - 20;

где Lzag - значение поля длина заголовка в первом байте,

20 - длина фиксированной части заголовка.

Опции должны поддерживаться всеми Internet модулями (хостами и шлюзами). Не обязательно каждая конкретная датаграмма несет опции, но нести их все же может. В некоторых приложениях опция секретности должна присутствовать во всех датаграммах. Поле опций не имеет постоянной длины. Опций может не быть, а может быть несколько.

Типы и форматы полей опций можно найти здесь.

Опциональные поля протокола IP

Существуют два формата опции:

- единичный октет с указанием типа опции

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

Октет длины поля учитывает октет типа опции, сам себя и октеты с данными для опции.

Считается, что октет типа опции состоит из трех полей:

1	бит	флаг копирования
2	бита	класс опции
5	бит	номер опции

Флаг копирования показывает, что эта опция копируется во все фрагменты при фрагментации.

0	- не копируется
1	- копируется

Классы опции

0	- управление
1	- резервировано
2	- отладка и измерения
3	- резервировано

Определены следующие опции Internet

класс	номер	длина	описание
0	0	-	Конец списка опций. Эта опция занимает лишь один октет, октет длины отсутствует.
0	1	-	Нет операции. Эта опция занимает лишь один октет. Не имеет октета длины.
0	2	11	Безопасность. Используется для поддержания безопасности, изоляции, разделения на группы пользователей (TCC), обработки кодов ограничения, соответствующих DOD требованиям.
0	3	перем	Потеря маршрута отправителя. Используется для передачи Internet датаграммы, основанной на имеющейся у отправителя информации
0	9	перем	Определение маршрута отправителя. Используется для передачи Internet датаграммы, основанной на имеющейся у отправителя информации
0	7	перем	Запись маршрута. Используется для отслеживания проходимого Internet датаграммой маршрута.
0	8	4	Идентификатор маршрута. Используется для поддержки идентификации потока.
2	4	перем	Временной штамп Internet.

Отдельные описания опций

Тип 0

00000000

End of Option List (конец списка опций)

Эта опция обозначает конец списка опций. Он может не совпадать с окончанием Internet заголовка, обозначаемым полем Internet header length. Эта опция используется после всех опций, но не после каждой. Она необходима только в том случае, если конец списка опций не совпал с окончанием Internet заголовка.

Может быть скопирован, внесен или удален при фрагментации, или по какой-либо другой причине.

Тип 1

00000001

No operation (нет действий)

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

Тип 130

Security (безопасность)

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

10000010

00001011

SSS...SSS

CCC...CCC

HHH...HHH

TCC

Поле S (security) 16 бит

Указывает один из 16 уровней безопасности (восемь из которых зарезервировано).

00000000	00000000	- не классифицировано
11110001	00110101	- конфиденциальный
01111000	10011010	- EFTO
10111100	01001101	- MMMM
01011110	00100110	- PROG
10101111	00010011	- ограниченный
11010111	10001000	- секретный
01101011	11000101	- особо секретный
00110101	11100010	- резервировано
10011010	11110001	- резервировано
01001101	01111000	- резервировано
00100100	10111101	- резервировано
00010011	01011110	- резервировано
10001001	10101111	- резервировано
11000100	11010110	- резервировано
11100010	01101011	- резервировано

Поле C (compartments) 16 бит

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

Поле H (введение ограничений) 16 бит

Значения для управления и внесения меток являются буквенно- цифровыми диаграммами и определены в документе DIAM 65-19 "Standard Security Markings".

Поле TCC (поле управления переносом) 24 бита

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

Рассматриваемый тип должен копироваться при фрагментации.



Эта опция появляется в датаграмме не более одного раза.

Тип 131

Loose Source and Record Route (Потеря отправителя и запись маршрута)

10000011

длина

указатель

данные о маршруте

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

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

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

Данные о маршруте состоят из ряда Internet адресов. Каждый Internet адрес - это 32 бита или 4 октета. Если указатель превышает длину, то маршрут отправителя пуст (поле с записями маршрута заполнено), а маршрутизация должна основываться на значениях поля с адресом получателя.

Если адрес, записанный в поле адреса получателя, был достигнут, а указатель не превысил длину, то следующий адрес в маршруте отправителя замещает адрес в поле с адресом получателя. Записанный адрес маршрута заменяет только что использованный адрес отправителя, а указатель увеличивается на 4.

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

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



При фрагментации опция должна копироваться. В датаграмме она должна появляться не более одного раза.

Тип 137

Strict Source and Record Route (Уточнить отправитель и записать маршрут)

10001001

длина

указатель

данные о маршруте

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

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

Данные о маршруте состоят из серии Internet адресов. Каждый Internet адрес - это 32 бита или 4 октета. Если указатель превышает длину, то маршрут отправителя пуст (записываемый маршрут полон), а маршрутизация основывается на значении поля с адресом получателя.

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

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

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



Опция должна копироваться при фрагментации. Появляется не более одного раза в датаграмме.

Тип 7

Record Route

(Записать маршрут)

00000111

длина

указатель

данные о маршруте

Опция записи маршрута дает средства для записи маршрута Internet датаграммы.

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

Указатель отсчитывается от начала рассматриваемой опции, а его наименьшее допустимое значение - 4.

Записываемый маршрут состоит из серии Internet адресов. Каждый Internet адрес - это 32 бита или 4 октета. Если указатель больше, чем длина опции, то поле с записываемым маршрутом заполнено. Хост - компьютер, создающий эту опцию, должен зарезервировать поле с данными о маршруте и достаточным размером, с тем, чтобы оно вместило все ожидаемые адреса. Размер этой опции не изменяется при добавлении адресов. Первоначальное содержимое поля под данные о маршруте должно быть нулевым.

Когда Internet модуль направляет датаграмму, он проверяет ее на присутствие рассматриваемой опции с записываемым маршрутом. Если она присутствует, то он вставляет свой собственный Internet адрес в качестве распознанного во внешней среде, куда эта датаграмма направлена. Вставка осуществляется в опцию записи маршрута, в то место, на которое указывает октет указателя. Указатель затем увеличивается на 4.

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

При фрагментации не копируется, присутствует лишь в первом фрагменте.



В датаграмме присутствует не более одного раза.

Тип 136

(длина 4)

Stream Identifier

(Идентификатор потока)

10001000

00000010

идентификатор потока

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

Тип 68

Internet timestamp

(Временной штамп Internet)

01000100	длина	указатель	oflw	flg
Internet адрес
Timestamp

Длина - это количество октетов в опции, которое учитывает октеты типа, длины, указателя и overflow/flag (максимальная длина 40 октетов).

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

Overflow (oflw, переполнение 4 бита) - это количество IP модулей, которые не могут произвести регистрацию временных штампов по причине отсутствия свободного места.

Flag (flg, флаги 4 бита) - это

0	- оставлять лишь временные штампы, размещенные в следующих друг за другом 32-битных словах
1	- каждому временному штампу предшествует Internet адрес регистрируемого объекта
3	- поля Internet адресов определены заранее. IP модуль лишь регистрирует свой временной штамп если его собственный адрес совпадает со следующим указанным Internet адресом.

Timestamp - это выровненный по правой границе 32-битный временной штамп в миллисекундах (относительно полуночи по Единому Времени).

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

Хост-отправитель должен создавать эту опцию так, чтобы поля для временных штампов были достаточны для размещения всей ожидаемой информации. Размер опции не изменяется при добавлении временных штампов. Первоначально содержимое поля под временные штампы должно быть заполнено нулями, либо Internet адреса должны чередоваться с нулями.

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

Если имеется место, но оно недостаточно для вставки полного временного штампа, или же счетчик переполнения сам переполнен, то исходная датаграмма рассматривается как ошибочная и уничтожается. И в том, и в другом случае на хост-отправитель должно посылаться сообщение о проблеме с ICMP параметром.

Опция временного штампа не копируется при фрагментации, а сохраняется в первом фрагменте. В датаграмме появляется не более одного раза. <



table border="0" cellpadding="0" cellspacing="0" width="100%">

Описание функций

Функция или цель протокола Internet состоит в передаче датаграммы через набор объединенных компьютерных сетей. Это осуществляется посредством передачи датаграмм от одного модуля Internet к другому до тех пор, пока не будет достигнут получатель. Модули Internet находятся на хостах и шлюзах системы Internet. Датаграммы направляются с одного модуля Internet на другой через конкретные компьютерные сети, основанные на интерпретации Internet адресов. Таким образом, одним из важных механизмов протокола Internet является Internet адрес.

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

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

Адреса имеют фиксированную длину четыре октета (32 бита). Адрес начинается с сетевого номера, за которым следует локальный адрес (называемый полем остатка "rest"). Существуют три формата или класса адресов Internet. В классе a самый старший бит нулевой. Следующие 7 бит определяют сеть. а последние 24 бита - локальный адрес. В классе b самые старшие два бита равны соответственно 1 и 0, следующие 14 бит определяют сеть, а последние 16 бит - локальный адрес. В классе с три самых старших бита равны соответственно 1,1 и 0, следующие 21 бит определяют сеть, а последние 8 бит - локальный адрес.

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

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

Примеры построения карты адресов можно найти в документе "Address Mapping".  Фрагментация. Фрагментация Internet датаграммы необходима, когда эта датаграмма возникает в локальной сети, позволяющей работать с пакетами большого размера, и затем должна пройти к получателю через другую локальную сеть, которая ограничивает пакеты меньшим размером.

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

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

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

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

Поле идентификации позволяет отличить фрагменты одной датаграммы от фрагментов другой. Модуль Internet, отправляющий Internet датаграмму, устанавливает в поле идентификации значение, которое должно быть уникальным для данной пары отправитель - получатель, а также время, в течении которого датаграмма будет активна в системе Internet. Модуль протокола, отправляющий нерасчлененную датаграмму, устанавливает в нуль флаг "more fragments" и смещение во фрагменте.

Чтобы расчленить большую Internet датаграмму, модуль протокола Internet (например, шлюз), создает две новые Internet датаграммы и копирует содержимое полей Internet заголовка из большой датаграммы в оба новых Internet заголовка. Данные из старой датаграммы делятся на две части по границе на очередном восьмом октете (64 бита). Полученная таким образом вторая часть может быть кратна 8 октетам, а может и не быть, но первая часть кратна всегда. Заказывается количество блоков первой части NFB (количество блоков фрагмента). Первая часть данных помещается в первую новую Internet датаграмму, в поле общей длины помещается длина первой датаграммы. Флаг "more fragments" устанавливается в единицу. Вторая часть данных помещается во вторую новообразованную Internet датаграмму, в поле общей длины заносится длина второй датаграммы. В поле смещения фрагмента во второй Internet датаграмме устанавливается значение такого же поля в исходной большой датаграмме, увеличенное на NFB.

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

Чтобы собрать фрагменты Internet датаграммы, модуль протокола Internet (например, модуль на хост-компьютере) объединяет Internet датаграммы, имеющие одинаковые значения в полях идентификатора, отправителя, получателя и протокола. Собственно объединение заключается в помещении данных из каждого фрагмента в позицию, указанную в заголовке Internet пакета в поле "fragment offset". Первый фрагмент будет иметь в поле "fragment offset" нулевое значение, а последний фрагмент будет иметь флаг "more fragments", вновь установленный в нуль. <

Ошибки

Ошибки Internet заголовка могут быть оглашены посредством ICMP сообщений. <

Отображение физических адресов на IP-адреса: протоколы ARP и RARP

В протоколе IP-адрес узла, то есть адрес компьютера или порта маршрутизатора, назначается произвольно администратором сети и прямо не связан с его локальным адресом, как это сделано, например, в протоколе IPX. Подход, используемый в IP, удобно использовать в крупных сетях и по причине его независимости от формата локального адреса, и по причине стабильности, так как в противном случае, при смене на компьютере сетевого адаптера это изменение должны бы были учитывать все адресаты всемирной сети Internet (в том случае, конечно, если сеть подключена к Internet'у).

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

Для определения локального адреса по IP-адресу используется протокол разрешения адреса Address Resolution Protocol, ARP. Протокол ARP работает различным образом в зависимости от того, какой протокол канального уровня работает в данной сети - протокол локальной сети (Ethernet, Token Ring, FDDI) с возможностью широковещательного доступа одновременно ко всем узлам сети, или же протокол глобальной сети (X.25, frame relay), как правило не поддерживающий широковещательный доступ. Существует также протокол, решающий обратную задачу - нахождение IP-адреса по известному локальному адресу. Он называется реверсивный ARP - RARP (Reverse Address Resolution Protocol) и используется при старте бездисковых станций, не знающих в начальный момент своего IP-адреса, но знающих адрес своего сетевого адаптера.

В локальных сетях протокол ARP использует широковещательные кадры протокола канального уровня для поиска в сети узла с заданным IP-адресом.

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

0 8 16 31

Тип сети	Тип протокола
Длина локального адреса	Длина сетевого адреса	Операция
Локальный адрес отправителя (байты 0 - 3)
Локальный адрес отправителя (байты 4 - 5)	IP-адрес отправителя (байты 0-1)
IP-адрес отправителя (байты 2-3)	Искомый локальный адрес (байты 0 - 1)
Искомый локальный адрес (байты 2-5)
Искомый IP-адрес (байты 0 - 3)

Рис. 3.2. Формат пакета протокола ARP

В поле типа сети для сетей Ethernet указывается значение 1. Поле типа протокола позволяет использовать пакеты ARP не только для протокола IP, но и для других сетевых протоколов. Для IP значение этого поля равно 080016.

Длина локального адреса для протокола Ethernet равна 6 байтам, а длина IP-адреса - 4 байтам. В поле операции для ARP запросов указывается значение 1 для протокола ARP и 2 для протокола RARP.

Узел, отправляющий ARP-запрос, заполняет в пакете все поля, кроме поля искомого локального адреса (для RARP-запроса не указывается искомый IP-адрес). Значение этого поля заполняется узлом, опознавшим свой IP-адрес.

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

Отображение символьных адресов на IP-адреса: служба DNS

DNS (Domain Name System) - это распределенная база данных, поддерживающая иерархическую систему имен для идентификации узлов в сети Internet. Служба DNS предназначена для автоматического поиска IP-адреса по известному символьному имени узла. Спецификация DNS определяется стандартами RFC 1034 и 1035. DNS требует статической конфигурации своих таблиц, отображающих имена компьютеров в IP-адрес. Подробнее...

Padding (Выравнивание)

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

Порядок передачи данных

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

01234567	89012345	67890123	45678901
1	2	3	4
5	6	7	8
9	10	11	12

Рис. 10 Порядок передачи байтов

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

0	1	2	3	4	5	6	7
1	0	1	0	1	0	1	0

Рис. 11 Старшинство битов

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

 

Пример минимальной Internet датаграммы, несущей

Пример минимальной Internet датаграммы, несущей данные

Ver = 4	IHL = 5	Type of Service	Total Length = 21
Identification = 111	Flg = 0	Fragment Offset = 0
Time = 123	Protocol = 1	Header Checksum
Source Address
Destination Address
data	.

Рис. 5 Пример Internet датаграммы
Напомним, что каждая метка означает место для одного бита. Здесь приведена Internet датаграмма версии 4 Internet протокола. Internet заголовок состоит из пяти 32 битных слов, а общая длина датаграммы составляет 21 октет. Данная датаграмма является полноценной датаграммой (а не фрагментом).


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

Ver = 4	IHL = 5	Type of Service	Total Length = 472
Identification = 111	Flg = 0	Fragment Offset = 0
Time = 123	Protocol = 6	Header Checksum
Source Address
Destination Address
data
data data
data	.

Рис. 6 Пример Internet датаграммы
Теперь приведем первый фрагмент, который возникает при расщеплении исходной датаграммы по границе после 256 октета данных.

Ver = 4	IHL = 5	Type of Service	Total Length = 276
Identification = 111	Flg = 1	Fragment Offset = 0
Time = 119	Protocol = 6	Header Checksum
Source Address
Destination Address
data
data data
data

Рис. 7 Пример Internet фрагмента
и второй фрагмент

Ver = 4	IHL = 5	Type of Service	Total Length = 216
Identification = 111	Flg = 0	Fragment Offset = 32
Time = 119	Protocol = 6	Header Checksum
Source Address
Destination Address
data
data data
data	.

Рис. 8 Пример Internet заголовка


Здесь мы показываем пример, когда датаграмма имеет опции

Ver = 4	IHL = 8	Type of Service	Total Length = 576
Identification = 111	Flg = 0	Fragment Offset = 32
Time = 123	Protocol = 6	Header Checksum
Source Address
Destination Address
Opt.Code = x	Opt.Len. = 3	option value	Opt.Code = x
Opt.Len. = 4	option value	Opt.Code = 1
Opt. Code = y	Opt.Len. = 3	option value	Opt. Code = 0
data
data data

Рис. 9 Пример Internet датаграммы

Пример интерфейса с вышестоящим уровнем

Два примера вызовов, приведенные ниже, удовлетворяют запросы пользователя в общении с Internet протоколом (символ "=>" означает возвращаемое значение).

SEND(src,dst,prot,TOS,TTL,BufPTR,len,Id,DF,opt => result)

где

src	- адрес отправителя
dst	- адрес получателя
prot	- протокол
TOS	- тип сервиса
TTL	- время жизни
BufPTR	- указатель буфера
len	- длина данных в буфере
Id	- идентификатор
DF	- запрет фрагментации
opt	- опции
result	- ответ:
	Ok	- успешная посылка датаграммы
	Error	- ошибка в аргументах функции или в локальной сети

Заметим, что тип сервиса TOS включает приоритет, а требование безопасности передается в качестве опции.

RECV(BufPTR,prot => result,src,dst,TOS,len,opt)

BufPTR	- указатель буфера
prot	- протокол
result	- ответ:
	Ok	- успешное получение датаграммы
	Error	- ошибка в аргументах
len	- длина буфера
src	- адрес отправителя
dst	- адрес получателя
TOS	- тип сервиса
opt	- опции

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

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

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

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

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

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

Данная глава характеризует функции интерфейса между пользователем и Internet протоколом. Используемые обозначения аналогичны большинству процедур функций вызовов на языках высокого уровня, однако данный способ обращения с Internet протоколом не является правилом для запросов на обслуживание типа ловушек (т.е. SVC, UUO, EMT), или для любой другой формы общения между процессами. <

Пример процедуры фрагментации

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

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

Обозначения:

FO	- смещение фрагмента
IHL	- длина Internet заголовка
DF	- флаг запрета фрагментации
MF	- флаг появления дополнительных фрагментов
TL	- общая длина
OFO	- старое смещение фрагмента
OIHL	- старая длина Internet заголовка
OMF	- старое значение флага появление дополнительных фрагментов
OTL	- старое значение общей длины
NFB	- количество блоков фрагментации
MTU	- максимальная длина переноса

Процедура

IF TL =< MTU THEN отправить датаграмму на следующие процедуры обработки

ELSE

IF DF =1 THEN разрушить датаграмму

ELSE

создать первый фрагмент

(1)	скопировать исходный Internet заголовок;
(2)	OIHL <- IHL; OTL <- TL; OMF <- MF;
(3)	NFB <- (MTU - IHL*4)/8;
(4)	взять первые NFB*8 октетов данных;
(5)	скорректировать заголовок: MF <- 1; TL <- (IHL*4)+(NFB*8); пересчитать контрольную сумму;
(6)	направить данный фрагмент на последующие процедуры обработки создать второй фрагмент:
(7)	выборочно скопировать Internet заголовок (некоторые опции не копируются, см. определение опций)
(8)	добавить оставшиеся данные
(9)	скорректировать заголовок IHL <- (((OIHL*4)-(длина не скопированных опций))+3)/4; TL <- OTL - NFB*8 - (OIHL-IHL)*4; FO <- OFO + NFB; MF <- OMF; пересчитать контрольную сумму;
(10)	Приготовить этот фрагмент к повторному тесту на необходимость фрагментации. Выполнить.

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

Пример процедуры сборки

Для каждой датаграммы идентификатор буфера определяется как объединение полей адреса отправителя, адреса получателя, протокола и идентификации. Если это целая датаграмма (поля fragment offset и more fragments нулевые), то все ресурсы, связанные с этим идентификатором буфера, освобождаются, а сама датаграмма направляется на следующие процедуры обработки.

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

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

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

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

Например, скорость получения данных следует умножать на размер буфера (т.е. 10 КБайт/сек * 15 сек = 150 КБайт).
Обозначения

FO	- смещение фрагмента
IHL	- длина Internet заголовка
MF	- флаг More Fragments
TTL	- время жизни
NFB	- количество фрагментов
TL	- общая длина
TDL	- общая длина данных
BUFID	- идентификатор буфера
RCVBT	- битовая таблица фрагментации
TLB	- нижняя граница для значения таймера

Процедура

(1) BUFID <- отправитель|получатель|протокол|идентификация;
(2) IF FO = 0 AND MF = 0 THEN
(3) IF буфер с идентификатором BUFID выделены THEN
(4) завершить сборку для этого идентификатора BUFID;
(5) Приготовить датаграмму для дальнейшей обработки.
Запустить обработку
(6) ELSE
IF буфер для идентификатора BUFID не выделен THEN
(7) выделить ресурсы для сборки с идентификатором BUFID
TIMER <- TLB; TDL <- 0;
(8) перенести данные из фрагмента в буфер данных с идентификатором
BUFID, данные с октета FO*8 по октет (TL-(IHL*4))+FO*8;
(9) установить биты RCVBT с FO по FO+((TL-(IHL*4)+7)/8);
(10) IF MF = 0 THEN TDL <- TL-(IHL*4)+(FO*8)
(11) IF FO = 0 THEN поместить заголовок в буфер заголовка
(12) IF TDL # 0 AND все биты RCVBT с 0 по (TDL+7)/8 выставлены THEN
(14) TL <- TDL+(IHL*4)
(15) Приготовить датаграмму к дальнейшей обработке
(16) Освободить все ресурсы сборки для этого идентификатора
BUFID. Запустить обработку.
(17) TIMER <- MAX(TIMER,TTL);
(18) приостановить работу до получения следующего фрагмента или
сигнала от таймера
(19) Сигнал от таймера:
Освободить все ресурсы, связанные с этим идентификатором BUFID.
В случае, если два или более фрагмента содержат одни и те же данные, либо идентичны или частично перекрываются, то эта процедура будет использовать последнюю полученную копию при создании буфера данных и воссоздании датаграммы.

Приоритет

111	- управление сетью
110	- межсетевое управление
101	- CRITIC/ECP
100	- более, чем мгновенно
011	- мгновенно
010	- немедленно
001	- приоритетно
000	- обычный маршрут

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

Тип обслуживания используется для указания типа обработки датаграммы при ее прохождении через систему Internet. Примеры отображения типа обслуживания в протоколе Internet на реальные услуги, предоставляемые такими сетями, как AUTODIN II, ARPANET, SATNET и PRNET даны в документе "Service Mapping" [8]. Значение "управление сетью" следует присваивать приоритету только для использования внутри локальной сети. Управление и реальное использование этого аргумента должно находиться в согласии с каждой применяющей его сетью. Аргумент "межсетевое управление" предназначен только для использования шлюзами, берущими на себя управление. Если вышеописанные аргументы приоритета находят применение в какой-либо сети, то это означает, что данная сеть может управлять приемом и использованием этих аргументов.

Protocol (Протокол) 8 бит

Это поле показывает, какой протокол следующего уровня использует данные из Internet датаграммы. Значение поля определяется рекомендациями RFC (RFC1700). Неполный список основных типов протоколов приведен здесь.

Протокол ICMP

Протокол Internet (IP) используется для обработки датаграммы, передаваемой между хост-компьютерами в системе объединенных сетей. Устройства, осуществляющие соединение различных сетей, называются шлюзами. Для обеспечения управления шлюзы общаются друг с другом посредством протокола Gateway to Gateway Protocol (GGP). Порой шлюз или хост-компьютер, получающий данные, обменивается информацией с хост-компьютером, отправляющим эти данные. Именно для таких целей используется данный протокол - протокол контрольных сообщений Internet (ICMP). ICMP использует основные свойства протокола Internet (IP), как если бы ICMP являлся протоколом более высокого уровня. Однако фактически ICMP является составной частью протокола Internet и должен являться составной частью каждого модуля IP.

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

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

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

Протокол ICMPv6 отличается от ICMPv4

Протокол ICMPv6 отличается от ICMPv4 только теми параметрами, которые напрямую связаны со структурой IP-пакета: изменился идентификатор ICMPv6, который определяет тип заголовка (Next Header), изменились коды типов сообщений ICMPv6, добавились параметры для типов сообщений, которые работают с вложенными заголовками и т. д.

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

Подробное описание ICMPv6 можно найти в RFC-1885. <

Протокол IP

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

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

с тех пор основные принципы

Развитие стека TCP/IP: протокол IPv.6

Технология стека TCP/IP сложилась в основном в конце 1970-х годов и с тех пор основные принципы работы базовых протоколов, таких как IP, TCP, UDP и ICMP, практически не изменились. Однако, сам компьютерный мир за эти годы значительно изменился, поэтому долго назревавшие усовершенствования в технологии стека TCP/IP сейчас стали необходимостью.

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

	Повышение производительности компьютеров и коммуникационного оборудования. За время существования стека производительность компьютеров возросла на два порядка, объемы оперативной памяти выросли более чем в 30 раз, пропускная способность магистрали Internet в Соединенных Штатах выросла в 800 раз.
	Появление новых приложений. Коммерческий бум вокруг Internet и использование ее технологий при создании intranet привели к появлению в сетях TCP/IP, ранее использовавшихся в основном в научных целях, большого количества приложений нового типа, работающих с мультимедийной информацией. Эти приложения чувствительны к задержкам передачи пакетов, так как такие задержки приводят к искажению передаваемых в реальном времени речевых сообщений и видеоизображений. Особенностью мультимедийных приложений является также передача очень больших объемов информации. Некоторые технологии вычислительных сетей, например, frame relay и ATM, уже имеют в своем арсенале механизмы для резервирования полосы пропускания для определенных приложений. Однако эти технологии еще не скоро вытеснят традиционные технологии локальных сетей, не поддерживающие мультимедийные приложения (например, Ethernet). Следовательно, необходимо компенсировать такой недостаток средствами сетевого уровня, то есть средствами протокола IP.
	Бурное расширение сети Internet. В начале 90-х годов сеть Internet расширялась очень быстро, новый узел появлялся в ней каждые 30 секунд, но 95-й год стал переломным - перспективы коммерческого использования Internet стали отчетливыми и сделали ее развитие просто бурным. Первым следствием такого развития стало почти полное истощение адресного пространства Internet, определяемого полем адреса IP в четыре байта.
	Новые стратегии администрирования. Расширение Internet связано с его проникновением в новые страны и новые отрасли промышленности. При этом в сети появляются новые органы администрирования, которые начинают использовать новые методы администрирования. Эти методы требуют появления новых средств в базовых протоколах стека TCP/IP.

<



/p>

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

Основным предложением по модернизации протокола IP является предложение, разработанное группой IETF. Сейчас принято называть ее предложение версией 6 - IPv6, а все остальные предложения группируются под названием IP Next Generation, IPng.

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

	Использование более длинных адресов. Новый размер адреса - наиболее заметное отличие IPv6 от IPv4. Версия 6 использует 128-битные адреса.
	Гибкий формат заголовка. Вместо заголовка с фиксированными полями фиксированного размера (за исключением поля Резерв), IPv6 использует базовый заголовок фиксированного формата плюс набор необязательных заголовков различного формата.
	Поддержка резервирования пропускной способности. В IPv6 механизм резервирования пропускной способности заменяет механизм классов сервиса версии IPv4.
	Поддержка расширяемости протокола. Это одно из наиболее значительных изменений в подходе к построению протокола - от полностью детализированного описания протокола к протоколу, который разрешает поддержку дополнительных функций.

Литература



Подробная информация о протоколе IPv6 и его использовании можно найти в RFC-1752, RFC- 1826, RFC- 1827, RFC – 1883, RFC- 1885, RFC- 1887, RFC- 1924, RFC- 1971, RFC 2073.

Протокол передачи видео- и аудиоинформации в реальном масштабе времени — RTP

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

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

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

Эту задачу и призван решить новый транспортный протокол реального времени — RTP (Real-Time Transport Protocol), который гарантирует доставку данных одному или более адресатам с задержкой в заданных пределах, т. е. данные могут быть воспроизведены в реальном времени.

Принципы построения протокола RTP

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

Примечание

Для каждого участника RTP сеанс определяется парой транспортных адресов назначения пакетов (один сетевой адрес — IP и пара портов: RTP и RTCP).

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

Наличие такой информации позволяет оценить величину начальной задержки и объема буфера передачи.



Примечание



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

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

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



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



Методы контроля работы



Протокол RTP используется только для передачи пользовательских данных — обычно многоадресной — всем участникам сеанса. Совместно с RTP работает протокол RTCP (Real-time Transport Control Protocol), основная задача которого состоит в обеспечении управления передачей RTP. RTCP использует тот же самый базовый транспортный протокол, что и RTP (обычно UDP), но другой номер порта.

RTCP выполняет несколько функций:

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

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



Оценка размеров сеанса и масштабирование. Для обеспечения качества услуг и обратной связи с целью управления загруженностью, а также с целью идентификации отправителя, все участники периодически посылают пакеты RTCP. Частота передачи этих пакетов снижается с ростом числа участников. При небольшом числе участников один пакет RTCP посылается максимум каждые 5 секунд. RFC-1889 описывает алгоритм, согласно которому участники ограничивают частоту RTCP-пакетов в зависимости от общего числа участников. Цель состоит в том, чтобы трафик RTCP не превышал 5% от общего трафика сеанса.



Формат заголовка протокола RTP



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

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

Использование TCP в качестве транспортного протокола для этих приложений невозможно по нескольким причинам:



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

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

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



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

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



Эту задачу и призван решить новый транспортный протокол реального времени — RTP (Real-time Transport Protocol), который гарантирует доставку данных одному или более адресатам с задержкой в заданных пределах, т. е. данные могут быть воспроизведены в реальном времени.

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

0

2

3

4

8

16

31

V=2	P	X	CC	M	PT	Sequence Number
Timestamp
Synchronization Source (SSRC) Identifier
Contributing Source (CSRC) Identifiers

Рис. 1. Фиксированный RTP-заголовок.

V (2 бита). Поле версии. Текущая версия — вторая.



Р (1 бит). Поле заполнения. Это поле сигнализирует о наличии заполняющих октетов в конце полезной нагрузки. Заполнение применяется, когда приложение требует, чтобы размер полезной нагрузки был кратен, например, 32 битам. В этом случае последний октет указывает число заполняющих октетов.



Х (1 бит). Поле расширения заголовка. Когда это поле задано, то за основным заголовком следует еще один дополнительный, используемый в экспериментальных расширениях RTP.



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



М (1 бит). Поле маркера. Смысл бита маркера зависит от типа полезной нагрузки. Бит маркера используется обычно для указания границ потока данных. В случае видео он задает конец кадра. В случае голоса он задает начало речи после периода молчания.



РТ (7 бит). Поле типа полезной нагрузки. Это поле идентифицирует тип полезной нагрузки и формат данных, включая сжатие и шифрование. В стационарном состоянии отправитель использует только один тип полезной нагрузки в течение сеанса, но он может его изменить в ответ на изменение условий, если об этом сигнализирует протокол управления передачей в реальном времени (Real-Time Transport Control Protocol).



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



Timestamp (32 бита). Поле отметки о времени. Это поле содержит момент времени, в который первый октет данных полезной нагрузки был создан. Единицы, в которых время указывается в этом поле, зависят от типа полезной нагрузки. Значение определяется по локальным часам отправителя.



Synchronization Source (SSRC) Identifier (32 бита). Поле идентификатора источника синхронизации: генерируемое случайным образом число, уникальным образом идентифицирующее источник в течение сеанса и независимое от сетевого адреса. Это число играет важную роль при обработке поступившей порции данных от одного источника.



Contributing source (CSRC) Identifier (32 бита). Список полей идентификаторов источника, "подмешанных" в основной поток, например, с помощью микшера. Микшер вставляет целый список SSRC идентификаторов источников, которые участвовали в построении данного RTP-пакета. Этот список и называется CSRC. Количество элементов в списке: от 0 до 15. Если число участников более 15 — выбираются первые 15. Примером может служить аудио-конференция, в RTP-пакеты которой собраны речи всех участников, каждый со своим SSRC — они-то и образуют список CSRC. При этом вся конференция имеет общий SSRC.

Протокол RTCP, как и всякий управляющий протокол, значительно сложнее и по структуре, и по выполняемым функциям (сравните, например, протоколы IP и TCP). Хотя основу протокола RTCP составляет RTP, он содержит множество дополнительных полей, с помощью которых он реализует свои функции.

Решить проблему приоритетности для чувствительных к задержкам данных, в противовес традиционным данным, для которых задержки не столь критичны, призван протокол резервирования ресурсов — RSVP, находящийся в настоящее время на рассмотрении в группе инженерной поддержки Internet (IETF). RSVP позволяет конечным системам резервировать сетевые ресурсы для получения необходимого качества услуг, в особенности ресурсы для графика реального времени по протоколу RTP. RSVP касается прежде всего маршрутизаторов, хотя приложения в конечных узлах также должны знать, как использовать RSVP в целях резервирования необходимой полосы пропускания для данного класса услуг или уровня приоритета.

RTP вместе с другими описанными стандартами позволяет с успехом передавать видео и аудио по обычным IP-сетям. RTP/RTCP/RSVP — стандартизованное решение для сетей с передачей данных в реальном времени. Единственным его недостатком является то, что оно предназначено только для IP-сетей. Однако это ограничение временное: сети так или иначе будут развиваться в этом направлении. Данное решение обещает решить проблему передачи чувствительных к задержкам данных по Internet.



Литература



Описание протокола RTP можно найти в RFC-1889.

 <



table border="0" cellpadding="0" cellspacing="0" width="100%">

Протокол резервирования ресурсов RSVP

Протокол резервирования ресурсов RSVP (Resource Reservation Protocol) позволяет конечным системам резервировать сетевые ресурсы для получения необходимого качества услуг. Отправители предоставляют маршрутизаторам общие характеристики трафика (например, темп передачи данных, вариабельность), получатели определяют требуемый уровень качества услуг. Маршрутизаторы сводят затем воедино запросы на выделение ресурсов на общих участках маршрутов движения полезной нагрузки. Протокол активно используется маршрутизаторами фирмы CISCO для передачи видео и речевой информации. <

Сценарий работы

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

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

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

Модуль передает данную датаграмму и адрес в локальной сети в распоряжение интерфейса локальной сети.

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

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

Интерфейс создает заголовок локальной сети и соединяет с ним датаграмму, а затем результат направляет на хост-получатель. На хосте-получателе интерфейс локальной сети удаляет заголовок локальной сети и передает оставшееся на Internet модуль.

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

Рис. 2 Путь передачи датаграммы

Соглашения о специальных адресах: broadcast, multicast, loopback

В протоколе IP существует несколько соглашений об особой интерпретации IP-адресов:

если IР-адрес состоит только из двоичных нулей,

0 0 0 0 ................................... 0 0 0 0

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

если в поле номера сети стоят 0,

0 0 0 0 .......0

Номер узла

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

если все двоичные разряды IP-адреса равны 1,

1 1 1 1 .........................................1 1

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

если в поле адреса назначения стоят сплошные 1,

Номер сети

1111................11

то пакет, имеющий такой адрес рассылается всем узлам сети с заданным номером. Такая рассылка называется широковещательным сообщением (broadcast);

адрес 127.0.0.1 зарезервирован для организации обратной связи при тестировании работы программного обеспечения узла без реальной отправки пакета по сети. Этот адрес имеет название loopback.

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

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

Спецификация протокола IP

	Формат заголовка Internet
	Коментарии
	Интерфейсы
	Примеры и сценарии

Структура протокольного блока

Разряды								Описание
7	6	5	4	3	2	1	0
Версия = 4 протокола				Длина заголовка дейтаграммы
1 байт								Type of Service Вид обслуживания
старший байт								Общая длина дейтаграммы в байтах
младший байт
старший байт								Identification Идентификатор дейтаграммы Формируется исходным абонентом, формирующим дейтаграмму, служит для идентификации конкретной дейтаграммы. Выглядит как 16-ти разрядный счетчик
младший байт
O DF MF Flags				Смещение фрагмента старшая тетрада				Поле флагов и поля смещения фрагмента данных от начала исходного блока данных (используется при сегментации)
младший байт
1 байт								Time to Live Время жизни Поле показывает количество переходов через маршрутизаторы
1 байт								Protocol. Тип следующего протокола
2 байта								Header Checksum Контрольная сумма заголовка
старший байт								Source Address Адрес отправителя
1 байт
1 байт
младший байт
старший байт								Адрес получателя Destination Address
1 байт
1 байт
младший байт
. .  .								Options Поле дополнительных услуг (может отсутствовать) Длина поля дополнительных услуг определяется как разность заданной длины заголовка и размера фиксированной части.
1, 2 или 3 байта								Padding (Выравнивание) Выравнивание Internet заголовка используется для того, чтобы убедиться в том, Internet заголовок заканчивается на 32-битной границе. Выравнивание осуществляется нулями.
. . .								Данные

Связь с другими протоколами

Следующая диаграмма иллюстрирует место протокола Internet в иерархии протоколов.

Рис. 1 Взаимодействие протоколов

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

Time to Live (Время жизни) 8 бит

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

Тип обслуживания

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

Приоритет. Независимая единица измерения для важности данной датаграммы.

Задержка. Указание задержки важно для датаграмм с этим знаком.

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

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

Например, сеть ARPANET имеет бит приоритета, а также выбор между "стандартными" сообщениями (тип 0) и "неконтролируемыми" (тип 3) (также в качестве одного из сервисных параметров может использоваться выбор между единичным пакетом и многопакетными сообщениями). Неконтролируемые сообщения имеют тенденцию иметь меньшую достоверность, но и меньшую задержку. Допустим, Internet датаграмма должна быть передана через сеть ARPANET.

Пусть тип Internet сервиса определен как

приоритет:	5
задержка:	0
пропускная способность:	1
достоверность:	1

В рассматриваемом примере отображение описанных параметров на параметры, допустимые в сети ARPANET, привело бы к установке бита приоритета ARPANET (поскольку приоритет Internet находится в верхней половине своего диапазона), выбору стандартного типа сообщений (поскольку указаны требования высокой пропускной способности и достоверности, а параметр задержки сброшен). Дополнительные детали реализации сервиса даны в документе "Service Mappings".

Типы адресов: физический (MAC-адрес), сетевой (IP-адрес) и символьный (DNS-имя)

Каждый компьютер в сети TCP/IP имеет адреса трех уровней:

Локальный адрес узла, определяемый технологией, с помощью которой построена отдельная сеть, в которую входит данный узел. Для узлов, входящих в локальные сети - это МАС-адрес сетевого адаптера или порта маршрутизатора, например, 11-А0-17-3D-BC-01. Эти адреса назначаются производителями оборудования и являются уникальными адресами, так как управляются централизовано. Для всех существующих технологий локальных сетей МАС-адрес имеет формат 6 байтов: старшие 3 байта - идентификатор фирмы производителя, а младшие 3 байта назначаются уникальным образом самим производителем. Для узлов, входящих в глобальные сети, такие как Х.25 или frame relay, локальный адрес назначается администратором глобальной сети.

IP-адрес, состоящий из 4 байт, например, 109.26.17.100. Этот адрес используется на сетевом уровне. Он назначается администратором во время конфигурирования компьютеров и маршрутизаторов. IP-адрес состоит из двух частей: номера сети и номера узла. Номер сети может быть выбран администратором произвольно, либо назначен по рекомендации специального подразделения Internet (Network Information Center, NIC), если сеть должна работать как составная часть Internet. Обычно провайдеры услуг Internet получают диапазоны адресов у подразделений NIC, а затем распределяют их между своими абонентами.

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

Символьный идентификатор-имя, например, SERV1.IBM.COM. Этот адрес назначается администратором и состоит из нескольких частей, например, имени машины, имени организации, имени домена. Такой адрес, называемый также DNS-именем, используется на прикладном уровне, например, в протоколах FTP или telnet.

Толковый словарь

1822 BBN доклад 1822, "The Specification of the Interconnection of a Host and an IMP". Спецификация взаимодействия между хост-компьютером и сетью ARPANET.

ARPANET проводник

Управляющая информация в ARPANET сообщении для интерфейса между хост-компьютером и IMP процессором.

ARPANET сообщение

Единица передачи между хост-компьютером и IMP процессором в сети ARPANET. Максимальный ее размер примерно 1012 октетов (8096 битов).

ARPANET пакет

Единица передачи внутри сети ARPANET между IMP процессорами. Максимальный размер ее около 126 октетов (1008 бит).

Destination (Получатель)

Адрес получателя, поле в Internet заголовке.

DF

Бит запрета фрагментации в поле флагов.

Flags (Флаги)

Поле Internet заголовка, содержащее различные управляющие биты.

Fragment Offset (Смещение фрагмента)

Это поле Internet заголовка указывает, к какому месту в Internet датаграмме относится фрагмент.

GGP

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

header (заголовок)

Управляющая информация в начале сообщения, сегмента, датаграммы, пакета или блока данных.

ICMP

Internet Control Message Protocol - Протокол контрольных сообщений Internet. Поддерживаемое Internet модулем, ICMP сообщение передается от шлюзов к хост-компьютерам и между хост-компьютерами, используется для отчетов об ошибках а также для создания предположений о маршрутизации.

Identification (Идентификация)

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

IHL

The Internet Header Length - Поле Internet заголовка. Представляет собой длину Internet заголовка, измеренную в 32-битных словах.

IMP

The Interface Message Processor - Процессор сообщений интерфейса. Пакетный переключатель сети ARPANET.

Internet Address (адрес Internet)

Четырехоктетный (32 бита) адрес отправителя или получателя. Состоит из поля сети и поля локального адреса.

Internet фрагмент

Порция данных из Internet датаграммы, снабженная Internet заголовком.

Local Address (локальный адрес)

Адрес хост-компьютера внутри какой-либо сети. Реальное отображение локального адреса Internet на адреса хост-компьютеров в сети довольно произвольное, что позволяет отображать несколько локальных адресов на один хост-компьютер.

MF

Флаг появления дополнительных фрагментов, содержащийся в поле флагов Internet заголовка

module (модуль)

Реализация, обычно программная, протокола или других процедур

more-fragments flag (флаг дополнительных фрагментов)

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

NFB

The Number of Fragments Blocks - количество блоков фрагментации с данными в Internet фрагменте. Иными словами, длина поля с данными. Единица измерения - 8 октет.

octet (октет)

байт с восемью битами

Options (опции)

Поле опций Internet заголовка, может содержать несколько опций. Каждая опция может иметь длину в несколько октет. Padding (Выравнивание)

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

Protocol (Протокол)

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

Rest (Остаток)

Часть Internet адреса, указывающая локальный адрес.

Source (Отправитель)

Адрес отправителя, поле Internet заголовка.

TCP

Transmission Control Protocol - Протокол управления передачей. Протокол общения между хост-компьютерами для осуществления коммуникаций в среде Internet.

TCP сегмент

Единица данных, передаваемая между TCP модулями (имеющая TCP заголовок).

TFTP

Trivial File Transfer Protocol: Простой протокол передачи файлов, созданный для UDP.

Time to Live (Время жизни)

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

TOS

Тип сервиса Total length (общая длина)

Поле Internet заголовка Total Length, определяющее длину датаграммы в октетах, включающее Internet заголовок и данные.

TTL

Время жизни

Type of Service (Тип сервиса)

Поле Internet заголовка, определяющее тип сервиса для данной Internet датаграммы.

UDP

User Datagram Protocol. Протокол на уровне пользователя для приложений, ориентированных на транзакции.

User (Пользователь)

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

Version (версия)

Поле версии, определяющее формат Internet заголовка. <

Total Length (общая длина) 16 бит

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

Значение 576 выбрано с тем, чтобы соответствующим образом ограниченный блок данных передавался вместе с требуемой информацией в заголовке. Например, этот размер позволяет заполнять датаграмму полем данных размером в 512 октетов и заголовком в 64 октета. Наибольший Internet заголовок занимает 60 октетов, а его типичный размер составляет всего 20 октетов, что оставляет место под заголовки протоколов более высокого уровня.

Identification

(идентификатор) 16 бит

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

Три основных класса IP-адресов

IP-адрес имеет длину 4 байта и обычно записывается в виде четырех чисел, представляющих значения каждого байта в десятичной форме, и разделенных точками, например:

128.10.2.30 - традиционная десятичная форма представления адреса,

10000000 00001010 00000010 00011110 - двоичная форма представления этого же адреса.

На рисунке 3.1 показана структура IP-адреса.

Класс А

0

N сети

N узла

Класс В

1

0

N сети

N узла

Класс С

1

1

0

N сети

N узла

Класс D

1

1

1

0

адрес группы multicast

Класс Е

1

1

1

1

0

зарезервирован

Рис. 3.1. Структура IР-адреса

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

	Если адрес начинается с 0, то сеть относят к классу А, и номер сети занимает один байт, остальные 3 байта интерпретируются как номер узла в сети. Сети класса А имеют номера в диапазоне от 1 до 126. (Номер 0 не используется, а номер 127 зарезервирован для специальных целей, о чем будет сказано ниже.) В сетях класса А количество узлов должно быть больше 216 , но не превышать 224.
	Если первые два бита адреса равны 10, то сеть относится к классу В и является сетью средних размеров с числом узлов 28 - 216. В сетях класса В под адрес сети и под адрес узла отводится по 16 битов, то есть по 2 байта.
	Если адрес начинается с последовательности 110, то это сеть класса С с числом узлов не больше 28. Под адрес сети отводится 24 бита, а под адрес узла - 8 битов.
	Если адрес начинается с последовательности 1110, то он является адресом класса D и обозначает особый, групповой адрес - multicast. Если в пакете в качестве адреса назначения указан адрес класса D, то такой пакет должны получить все узлы, которым присвоен данный адрес.
	Если адрес начинается с последовательности 11110, то это адрес класса Е, он зарезервирован для будущих применений.

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

Класс	Наименьший адрес	Наибольший адрес
A	01.0.0	126.0.0.0
B	128.0.0.0	191.255.0.0
C	192.0.1.0.	223.255.255.0
D	224.0.0.0	239.255.255.255
E	240.0.0.0	247.255.255.255

Type of Service (тип сервиса) 8 бит

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

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

биты 0-2	приоритет
бит 3	0 - нормальная задержка, 1 - малая задержка
бит 4	0 - нормальная пропускная способность, 1 - высокая пропускная способность
бит 5	0 - обычная достоверность, 1 - высокая достоверность
биты 6-7	зарезервированы

0	1	2	3	4	5	6	7
приоритет	D	T	R	0	0

Version (версия) 4 бита

Поле версии показывает формат заголовка Internet. Данный документ описывает версию 4.

IHL (длина Internet заголовка) 4 бита

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

Время жизни

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

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

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

Некоторые протоколы более высокого уровня, управляющие соединениями, основываются на предположении, что старые датаграммы-дубликаты не достигают цели по истечении определенного времени. TTL - это способ, с помощью которого такие протоколы могли бы убедиться, что их предположение удовлетворяется.

Библиографическая справка (NetWare)

NetWare является операционной системой сети (network operating system - NOS) и связанной с ней средой обеспечения услуг, разработанной Novell, Inc. и представленной на рынок в начале 1980 гг. В то время сети были небольшими и преимущественно гомогенными, связь рабочих групп с помощью локальных сетей была еще новым явлением, а идея о персональном компьютере еще только начала завоевывать популярность.

Большая часть технологии организации сетей NetWare была заимствована из Xerox Network Systems (XNS)

- системы организации сетей, разработанной Xerox Corporation в конце 1970 гг. Подробная информация о XNS   в разделе "XNS".

K началу 1990 гг. доля в рынке NOS NetWare возросла до 50-75 % (данные зависят от исследовательских групп, занимавшихся изучением рынка). Установив свыше 500,000 сетей NetWare по всему миру и ускорив продвижение по пути об'единения сетей с другими сетями, NetWare и подддерживающие ее протоколы часто сосуществуют на одном и том же физическом канале с многими другими популярными протоколами, в том числе ТСР/IP, DECnet и AppleTalk.

  <

Доступ к среде (NetWare)

NetWare работает с Ethenet/IEEE 802.3, Token Ring/IEEE 802.5, Fiber Distributed Data Interface (FDDI) и ARCnet.  NetWare также работает в синхронных каналах глобальных сетей, использующих Point-to-Point Protocol (PPP) (Протокол непосредственных соединений).

ARСnet представляет собой систему простой сети, которая поддерживает все три основных носителя (скрученную пару, коаксиальный кабель и волоконно-оптический кабель) и две топологии (шина и звезда). Она была разработана корпорацией Datapoint Corporation и выпущена в 1977. Хотя ARCnet не приобрела такую популярность, какой пользуются Ethernet и Token Ring, ее гибкость и низкая стоимость завоевали много верных сторонников. <

Протоколы высших уровней (NetWare)

NetWare поддерживает большое разнообразие протоколов высших уровней; некоторые из них несколько более популярны, чем другие. NetWare shell (командный процессор) работает в оборудовании клиентов (которое часто называется рабочими станциями среди специалистов по NetWare) и перехватывает обращения прикладных задач к устройству Ввод/Вывод, чтобы определить, требуют ли они доступ к сети для удовлетворения запроса. Если это так, то NetWare shell организует пакеты запросов и отправляет их в программное обеспечение низшего уровня для обработки и передачи по сети. Если это не так, то они просто передаются в ресурсы местного устройства Ввода/Вывода. Прикладные задачи клиента не осведомлены о каких-либо доступах к сети, необходимых для выполнения обращений прикладных задач. NetWare Remote Procedure Call (Netware RPC) (Вызов процедуры обращения к отдаленной сети) является еще одним более общим механизмом переадресации, поддерживаемым Novell.

Netware Core Protocol (NCP) (Основной протокол NetWare) представляет собой ряд программ для сервера, предназначенных для удовлетворения запросов прикладных задач, приходящих, например, из NetWare shell. Услуги, предоставляемые NCP, включают доступ к файлам, доступ к принтеру, управление именами, учет использования ресурсов, защиту данных и синхронизацию файлов.

NetWare также поддерживает спецификацию интерфейса сеансового уровня Network Basic I/O System (NetBIOS) компаний IBM и Microsoft. Программа эмуляции NetBIOS, обеспечиваемая NetWare, позволяет программам, написанным для промышленного стандартного интерфейса NetBIOS, работать в пределах системы NetWare.

Услуги прикладного уровня NetWare включают NetWare Message Handling Service (NetWare MHS) (Услуги по обработке сообщений), Btrieve, NetWare Loadable Modules (NLM)

(Загружаемые модули NetWare) и различные характеристики связности IBM. NetWare MHS является системой доставки сообщений, которая обеспечивает транспортировку электронной почты. Btrieve представляет собой реализацию механизма доступа к базе данных двоичного дерева (btree) Novell. NLM реализуются как дополнительные модули, которые подключаются к системе NetWare. В настоящее время компания Novell и третьи участвующие стороны предоставляют NLM для чередующихся комплектов протоколов (alternate protocol stacks), услуги связи, услуги доступа к базе данных и много других услуг. <

Сетевая архитектура NetWare

В качестве среды NOS, NetWare определяет пять высших уровней эталонной модели OSI. Она обеспечивает совместное пользование файлами и принтером, поддержку различных прикладных задач, таких как передача электронной почты и доступ к базе данных, и другие услуги. Также, как и другие NOS, такие как Network File System (NFS) компании Sun Microsystems, Inc. и LAN Manager компании Microsoft Corporation, NetWare базируется на архитектуре клиент-сервер (slient-server architecture). В таких архитектурах клиенты (иногда называемые рабочими станциями) запрашивают у серверов определенные услуги, такие как доступ к файлам и принтеру.

Первоначально клиентами NetWare были небольшие РС, в то время как серверами были ненамного более мощные РС. После того, как NetWare стала более популярной, она была перенесена на другие компьютерные платформы. В настоящее время клиенты и сервера могут быть представлены практически любым видом компьютерной системы, от РС до универсальных вычислительных машин.

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

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

<

Сетевой уровень (NetWare)

Internet Packet Exchange (IPX) является оригинальным протоколом сетевого уровня Novell. Если устройство, с которым необходимо установить связь, находится в другой сети, IPX прокладывает маршрут для прохождения информации через любые промежуточные сети, которые могут находиться на пути к пункту назначения. На Рисунке представлен формат пакета IPX.

Пакет IPX начинается с 16-битового поля контрольной суммы (checksum), которое устанавливается на единицы.

16-битовое поле длины (length) определяет длину полной дейтаграммы IPX в байтах. Пакеты IPX могут быть любой длины, вплоть до размеров максимальной единицы передачи носителя (MTU). Фрагментация пакетов не применяется.

За полем длины идет 8-битовое поле управления транспортировкой (transport control), которое обозначает число роутеров, через которые прошел пакет. Когда значение этого поля доходит до 15, пакет отвергается исходя из предположения, что могла иметь место маршрутная петля.

8-битовое поле типа пакета (packet type) определяет протокол высшего уровня для приема информации пакета. Двумя общими значениями этого поля являются 5, которое определяет Sequenced Packet Exchange (SPX) (Упорядоченный обмен пакетами) и 17, которое определяет NetWare Core Protocol (NCP) (Основной протокол NetWare).

Информация адреса пункта назначения (destination address) занимает следующие три поля. Эти поля определяют сеть, главную вычислительную машину и гнездо (процесс) пункта назначения.

Следом идут три поля адреса источника (source address), определяющих сеть, главную вычислительную машину и гнездо источника.

За полями пункта назначения и источника следует поле данных (data). Оно содержит информацию для процессов высших уровней.

Хотя IPX и является производной XNS, он имеет несколько уникальных характеристик. С точки зрения маршрутизации , наиболее важное различие заключается в механизмах формирования пакетов данных этих двух протоколов. Формирование пакета данных - это процесс упаковки информации протокола высшего уровня и данных в блок данных. Блоки данных являются логическими группами информации, очень похожими на слова телефонного разговора. XNS использует стандартное формирование блока данных Ethernet, в то время как пакеты IPX формируются в блоки данных Ethernet Version 2.0 или IEEE 802.3 без информации IEEE 802.2, которая обычно сопровождает эти блоки данных. Следующий рисунок иллюстрирует формирование пакета данных Ethernet, стандарта IEEE 802.3 и IPX.

Примечание: NetWare 4.0 обеспечивает формирование пакетов IPX в блоки данных IEEE 802.3.

Для маршрутизации пакетов в об'единенных сетях IPX использует протокол динамической маршрутизации, называемый Routing Information Protocol (RIP) (Протокол маршрутной информации). Также, как и XNS, RIP получен в результате усилий компании Xerox по разработке семейства протоколов XNS. В настоящее время RIP является наиболее часто используемым протоколом для внутренних роутеров (interior gateway protocol-IGP) в сообществе Internet-среде международной сети, обеспечивающей связность практически со всеми университетами и исследовательскими институтами и большим числом коммерческих организаций в США, а также со многими иностранными организациями.

В дополнение к разнице в механизмах формирования пакетов, Novell также дополнительно включила в свое семейство протоколов IPX протокол, называемый Service Adverticement Protocol (SAP) (Протокол об'явлений об услугах). SAP позволяет узлам, обеспечивающим услуги, об'являть о своих адресах и услугах, которые они обеспечивают.

Novell также поддерживает "Блок адресуемой сети" LU 6.2 компании IBM (LU 6.2 network addressable unit - NAU). LU 6.2 обеспечивает связность по принципу равноправных систем через среду сообщений IBM. Используя возможности LU 6.2, которые имеются у NetWare, узлы NetWare могут обмениваться информацией через сеть IBM. Пакеты NetWare формируются в пределах пакетов LU 6.2 для передачи через сеть IBM. <

Транспортный уровень (NetWare)

Sequenced Packet Exchange (SPX) (Упорядоченный обмен пакетами) является наиболее часто используемым протоколом транспортного уровня NetWare. Novell получила этот протокол в результате доработки Sequenced Packet Protocol (SPP) системы XNS. Как и протокол ТСР (Transmission Control Protocol) и многие другие протоколы транспортного уровня, SPX является надежным, с установлением соединения протоколом, который дополняет услуги дейтаграмм, обеспечиваемые протоколами Уровня 3.

Novell также предлагает поддержку протокола Internet Protocol (IP) в виде формирования протоколом User Datagram Protocol(UDP)/IP других пакетов Novell, таких как пакеты SPX/IPX. Для транспортировки через об'единенные сети, базирующиеся на IP, дейтаграммы IPX формируются внутри заголовков UDP/IP. <

ФОРМАТ RFC 850.

Статьи, используемые в системе телеконференций, как уже оговаривалось, имеют формат, определенный в RFC 850, и очень похожи на сообщения электронной почты. Каждая статья состоит из тех же частей: заголовка и тела. Тело статьи - это текст сообщения. Заголовок указывает программным средствам системы телеконференций, как следует распространять эту статью по сети INTERNET, а также содержит информацию о теме статьи. Информация заголовка используется для построения индекса серверов новостей, который позволяет клиентам создавать меню и искать интересующие их статьи без просмотра совокупности статей. Таким образом, в заголовке содержатся данные об авторе, теме, конспект и некоторые индексирующие ключевые слова. Ниже приведен пример статьи, составленной в формате RFC 850. Статья была передана через последовательность UNIX-компьютеров с помощью протокола UUCP. В таком виде она может быть получена сервером новостей, поддерживающим протокол NNTP.

Relay-Version: version B 2.10.3 4.3bsd-beta 6/6/89; site sdcsvax.UUCP * текущий

компьютер-получатель, выступающий в роли транслятора

Posting-Version: version B 2.10.1 6/24/89 SMI; site unitek.uucp * компьютер, на кото ром была опубликована статья

Path:sdcsvax!sdcrdcf!hplabs!qantel!ihnp4!alberta!ubc-vision!unitek !honman * серверы новостей, через которые была передана статья

From: honman@unitek.uucp (Man Wong) * отправитель статьи

Newsgroups: net.unix-wizards * название группы новостей, в которой опубликована данная статья

Subject: foreground -> background ? * тема статьи (указывается автором)

Message-ID: <167@unitek.uucp> * идентификатор сообщения, машины отправителя

Date: 25 Sep 93 23:51:52 GMT * дата отправки

Date-Received: 29 Sep 93 09:54:48 GMT * дата получения последним сервером

Reply-To: honman@unitek.UUCP (Hon-Man Wong) * E-Mail адрес автора для желающих ответить

Distribution: net.all * область распространения статьи, задаваемая автором

Organization: Unitek Technologies Corporation * место работы автора

Lines: 12 * количество строк текста в статье

I have a process (C program) which generates a child and waits for

it to return. What I would like to do is to be able to run the

child process interactively for a while before kicking itself into

the background so I can return to the parent process (while the

child process is RUNNING in the background). Can it be done? And

if it can, how?

Please reply by E-mail. Thanks in advance.

Hon-Man Wong

<

Формат статей и сообщений UseNet

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

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

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

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

From: jerry@cock.att.com (Jerry Balls)

Path: cbosgd!mhuxj!mhuxt!cock! jerry

Newsgroups: news.announce

Subject: UseNet Etiquette -- Please Read

Message-ID: <642@cock.att.com>

Date: Fri, 19 Nov 97 16:14:55 GMT

Followup-To: news.misc

Expires: Sat, 1 Jan 98 00:00:00 -0500

rganization: AT&T Bell Laboratories

This is a trivial news!

Стандартное UseNet-сообщение состоит (так же как и почтовое сообщение) из нескольких строк заголовка, отделенных от тела сообщения пустой строкой. Каждая строка состоит из ключевого слова, двоеточия ":", пробела, информации и символов завершения строки -<CRLF>.

Часть полей заголовка может отсутствовать. Это — поля: "Followup-To:", "Expires:", "Reply-To:", "Sender:", "References:", "Control:", "Distribution:", "Keywords:", "Summary:", "Approved:", "Lines:", "Xref:", "Organization:". Однако часть полей должна присутствовать в каждой статье: "From:", "Date:", "Newsgroups:", "Subject:" "Message-ID:", "Path:".

	Поля "From:", "Date:", "Subject:", "Message-ID:" содержат те же параметры, что и аналогичные поля конверта почтового сообщения. Форматы этих полей в статьях UseNet зависят от программного обеспечения клиента для работы с UseNet.
	Поле "Newsgroups:" заголовка статьи определяет группу и содержит название дискуссии или конференции, которой принадлежит данная статья. Одна и та же статья может принадлежать нескольким группам, тогда их названия перечисляются через запятую.

Все группы, упомянутые в поле "Newsgroups:", должны существовать. Если в поле "Newsgroups:" поступившего сообщения содержатся имена недоступных для данного сервера или несуществующих групп дискуссий, эти имена при обработке статьи игнорируются.

Поле "Path:" содержит путь сообщения, который был проделан, чтобы попасть в данную систему. Когда система переправляет сообщение с одного хоста на другой, она добавляет имя хоста в поле "Path:". Имена хостов могут отделяться друг от друга любым знаком пунктуации за исключением точки — "." (поскольку точка используется в именах хостов). Например, так: "Path: cbosgd!mhuxj!mhuxt" или "Path: cbosgd, mhuxj, mhuxt", или "Path: @cbosgd.att.com,@mhuxj. att.com,@mhuxt. att.com". Как правило, имя следующего хоста добавляется в строчку слева, поэтому хост — инициатор сообщения всегда стоит в этой строке справа. Это нужно для обеспечения совместимости со старыми системами. Например, хост А получил сообщение с параметром "Path: X!Y!Z". Если хост А отправляет его хосту В, то хост В получит статью с параметром "Path:

<



/p>



A!X!Y!Z" и т. д.

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

Если, например, хост А отправляет статью хосту В, параметр статьи "Path:" будет содержать имя хоста А. Поэтому хост В или какой-либо из следующих хостов, обрабатывающих эту статью, не отправит эту же статью обратно на хост А.



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

Поле "Followup-To:" имеет тот же формат, что и поле "Newsgroups:". Если это поле присутствует, дополнительные статьи, относящиеся к данной статье, направляются в конференцию(ии), указанные в этом поле. Если поле отсутствует, дополнения к данной статье направляются в конференцию(ии), указанные в поле "Newsgroups:".

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

Поле "References:" содержит список идентификаторов сообщений (Message-ID), на которые ссылается данное сообщение. Это поле обязательно должно присутствовать во всех сообщениях, являющихся дополнительными к данному. Как правило, поле "Subject:" сообщений, которые являются ответными к данному, содержит префикс "Re:". Например:

<



/p>

References: AAckqIqWy5@jone.tamu.edu

Message-Id: AARABLqq2H@lisa.silly.edu

Subject: Re: Hello

Если сообщение, к которому относится дополнительное сообщение, содержит поле "References:", дополнительное сообщение должно содержать в этом поле значения "References:" и значение поля "Message-ID:" этого сообщения. Данное поле позволяет группировать статьи в потоки обсуждений какой-либо темы и организовывать временные иерархические структуры внутри конференции. Если строка "References:" получается слишком длинной, локальное программное обеспечение может ее "обрезать", сохраняя количество ссылок, достаточное для идентификации потока обсуждения.

Поле "Organization:" содержит имя организации, к которой принадлежит отправитель или хост отправителя.

Поле "Keywords:" содержит ключевые слова-идентификаторы сообщения. Оно используется при поиске сообщения конкретного содержания.

Поле "Summary:" содержит краткое описание содержания статьи.

Поле "Distribution:" используется для ограничения распространения статей определенных конференций. Поле содержит идентификаторы зон распространения статьи. Например:

Newsgroups: rec.auto,misc.forsale

Distribution: nj,ny

Данная статья будет передаваться подписчикам конференций "rec.auto" и "misc.forsale", расположенным в доменах New Jersy — nj и New York — ny. Эту же задачу можно было решить, если создать для подписчиков New York и New Jersy отдельные конференции, например, "nj.rec.auto" "ny.rec.auto", "nj.misc.forsale" и "ny.misc.forsale". Но если вам нужно от-" править одну или несколько статей ограниченному кругу лиц, создавать для этого специальные конференции крайне неэффективно.

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

…

Newsgroups: news.lists,news.groups

…

Xref: alibaba news.lists:461 news.groups:6378

Это означает, что данное сообщение имеет номер 461 в группе "news.list" и 6378 в группе "news.groups" локального хоста "alibaba". Эти значения могут быть использованы локальным программным обеспечением.

Модели передачи статей

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

Примечание

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

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

Одним из решений этой проблемы является инкапсуляция статьи дискуссии, вместе с заголовком, в тело почтового сообщения. Для этого в начало каждой строчки статьи новостей, как тела, так и заголовка, вставляется буква "N". После этого статья записывается в тело почтового сообщения. Это гарантирует, что ни одна строчка статьи не будет интерпретироваться почтовым сервером как управляющая для почтового сообщения. Программа, ко-горая получит такое сообщение, извлекает из него статью и передает ее соответствующей программе обработки статей дискуссий.

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

Date: Mon, 3 Jan 95 08:33:47 MST

From: news@cbosgd.att.corn

Subject: network news message

To: rnews@npois.att.com

NPath: cbosgdimhuxj!harpo!utah-cs!sask!derek

NFrom: derek@sask.UUCP

NNewsgroups: misc.test

NSubject: test

NMessage-ID: <176@aask.UUCP>

NDate: Mon, 3 Jan 95 00:59:15 MST

N

NThis really is a test.

N

<

/p>

Подобная форма передачи статей позволяет отдельно задавать приоритеты почтовых сообщений и статей новостей.

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

Например, пакет может быть построен так, что каждому сообщению в пакете предшествует строка "#!rnews <number>", где <number> — длина статьи. Такой пакет будет выглядеть следующим образом:

# ! rnews 239

From: jerry@eagle.att.corn (Jerry Schwarz)

Path: cbosgdimhuxj imhuxt!eagle!jerry

Newsgroups: news.announce

Subject: UseNet Etiquette -- Please Read

Message-ID: 642@eagle.att.corn

Date: Fri, 19 Nov 96 16:14:55 EST

Approved: mark@cbosgd.att.corn

Here is an important message about UseNet Etiquette.

# ! rnews 234

From: jerry@eagle.att.corn (Jerry Schwarz)

Path: cbosgd!mhuxj!mhuxt!eagle ! jerry

Newsgroups: news.announce

Subject: Notes on Etiquette message

Message-ID: 643@eagle.att.corn

Date: Fri, 19 Nov 96 17:24:12 EST

Approved: mark@cbosgd.att.corn

There was something I forgot to mention in the last message.

В данном примере, символ "#"

используется как идентификатор, а строка "rnews" задает формат пакета.



Примечание



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

Протокол NNTP, описание команд

Сервер новостей UseNet использует протокол NNTP для взаимодействия с другими серверами. Механизм работы протокола NNTP во многом похож на механизм работы по протоколу SMTP. Протокол поддерживает канал обмена новостями и простейший интерфейс работы с распределенной базой данных новостей. При использовании в качестве транспортного протокола TCP, протокол NNTP, как правило, работает с портом 119.

Команды и ответы протокола состоят из ASCII-символов. Если соединение позволяет передавать 8-битные данные, восьмой (старший) бит устанавливается в ноль. Команды могут содержать параметры, которые отделяются пробелами или символами табуляции. Каждая строка может содержать только одну команду (с параметрами или без), должна заканчиваться парой <CRLF> и быть длиной не более 512 байт.

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

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

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

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

Статус-ответы являются сообщениями о статусе от сервера и индицируют ответ на последнюю команду, принятую от клиента.

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

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

Обычно коды ответов типа 1хх могут быть проигнорированы или отображены по желанию; коды 200

или 201 посылаются после установления соединения с NNTP-сервером в зависимости от того, разрешена публикация или нет; код 400

будет послан тогда, когда NNTP-сервер прекратит обслуживание (например, по запросу оператора); и коды 5хх указывают на то, что команда не может быть выполнена по каким-либо причинам.



100 Текст с инструкциями.



190 – 199 Отладка выхода.



200 Сервер готов - публикация разрешена.



201 Сервер готов - публикация не разрешена.



400 Прекращение обслуживания.



500 Команда не опознана.



501 Ошибка в синтаксисе команды.



502 Ограничение доступа или отказ в разрешении.



503 Ошибка программы - команда не выполнима.



Примечание



Числовые коды ответов сервера новостей составляют определенную иерархию и обозначают состояние сервера после выполнения команды. Описание кодов возврата выходит за рамки данной книги. Подробное описание структуры системы кодов вы можете найти, например, в RFC-977.

Итак, после того как клиент установил TCP-соединение с сервером новостей, сервер отвечает приглашением к работе по протоколу NNTP (далее символом "S" будем обозначать сервер новостей, а символом "С" — клиента). Например:





S: 200 newsvax news server ready — posting ok





Код 200 означает, что данный сервер позволяет клиенту передавать ему новые статьи. Если код ответа — 201, сервер не позволяет клиенту передавать на него новые статьи:





S: 201 badvax netnews server ready -- no posting allowed





Теперь клиент может начать работу. Далее будут описаны наиболее употребительные в ежедневной работе команды NNTP.

Команда LIST возвращает список групп сервера новостей и сопутствующую информацию. Например:

С: LIST

S: 215 list of newsgroups follows

S: net.wizards 10125 10011 у

S: net.idiots 00100 00001 n

S: ...

S: <groupname> <last> <first> p



где <groupname> — имя группы новостей, <last> и <first> — номера последней и первой статьи в группах, р — флаг, показывающий, может ли клиент отправлять свои статьи в эти группы ('n' — не может, 'у' — может).

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

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

С: GROUP net.deneg

S: 211 104 10011 10125 net.deneg group selected

(there are 104 articles on file, from 10011 to 10125)





где 211 — код успешного открытия группы (если код =411, такой группы нет), число 104 — количество статей в группе, 10011 — номер первой статьи группы, 10125 — номер последней статьи. После выполнения этой команды создается указатель на текущую статью, который по умолчанию будет указывать на первую статью в группе.

После того как выбрана группа новостей, пользователь может прочитать статью из этой группы. Для этого можно использовать команды: ARTICLE, BODY, HEAD. В качестве аргументов команды используют либо номер статьи, либо ее уникальный идентификатор (Message-ID). Последний может использоваться, например, для предотвращения повторного чтения одной и той же статьи. Разница между этими командами заключается в том, что ARTICLE возвращает как заголовок, так и тело статьи, HEAD возвращает только заголовок, a BODY — только тело сообщения. Например:

<



/p>





С: ARTICLE <87623@baz.net>

S: 220 <87623@baz.net> All of article follows

S: ... text ...

C: BODY 402

S: 220 402 <4105@ucbvax.arpa> Article retrieved, body follows

S: ... text ...

C: HEAD 404

S: 220 404 <mik@vax.net> Article retrieved, head follows

S: ... text ...

Сообщения в группе можно читать последовательно, не обращаясь к номеру статьи. Для этого требуется установить указатель на текущую статью. Это делает команда STAT. Аргументом команды является или номер статьи в группе, или уникальный идентификатор сообщения (Message-ID). После того как указатель установлен, вы можете читать текст статей, например, командой BODY, не указывая номера. Для того чтобы передвинуть указатель на следующую статью, следует подать команду NEXT без аргументов, соответственно, на предыдущую — команду LAST. Например:

С: STAT 110

S: 223 110 <23445@svax.com> article retrieved — statistics

C: BODY

S: 222 110 <23445@svax.com> article retrieved - body follows

S: ... text ...

C: NEXT

S: 223 113 <21495@nuke.uucp> article retrieved - statistics

Пользователь может получить от сервера новостей список групп, которые были созданы позднее заданной даты. Этот сервис предоставляется командой NEWGROLJPS. Аргументами команды NEWGROUPS являются дата и время в формате "YYMMDD HHMMSS", флаг отсчета времени (локальное или по GMT), маска имен групп. Например, запрос списка групп, созданных на данном сервере с 15 мая 1995 года по GMT и имеющих в своем названии строку "net" выглядит следующим образом:

С: NEWGROUPS 950515 000000 GMT <net>

S: 235 New newsgroups since 950515 follow

S: net.fluff

S: ...

Пользователь может получить от сервера новостей список уникальных идентификаторов статей которые были созданы в указанной группе позднее заданной даты. Этот сервис предоставляется командой NEW-NEWS. Аргументами команды являются дата и время в формате "YYMMDD HHMMSS", флаг отсчета времени (локальное или по GMT), маска имени группы новостей. Маска имени в данной команде позволяет использовать символ джокеры ("*") и символ отрицания ("!"). Например, запрос списка статей, полученных всеми группами новостей данного сервера после 16 июня 1997 года выглядит следующим образом:

<



/p>

С: NEWNEWS * 970616 000000

S: 230 New news since 970616 000000 follows

S: <1772@foo.UUCP>

S: ...

Команда IHAVE информирует сервер, что пользователь имеет статью с идентификатором <Message-ID>, который указывается в качестве аргумента данной команды. Например:

С: IHAVE <4105@vax.com>

S: 435 Already seen that one, where you been?

С: IHAVE <4109@vax.com>

S: 335 News to me! <CRLF.CRLF> to end.

С: (sends article)

С : .

S: 235 Article transferred successfully. Thanks.

Если сервер уже имеет данную статью, он ответит, что копия статьи у него уже есть. Если указанной статьи нет, сервер попросит ее отправить, и пользователь может отправить статью. При отправке клиент должен передать всю статью целиком, включая заголовок и тело сообщения в том же формате, в каком он получает статьи от данного сервера. Передача сообщения завершается строчкой, содержащей символ "." (т. е. последовательностью "<CRLF>.<CRLF>").

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

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

С: POST

S: 340 Continue posting; Period on a line by itself to end

C: ...

C: .

S: 240 Article posted successfully.

Завершает сессию обмена команда QUIT:

С: QUIT

S: 205 VAX closing connection. Goodbye.

 

Сценарий работы NNTP

Далее представлен простейший пример сессии работы клиента и сервера по протоколу NNTP:

S: 200 atvax news server ready — posting ok

C: GROUP net. Wizards

S: 211 104 10011 10125 net.wizards group selected

(there are 104 articles on file, from 10011 to 10125)

C: STAT 10110

S: 223 10110 <23445@svax.ARPA> article retrieved - statistics

only (article 10110 selected, its message-id is

<23445@svax.ARPA>)

C: BODY

S: 222 10110 <23445@svax.ARPA> article retrieved - body follows

S: ... text body ...

S: .

C: NEXT

S: 223 10113 <21495@nudebch.uucp> article retrieved - statistics

only (article 10113 was next in group)

C: ARTICLE 10120

S: 220 10120 <4105@ucbvax.ARPA> Article retrieved, text follows

S: ... text article ...

S:

C: QUIT

S: 205 goodbye. <

Серверы новостей

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

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

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

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

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

Для обмена сообщениями между серверами, а также для доступа к серверам используется протокол NNTP. <

Система UseNet

Internet-сообщество уже много лет пользуется системой тиражирования объявлений, рекламы, сообщений и другой информации. Всю подобным образом тиражируемую информацию называют новостями — "news". Новости делятся на группы новостей — "newsgroups". Группы новостей организованы в определенном порядке, основанном на распределении дискуссий по темам, например, отдых, спорт, новости, информация, религия и др. Внутри каждой из этих групп может быть до нескольких тысяч подгрупп, которые, в свою очередь, обладают такой же иерархической структурой. Принцип этой организации подобен структуре размещения каталогов и подкаталогов на жестком диске.

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

Biz - бизнес;

Comp – вычислительная техника;

News - новости общего характера;

Rec - развлечения, хобби, отдых;

Sci - наука;

Soc – социальные темы;

Talk – с ориентацией на дискуссию;

Alt – альтернативные взгляды;

Misc – всё остальное.

К примеру, группа, обменивающаяся информацией об отдыхе (recreation), использует ключ гес для построения иерархии более низкого уровня, такой как rec.arts, rec.games, rec.pets, rec.sports, rec.travel и т. д. Каждая из подгрупп, например, rec.pets, может быть, в свою очередь, разделена на более мелкие подгруппы, например, rec.pets.dogs, rec.pets.cats и др. Так организованные группы новостей позволяют пользователям, имеющим общие интересы, обмениваться новостями, отправлять свои статьи и отвечать на заметки других пользователей, обмениваться иллюстрациями и программным обеспечением для просмотра статей этой группы и т. п.

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

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

Каждое ребро графа UseNet можно соотнести с идентификатором конференции, тогда отношение "подписки" топологически можно изобразить так:

хост А "подписан" на конференцию хоста В, если между А и В существует ребро графа, принадлежащее подсети данной конференции.



Примечание



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

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

Одним из решений этой проблемы является отслеживание истории прохождения хостов данной статьей. Так, каждый хост, при. прохождении через него статьи, фиксирует уникальный номер сообщения (Message-ID). Если сообщение с тем же номером приходит на хост еще раз, оно уже не принимается. Другой способ предотвращения петель состоит в фиксировании пути внутри самого сообщения. То есть сообщение никогда не будет отправлено на хост, зафиксированный в определенном поле заголовка статьи (Path).



Способы тиражирования сообщений



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

Отправка статей по электронной почте по спискам рассылки участников конференций.



Использование распределенной базы данных и серверов новостей системы UseNet.

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

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

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

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

<

Управляющие сообщения NNTP

Если сообщение содержит строку "Control:", это означает, что данное сообщение — управляющее. Управляющие сообщения используются для обмена служебной информацией между UseNet-хостами (а не пользователями). Управляющие сообщения передаются с использованием того же самого механизма, как и обычные сообщения, т. е. через систему групп или конференций подписки.

Примечание

Для совместимости со старыми версиями системы, сообщения адресованные группе "all.all.ctl" считаются управляющими. Если сообщение этой группы не содержит поля "Control:", поле предмета сообщения "Subject:" для таких сообщений интерпретируется как параметр "Control:". Кроме того, если в сообщениях этой группы первые 4 символа поля "Subject:" содержат подстроку "cmsg", оставшаяся часть поля "Subject:" интерпретируется как управляющее сообщение.

Поля "Control:" заголовка сообщения содержат команду и параметры команды: первое слово представляет собой команду, остальные — параметры этой команды. Другие поля заголовка и тело сообщения тоже могут использоваться как потенциальные параметры команды. Например:

Control: cancel <any.string@host.domen>

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

Сообщение "cancel" позволяет пользователю удалять статьи из локальной системы уже после того, как статья была тиражирована. Параметр команды — идентификатор сообщения "Message-ID".

cancel <Message-ID>

Отправить такую команду может только автор статьи или администратор локальной UseNet-системы. Обработчик данного управляющего сообщения, прежде чем его применить, сверяет параметры "Sender:" и "From:" управляющего и исходного сообщений.

<

/p>

Сообщения "ihave/sendme". Эти сообщения являются частью ihave/sendme-протокола, который позволяет одному хосту (А) сообщить другому хосту (В), что данное сообщение им получено — команда "ihave" (а другому хосту (В) запросить это сообщение — команда "sendme").

ihave <Message-ID list> [<remotesys>]

sendme <Message-ID list> [<remotesys>]



Например, хост (А) получил сообщение <1234@vax.berkeley.edu> и хочет передать его на хост (В). Тогда (А) отправляет через какую-либо из конференций, на которые подписан (В), хосту (В) управляющее сообщение "ihave <1234@vax.berkeley.edu> А". Хост (В) отвечает, опять же через какую-либо из конференций, на которые подписан хост (А), управляющим сообщением "sendme <1234@vax.berkeley.edu> В". После получения сообщения "sendme", хост (А) отправляет хосту (В) данное сообщение.

Эти команды позволяют хостам выбирать статьи для пересылки, тем самым уменьшая передаваемый поток новостей "вслепую".

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

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

newgroup <groupname> [moderated]



Это сообщение создает конференцию с именем "groupname". Тело данного управляющего сообщения может содержать краткую аннотацию новой группы (предназначение, уровень и темы дискуссий и т. д.). Если указан аргумент "moderated" — это означает, что у данной группы есть председательствующий, который следит за уровнем и темами дискуссий. По умолчанию новая конференция не имеет председательствующего. Статья новостей может быть отправлена в конференцию только после того, как данная конференция будет создана.



rmgroup <groupname>

Это сообщение удаляет конференцию с именем "groupname".

Управляющее сообщение "sendsys" ( без аргументов) представляет собой запрос к данному UseNet-хосту на получение списка всех его соседей и групп статей новостей, которые он передает своим соседям. Ответ на запрос передается отправителю данного управляющего сообщения, указанному в поле "Reply-To:" или в поле "From:" управляющего сообщения.

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

From: cbosgd!mark (Mark Horton)

Date: Sun, 27 Mar 83 20:39:37 –0500

Subject: response to your sendsys request

To: mark@home.att.com

Responding-System: cbosgd.att.com

cbosgd:osg,cb,btl,bell,world,comp,sci,rec/talk,misc,news,soc

ucbvax:world,comp,to.ucbvax

cbosg:world,comp,be 11,btl,cb,osg,to.cbosg

cbosgb:osg,to.cbosgb sescent:wo rid,comp,bell,to.sescent:F:/usr/spool/outnews/sescent

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

Управляющее сообщение "version" (без аргументов) используется для запроса имени и версии программного обеспечения системы UseNet, используемой на запрашиваемом хосте.

 

PPPS