Следующая:i Protocol, Следующая:j Protocol, Предыдущая:Big G Protocol, Вверх:Protocols
i
ProtocolUUCP протокол i
Протокол i
написан Ian Lance Taylor (автор данного руководства).
Первоначально использовался в версии Taylor UUCP 1.04.
Данный протокол применяет скользящее окно, подобно g
протоколу,
но поддерживает двунаправленную передачу (то есть, файлы передаются в
обоих направлениях). Данный протокол требует восьмибитного чистого
соединения. Несколько идей для реализации протокола были взяты из
статьи P. Lauder A High-Throughput Message Transport System.
Я не знаю, где опубликована статья, но адрес электронной почты автора -
piers@cs.su.oz.au
. i
протокол не реализует главную идею
статьи, которая состоит в том, чтобы обойтись без окон полностью.
Это возникло потому, что некоторые соединения требуют управление
потоком данных и, что более важно из-за того, что при использовании
окон устанавливается ограничение на количество данных, которые
протокол может заново отослать по запросу. Для уменьшения затрат на
окна, протокол использует большое окно и требует подтверждение на
половине окна.
Каждый пакет начинается с шести байтового заголовка, за которым
следуют байты данных, а затем идет четырехбайтовая контрольная сумма.
В настоящее время определено пять типов пакета (DATA
, SYNC
,
ACK
, NAK
, SPOS
,CLOSE
) которые описаны ниже.
Хотя пакеты любого типа могут включать данные, любые данные, содержащиеся
в пакетах ACK
, NAK
или CLOSE
игнорируется.
Каждый пакет DATA
, SPOS
и CLOSE
имеет последовательный
номер (sequence number). Последовательные номера независимы для каждой
стороны. Первый пакет, отсылаемый каждой стороной, всегда имеет номер
1. Номер каждого пакета больше на 1 по модулю 32, чем номер
предыдущего пакета.
Каждый пакет имеет локальный номер канала, и номер удаленного канала. Для всех пакетов, по крайней мере, один номер канала составляет ноль. Когда UUCP отсылается удаленной системе, то данной команде назначается локальный номер канала отличный от нуля. Все пакеты, связанные с данной UUCP командой, отсылаемые локальной системой используют выбранный локальный номер канала. Все пакеты, отсылаемые удаленной системой, используют этот выбранный номер в качестве удаленного номера канала. Это позволяет каждой UUCP команде быть идентифицированной номером канала на системе возникновения, и поэтому каждый UUCP пакет может связать все файловые данные и ответы на команду UUCP с соответствующей командой. Это требование для двунаправленной UUCP передачи.
Протокол поддерживает единственную глобальную файловую позицию,
которая начинается с 0. При поступлении пакета, любые связанные с ним
данные, рассматриваются, как будто они соответствуют текущей файловой
позиции, а сама позиция инкрементируется на количество принятых
данных. Исключением является пакет типа SPOS
, который используется
для изменения файловой позиции. Причина поддержки текущей позиции в
файле описана ниже.
Заголовок выглядит следующим образом:
\007
(packet << 3) + locchan
DATA
, SPOS
и CLOSE
для
поля packet используют последовательный номер (sequence number)
пакета. В пакетах типа NAK
поле packet заполняют
последовательным номером пакета, который нужно повторно отослать.
Пакеты ACK
и SYNC
не используют поле packet, и
обычно заполняют данное поле нулем. Пакеты, которые не связаны с UUCP
командой локальной системы, используют локальный номер канала равный 0.
(ack << 3) + remchan
(type << 5) + (caller << 4) + len1
Если длина данных отлична от нуля, за пакетом немедленно следует указанное количество байт данных. За байтами данных следует четыре байта контрольной суммы CRC 32, причем наиболее существенный байт передается первым. Контрольная сумма CRC считается для поля данных.
Определенны следующие типы пакетов:
DATA
SYNC
SYNC
пакетами происходит при инициализации протокола, и
описывается ниже. SYNC
пакеты не содержат последовательные
номера (то есть поле packet игнорируется).
ACK
DATA
пакеты также содержат
подтверждения пакетов, то ACK
пакеты отсылается только, когда
одна сторона не имеет никаких данных для отсылки. ACK
пакеты не
содержат последовательные номера (sequence numbers).
NAK
NAK
пакеты не несут
последовательные номера (sequence numbers) (поле packet уже
используется).
SPOS
CLOSE
CLOSE
. Данный пакет содержит последовательный номер
(sequence number), который используется для гарантирования
правильности получения пакетов (это не нужно данному протоколу
UUCP, однако, это нужно команде верхнего уровня H
, точнее,
ее отклику HY
).
При старте протокола, обе системы отсылают пакет SYNC
. Пакет
SYNC
включает, по крайней мере, три байта данных. Первые два байта
задают максимальный размер пакета, который удаленная система должна
использоваться, старший байт отсылается первым. Третий байт это размер
окна, который должна использовать удаленная система. Удаленная система
может отсылать пакеты любого размера вплоть до максимального. Если в
пакете присутствует четвертый байт, то он задает количество каналов,
которые может использовать удаленная система (количество каналов
должно лежать между 1 и 7, включительно). В будущем могут быть
определены дополнительные байты данных.
Размер окна это количество пакетов, которые могут быть отосланы
прежде, чем будет получено подтверждение пакета. Требования по
подтверждению каждого пакета отсутствуют; считается, что любое
подтверждение, подтверждает все пакеты, включая указанный в
подтверждении номер. В текущей реализации, если у одной стороны нет
никаких данных для отсылки, то отсылается ACK
пакет по приему
половины окна.
Обратите внимание, что пакет NAK
соответствует неиспользуемому в
протоколе g
пакету типа SRJ
, а не пакету типа RJ
.
По приему пакета типа NAK
, отсылается только указанный пакет,
а не последующие пакеты.
Отметим, что если у обоих сторон имеются данные для отсылки, а пакет теряется, то для одной стороны является разумным продолжить отсылку пакетов, причем все эти пакеты подтверждают последний правильно принятый пакет, а другая сторона, чей пакет был потерян, будет неспособна отослать следующий пакет, потому что окно на отсылку будет закрыто. При этих условиях, если таймауты отсутствуют (не используются), то одно направление коммуникации будет фактически закрыто. Поэтому, если у системы есть неподтвержденные пакеты, то данная система должна организовать таймауты на повторную отсылку пакетов, даже если данная система нормально принимает пакеты.
Команды отсылаются в виде последовательности пакетов данных с локальным номером канала, отличным от нуля. Последний пакет данных команды включает хвостовой нулевой байт (обычно команда укладывается в единственный пакет данных). Файлы отсылаются в виде последовательности пакетов данных, последний из которых имеет нулевую длину.
Номера каналов позволяют эффективнее реализовать команду протокола
UUCP на отсылку файла. Вместо того, чтобы отослать команду и ожидать
ответа SY
перед отсылкой файла, данные файла отсылаются немедленно,
после, того как отсылается команда S
. Если получен отклик SN
,
то отсылка файла прерывается, и отсылается финальный пакет данных
нулевой длины, для того чтобы указать, что номер канала может повторно
использоваться. Если получен отклик SY
c индикацией файловой
позиции, то отсылка файла выравнивается на данную файловую позицию;
это одна из причин, по которой протокол поддерживает глобальную
файловую позицию.
Отметим, что использование номера канала обозначает, что каждая UUCP система может отсылать и команды и файл данных одновременно. Более того, каждая UUCP система может отсылать несколько файлов в то же самое время, используя номер канала, для того чтобы разделить пакеты данных, относящиеся к различным файлам. Отсылка файла перед получением подтверждения для предыдущего файла помогает устранять round trip задержки (задержка, связанная с распространением пакета туда и обратно), свойственные другим UUCP протоколам.