Следующая:i Protocol, Следующая:, Предыдущая:Big G Protocol, Вверх:Protocols



UUCP i Protocol

UUCP протокол 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
Каждый пакет начинается с ^G.
(packet << 3) + locchan
Пять битов номера пакета, объединяются с тремя битами номера локального канала. Пакеты DATA, SPOS и CLOSE для поля packet используют последовательный номер (sequence number) пакета. В пакетах типа NAK поле packet заполняют последовательным номером пакета, который нужно повторно отослать. Пакеты ACK и SYNC не используют поле packet, и обычно заполняют данное поле нулем. Пакеты, которые не связаны с UUCP командой локальной системы, используют локальный номер канала равный 0.
(ack << 3) + remchan
Пять битов номера подтвержденного пакета, объединяются с тремя битами удаленного номера канала. Номер подтвержденного пакета это номер последнего, успешно полученного пакета, данное поле используется для всех типов пакетов. Пакеты, которые не отсылаются в ответ на UUCP команду от отдаленной системы, используют удаленный номер канала 0.
(type << 5) + (caller << 4) + len1
Три бита типа пакета, объединяются с одним битом направления пакета и с четырьмя старшими битами количества данных. Бит направления пакета составляет 1 для пакетов, отсылаемых звонящим UUCP, и 0 для пакетов, отсылаемых вызываемым UUCP. Данный бит служит для устранения возможных недоразумений, вызванных эхо пакетами.
len2
Младшие восемь битов длины данных. Двенадцать битов длины, дают размер пакетов от 0 до 4095 байтов.
check
Исключительное или (xor) для байтов заголовка от второго до пятого. Данное поле используется для дополнительной проверки заголовка на правильность.

Если длина данных отлична от нуля, за пакетом немедленно следует указанное количество байт данных. За байтами данных следует четыре байта контрольной суммы CRC 32, причем наиболее существенный байт передается первым. Контрольная сумма CRC считается для поля данных.

Определенны следующие типы пакетов:

0 DATA
Пакет данных.
1 SYNC
Обмен SYNC пакетами происходит при инициализации протокола, и описывается ниже. SYNC пакеты не содержат последовательные номера (то есть поле packet игнорируется).
2 ACK
Пакет подтверждения. Так как DATA пакеты также содержат подтверждения пакетов, то ACK пакеты отсылается только, когда одна сторона не имеет никаких данных для отсылки. ACK пакеты не содержат последовательные номера (sequence numbers).
3 NAK
Отрицательное подтверждение. Отсылается, если пакет получается неправильно, и означает, что пакет с номером содержащимся в поле packet должен быть заново отослан. NAK пакеты не несут последовательные номера (sequence numbers) (поле packet уже используется).
4 SPOS
Данный пакет меняет файловую позицию. Пакет содержит четыре байта данных, которые представляют позицию в файле, причем наиболее существенный байт передается первым. Считается что следующий полученный пакет соответствует данной файловой позиции.
5 CLOSE
Когда протокол завершается (shutdown), каждая сторона отсылает пакет 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 протоколам.