Протоколы Internet
Протокол обмена UUCP
4.4.14.1 Протокол обмена UUCP
Семенов Ю.А. (ГНЦ ИТЭФ)
Современные программные пакеты UUCP поддерживают приоритеты для всех команд, которые варьируются от a (наивысший) до z и далее a-z. В UNIX эти коды приоритетов вставляются в имена командных файлов, создаваемых UUCP или UUX. Имя командного файла обычно имеет вид: c.nnnngssss, где g – код приоритета (от слова grade), nnnn – имя удаленной системы, а ssss – четырех символьный номер. Например, командный файл создаваемый системой sun2 с уровнем приоритета d может иметь имя c.sun2d1111. При этом в имени удаленной системы сохраняется лишь 7 символов, чтобы обеспечить совместимость с 14-символьным ограничением для имен файлов.
UUCP-протокол определяет взаимодействие между двумя программами. Этот диалог включает в себя три этапа: установление канала, последовательность запросов пересылки файлов и закрытие канала. Прежде чем начать диалог, инициатор обмена должен авторизоваться в ЭВМ, с которой планируется обмен, и активизировать тамошнюю систему UUCP. На рисунке инициатор обмена назван клиентом (в литературе можно также встретить также название master). Все сообщения начинаются с символа ^p (восьмеричный код ‘\020’) и завершаются нулевым байтом (\000). В некоторых системах для завершения сообщений используется код перевода строки (\012).
Установление канала инициируется сервером, который посылает сообщение \020shere=hostname\000, где hostname – имя ЭВМ сервера. В устаревших пакетах uucp можно встретить инициирующие сообщения вида \020shere\000.
Клиент должен откликнуться сообщением \020shostname options\000, где hostname соответствует имени клиента (инициатора обмена). При этом допустимы следующие опции (опции могут и отсутствовать).
| rok | Запрос принимается, диалог переходит к согласованию протокола; |
| rlck | Сервер заблокирован, что говорит о том, что ЭВМ уже осуществляют обмен; |
| rcb | Сервер осуществляет обратный запрос клиенту, что позволяет исключить ложные вызовы; |
| rbadseq | Неверен порядковый номер сообщения; |
| rlogin | Клиент использовал неверное имя при авторизации; |
| ryou are unknown to me | Клиент неизвестен серверу (uucp не позволяет соединение с неизвестными системами). |
Запрос сервера \020pprotocols\000, где protocols характеризует список поддерживаемых протоколов, причем каждому протоколу соответствует лишь один символ. Клиент может послать сообщение \020uprotocols\000, где инициатор сессии выбирает протокол из предлагаемого сервером списка. Если в предлагаемом списке нет нужного протокола, посылается сообщение \020un\000 и обе стороны разрывают сессию.
Когда канал сформирован и определены его параметры, может начаться обмен командами. Если в процессе обмена командами выявляется ошибка, участники обмена переходят к диалогу для закрытия канала.
Клиент может послать команды: s, r, x, e, или h (команды посылает только клиент). В качестве параметров этих команд используются имена файлов. Это могут быть абсолютные имена файлов, начинающиеся с символа /, файлы из публичного каталога с именами, которые начинаются с символов ~/, файлы из каталога пользователя, начинающиеся с строки ~user/, или файлы из временного буфера (spool). Собственно имена начинаются с c. для командных файлов, с d. для файлов данных, или с x. для исполнительных файлов.
Команда клиента s, предназначенная для посылки файлов серверу, имеет формат: s from to user –options temp mode notify size. Параметр from представляет собой имя посылаемого файла, to – имя файла на сервере, куда будет скопирован файл, user – имя пользователя, инициировавшего пересылку файла, options – список опций, управляющих обменом, temp – имя пересылаемого файла в случае использования опции С. После успешного завершения обмена сервер стирает файл temp. Параметр mode задает разновидность файла на сервере. Если файл не из каталога spool, клиент создает его с mode=0666. Параметр notify может отсутствовать, он имеет смысл лишь при наличии опции n. В этом случае при успешном завершении обмена посылается уведомление через электронную почту по адресу notify. Поле size задает размер файла в байтах.
| Опция | Описание |
| c | Файл копируется в каталог spool (клиент должен использовать temp, а не from) |
| c | Файл не должен копироваться в каталог spool (по умолчанию) |
| d | Сервер должен сформировать каталог, если необходимо (по умолчанию) |
| f | Сервер не должен формировать каталог, если необходимо, а вместо этого он должен оборвать связь |
| m | Клиент должен послать электронное почтовое сообщение пользователю (user) по завершении обмена |
| n | Сервер должен послать e-mail по адресу, указанному в параметре notify, по завершении обмена |
| Отклик | Описание |
| sy start | Сервер готов принять файл и обмен начинается. Поле start присутствует в случае использования рестарта и характеризует позицию в файле, с которой осуществляется рестарт. Для нового файла start=0x0 |
| sn2 | Сервер не выдает разрешение на пересылку файла. Это может означать, например, что недоступен нужный каталог. Такой отклик говорит о том, что пересылка принципиально невозможна. |
| sn4 | Сервер не может создать нужный временный файл, можно повторить попытку обмена позднее |
| sn6 | Используется версией taylor uucp. Сервер считает файл слишком длинным (в данный момент места нет, но возможно ситуация изменится в будущем) |
| sn7 | Используется версией taylor UUCP. Сервер считает файл настолько большим, что пересылка вообще невозможна |
| sn8 | Используется версией taylor UUCP. Означает, что файл был уже получен ранее. Это может произойти при потере подтверждения завершения обмена. |
| sn9 | Используется версией taylor UUCP и uuplus. Означает, что удаленная система не может открыть другой канал и можно позднее попытаться передать файл еще раз |
| sn10 | Используется только svr4 uucp и означает, что размер файла слишком велик |
| cy | Передача файла успешно завершилась |
| cym | Передача успешно завершена и сервер хочет стать клиентом |
| cn5 | Временный файл не может быть перемещен в окончательное положение, что означает невозможность завершения обмена. |
/p> Последние три отклика сервера называются С-командами. При получении С-команды клиент может послать новую команду-запрос. Такой командой может быть r-команда, которая имеет следующий формат.
r from to user –options size
Это запрос клиента на получение файла от сервера. Параметр from – имя файла на сервере. Это не может быть spool-файл, имя не может иметь символов подмены (wildcard). Параметр to
– имя файла, который должен появиться у клиента, user – имя пользователя, инициировавшего обмен, options – список опций, контролирующих обмен, size – определяет максимальный размер файла, который может принять клиент. Допускаются следующие опции.
| d | клиент должен создать каталог, если необходимо (по умолчанию); |
| f | клиент не должен создать каталог, если необходимо,вместо этого он должен прервать сессию; |
| m | клиент должен послать e-mail по адресу user в случае успешного завершения обмена. |
| Отклик | Описание |
| ry mode [size] | Сервер готов послать файл и начинает эту процедуру. Аргумент mode – восьмеричный код модификатора файла на сервере. Для некоторых версий bsd uucp аргумент mode может иметь в конце символ М, означающий, что сервер хочет стать клиентом и выдать команду-запрос |
| rn2 | Сервер не может послать файл, так как это запрещено или потому, что такой файл отсутствует |
| rn6 | Используется версией taylor uucp. Файл слишком велик (например, не соответствует ограничениям клиента) |
| rn9 | Используется версией taylor uucp и fsuucp. Удаленная система не может открыть еще один канал. Можно попробовать позднее |
cy файл благополучно передан;
cn5 временный файл не может быть перемещен в окончательную позицию.
Клиент может использовать команду x
для запуска uucp на сервере. Команда может иметь формат x from to user –options. Параметр from – имя файла (или файлов) на ЭВМ-сервере, пересылку которого затребовал клиент. Команда может служить для пересылки файлов из сервера посторонней третьей системе. Параметр to является именем файла или каталога, куда будут перенесен файл (или файлы). Например, если клиент хочет получить файлы сам, можно использовать запись master!path. Сервер может прислать следующие отклики на команду x.
xy запрос принят, соответствующие команды пересылки файлов поставлены в очередь для последующего исполнения.
xn Запрос отклонен (причина отклонения не сообщается, может быть сервер не поддерживает Х-запросы).
Клиент может послать команду Е, которая имеет следующий формат:
e from to user –options temp mode notify size command
Е-команда поддерживается системой taylor uucp и служит для реализации запросов исполнения без использования файлов x.*. Эта команда применяется в случае, когда исполняемая команда требует входного файла, который используется ей в качестве стандартного ввода. Основные параметры команды имеют то же значение, что и в случае команды s. Список опций, управляющих обменом, представлен в таблице.
| Опция | Описание |
| c | Файл копируется в каталог spool (клиент должен использовать temp, а не from) |
| c | Файл не копируется в каталог spool (по умолчанию) |
| n | e-mail сообщение не посылается даже в случае неудачи. Это эквивалентно n-команде в файле x.*. |
| z | Е-mail сообщение посылается, если при исполнении команды произошла ошибка (значение по умолчанию). Эквивалентно команде z в файле Х.* |
| r | Е-mail сообщение о результате выполнения посылается адресату, записанному в параметре notify. Эквивалентно команде r в файле Х.* |
| e |
Исполнение должно проводиться с /bin/sh. Эквивалентно команде e файла Х.*. |
Для переведения соединения в пассивное состояние клиент может использовать h-команду (не имеет параметров или опций). Сервер реагирует на нее h-откликом.
| hy | сервер согласен заблокировать обмен. В некоторых пакетах uucp клиент также посылаете команду hy. После этого стартует процедура закрытия канала. |
| hn | Сервер не готов заблокировать обмен. После этого клиент и сервер меняются ролями, такой обмен ролями возможен несколько раз за время сессии. |
/p> Если обмен завершен и клиент не намерен выдавать какие-либо запросы, связь прерывается. Клиент посылает сообщение \020ОООООО\000, на что сервер откликается посылкой строки \02ООООООО\000 (6 символов ‘О’ в первом и 7 – во втором случае). Какой-либо смысловой нагрузки этот обмен не несет, по этой причине некоторые пакеты его не производят.
В рамках UUCP предусмотрено несколько вспомогательных протоколов.
g-протокол
предназначен для коррекции ошибок и поддерживается всеми версиями UUCP. Стандартная ширина окна в этом протоколе равна 3, а размер пакета 64 байтам, но в принципе предусмотрена возможность расширения окна при реализации потоков до 7 при размере пакетов 4096 байт. Протокол базируется на стандартных пакетных драйверах. Для реализации g-протокола используются пакеты с 6-байтовыми заголовками (управляющие пакеты содержат только заголовок). Формат этих пакетов представлен на рис. 4.4.14.1.1.
Рис. 4.4.14.1. Формат пакетов g-протокола
Пакет начинается с восьмеричного кода 020, далее следует поле k (1 Ј k Ј 9). Для управляющих пакетов k=9. Для информационных пакетов k определяет размер поля данных. k=1 соответствует 32 байтам данных, а k=9 – 4096 байтам. Далее следуют два байта контрольной суммы, контрольный байт, определяющий тип пакета, и xor-байт. Последний равен результату операции xor для полей k, младшего байта контрольной суммы, старшего байта контрольной суммы и контрольного байта. Этот байт служит для контроля целостности заголовка пакета.
Управляющий байт заголовка содержит в себе три субполя (ttxxxyyy). Поле tt может принимать следующие значения.
| 0 | Указатель управляющего пакета (k должно быть равно 9). При этом поле xxx определяет тип управляющего пакета; |
| 1 | Не используется UUCP; |
| 2 | Информационный пакет; |
| 3 | Короткий информационный пакет. |
Один байт данных пересылается в любом случае. Для всех типов информационных пакетов поле ххх определяет порядковый номер пакета, а поле yyy определяет номер последнего пакета, принятого без ошибки, что и определяет максимальный размер окна, равный 7. Каждая из сторон, участвующих в обмене, использует окно, чтобы регистрировать число пакетов, которое может быть послано без получения подтверждения. Размер этого окна может лежать в пределах 1-7. Пакеты посылаются строго по очереди, получение всех пакетов должно быть подтверждено в том порядке, в каком они были посланы.
В пакетах управления поле ххх может принимать следующие значения:
| CLOSE | Соединение должно быть оборвано немедленно (например, обнаружено слишком много ошибок). |
| RJ или NAK | Последний пакет доставлен с ошибкой. В поле ууу записан номер последнего пакета, доставленного корректно. |
| SRJ | Выборочный отказ. Поле ууу содержит номер пакета, доставленного с ошибкой. Пакет должен быть послан повторно. В UUCP обычно не используется. |
| RR или ACK | Подтверждение получения пакета. Поле ууу содержит код номера последнего пакета, полученного корректно. |
| INITA | Первый пакет инициализации. Поле ууу содержит код максимального размера окна. |
| INITB | Второй пакет инициализации. Поле ууу содержит код размера пакетов, который планируется использовать. |
| INITC | Третий пакет инициализации. Поле ууу содержит размер окна, который будет использован. |
Int
igchecksum (z, c)
| register const char *z; | |
| register int c; |
| register unsigned int ichk1, ichk2; | |
| ichk1 = 0xffff; | |
| ichk2 = 0; | |
| do | |
| { | |
| register unsigned int b; |
/p> /* rotate ichk1 left. */
| if ((ichk1 & 0x8000) == 0) | ||
| ichk1 | ||
| else | ||
| { | ||
| ichk1 | ||
| ++ichk1; | ||
| } |
| b = *z++ & 0xff; | |
| ichk1 += b; |
ichk2 += ichk1 ^ c; /* if the character was zero, or adding it to ichk1 caused an overflow, xor ichk2 to ichk1. */
| if (b == 0 || (ichk1 & 0xffff) < b) | |
| ichk1 ^= ichk2; | |
| } | |
| while (--c > 0); | |
| return ichk1 & 0xffff; |
Когда g-протокол запускается в работу, посылается управляющий пакет INITA с кодом желательного значения максимального размера окна. Сервер откликается пакетом INITA со своим предложением размера окна. После этого аналогичный обмен производится пакетами INITB и INITC. В результате каждая из сторон может использовать свой размер окна и длину посылаемых пакетов.
Когда UUCP выдает команду, посылается один или более пакетов. В конце команды всегда посылается нулевой байт, который указывает на завершение командной строки. Когда пересылается файл, его завершение отмечается коротким информационным пакетом, содержащим нули. Прекращение работы протокола осуществляется посылкой управляющего пакета close.
f-протокол
. Этот протокол предназначен для пересылки 7-битных текстовых файлов. Здесь используются только символы от \040 (пробел) до \176 (~) и возврат каретки. Протокол весьма не эффективен для транспортировки 8-битовых данных. Его система контрольного суммирования не слишком надежна для больших файлов. Первоначально этот протокол предназначался для работы в сетях Х.25. В f-протоколе не предусмотрена процедура инициализации. При пересылке команды передается строка, завершающаяся символом возврат каретки. В процессе передачи файлов каждый байт b преобразуется в соответствии с таблицей.
| 0 | b | 0172, b + 0100 | (0100 дo 0137) |
| 040 | b | b |
(040 до 0171) |
| 0172 | b | 0173, b – 0100 | ( 072 до 077) |
| 0200 | b | 0174, b – 0100 | (0100 до 0137) |
| 0240 | b | 0175, b – 0200 | ( 040 до 0171) |
| 0372 | b | 0176, b – 0300 | ( 072 до 077) |
/p> Таким образом, байты между \040 и \ 171 включительно передаются без изменений, остальные перед отправкой преобразуются. Когда файл данных переслан, посылается 7-байтовая последовательность, включающая в себя два байта \176, за которыми следует 4 ASCII байта контрольной суммы (в шестнадцатеричном формате) и символ возврата каретки. Если контрольная сумма равна 0x1a2b, то будет послана последовательность \176\1761a2b\r.
При вычислении контрольной суммы туда сначала заносится код 0xffff. Для вычисления контрольной суммы (ichk) используется следующая программа, которая выполняется перед отправкой каждого байта.
/* rotate the checksum left. */
| if ((ichk & 0x8000) == 0) | |
| ichk | |
| else | |
| { | |
| ichk | |
| ++ichk; | |
| } |
| ichk += b; |
| G | Файл принят без ошибок; |
| R | Ошибка в контрольной сумме, файл надо передать повторно; |
| Q | Контрольная сумма неверна, но уже совершено много попыток и сессию следует прервать |
e-протокол
. Протокол подобен t-протоколу. Но здесь нет управления потоком и контроля ошибок. При посылке команды передается командная строка, завершающаяся нулевым байтом. При пересылке файла сначала посылается код его размера в виде ASCII десятичных цифр. Эта строка дополняется до 20 символов нулевыми байтами. Так, если длина файла 40000 байт, сначала посылается последовательность 40000\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0, после чего посылается собственно файл.
G-протокол
. Протокол используется SVR4 UUCP. Он идентичен G-протоколу за исключением того, что можно модифицировать окно и размер пакетов. В SVR4 реализации G-протокола размер окна всегда равен 7 а длина пакета 64 байтам.\
i-протокол
. Протокол написан Яном Лансом Тейлором и использован в taylor UUCP. Это протокол пересылки данных со скользящим окном, подобно G-протоколу. Но в отличие от этого протокола i-протокол поддерживает обмен данными в двух направлениях одновременно. Пакеты в этом протоколе имеют 6-байтовый заголовок. За полем данных следует 4-байтовая контрольная сумма. Определено 5 типов пакетов: DATA, SYNC, ACK, NAK, SPOS и CLOSE. Все они могут содержать поле данных. Пакеты типа DATA, SPOS и CLOSE имеют порядковые номера. Каждая из сторон нумерует пакеты независимо по модулю 32. Каждый из пакетов характеризуется локальным и удаленным номерами каналов. Каждому типу команд в локальной системе ставится в соответствие ненулевой локальный номер канала. Аналогичное правило справедливо и для удаленной системы. Это позволяет решить проблему одновременного двухстороннего информационного обмена. Для каждого файла протокол формирует указатель, в исходный момент равный нулю. После получения очередного пакета указатель соответствующим образом инкрементируется. Исключение представляют пакеты типа spos, которые служат для изменения указателя файла. Формат пакета i-протокола представлен на рис. 4.4.14.1.2.
Рис. 4.4.14.1.2. Формат пакета i –протокола
Заголовок начинается с флага ^g (восьмеричный код \007), далее следует 5-битовое поле пакет. Пакеты DATA, SPOS и CLOSE используют это поле для номера пакета. В пакетах NAK сюда заносится номер пакета, подлежащий повторной пересылке. В пакетах же ACK и SYNC это поле заполняется нулями. Поле ACK содержит 5 бит и служит для записи номера последнего пакета, принятого без ошибки. Это поле используется всеми типами пакетов. В трехбитовое поле тип определяет назначение пакета и может принимать следующие значения.
| 0 ‘DATA’ | Информационный пакет; |
| 1 ‘SYNC’ | Пакет sync используется при инициализации соединения, поле пакет в для этого типа обнуляется; |
| 2 ‘ACK’ | Пакет-отклик. Так как пакет типа data также может использоваться для отклика, ack предназначен для случая, когда одной из сторон нечего посылать. Пакеты ack не нумеруются. |
| 3 ‘NAK’ | Отрицательное подтверждение. Пакет посылается, когда при приеме произошла ошибка. В этом случае в поле пакет записывается номер пакета, подлежащего повторной пересылке. |
| 4 ‘SPOS’ | Пакет служит для изменения указателя файла. Пакет содержит 4 байта указателя файла (наиболее значащий байт первый). |
| 5 ‘CLOSE’ | Пакет служит для сообщения о прерывании связи. Противоположная сторона должна откликнуться пакетом CLOSE. |
/p> Однобитовое поле d =1 для пакетов клиента и = 0 для пакетов сервера. Поле длины поля данных состоит из двух секций (полный байт содержит младшую часть), имеет суммарную протяженность 12 бит, что позволяет варьировать поле данных в пределах от 0 до 4095 байт. Однобайтовое поле контрольная сумма содержит код, который представляет собой результат операции XOR, выполненной для байт заголовка, начиная со второго по пятый. После заголовка следует поле данных, за которым помещается 32-разрядная контрольная сумма информационного поля (CRC).
При инициализации i-протокола стороны обмениваются SYNC-пакетами, которые содержат по крайней мере 3 байта. Первые два байта несут в себе максимальный размер пакетов, посылаемых удаленной стороной (старший байт первый). Третий байт определяет размер окна, используемый удаленной стороной. При этом могут посылаться пакеты любого размера, но не больше указанного максимального. Если SYNC содержит четвертый байт, то он хранит в себе номер канала (1-7), который может использовать удаленная система. Размер окна определяет число пакетов, которое может быть послано, не дожидаясь подтверждения получения. Подтверждаться может не каждый пакет. Если получено подтверждение получения пакета n, все предшествующие считаются полученными корректно. Если потерян пакет, посланный одной из сторон, другая может передавать пакеты, как ни в чем не бывало. Команды посылаются в виде последовательности информационных пакетов с ненулевым полем номера локального канала. Последний из пакетов в этом случае должен содержать нулевой байт в конце (обычно команда укладывается в один пакет). Файла передаются в виде последовательности пакетов, завершающейся пакетом нулевой длины. При получении отклика sn пересылка файла абортируется. Применение номеров каналов позволяет посылать команды и пересылать файлы одновременно.
j-протокол
. Этот протокол является разновидностью i-протокола написанного тем же автором. Протокол предназначен для коммуникационных каналов с возможностью перехвата некоторых символов, например xon или xoff. Протокол не выполняет детектирования или исправления ошибок. При инициализации j-протокола системы обмениваются последовательностями печатных ascii-символов, чтобы указать, какие из них стороны хотят исключить из употребления. Такая последовательность должна начинаться с символа ^ (восьмеричный код 136) и завершаться символом ~ (восьмеричный код 176). После отправления такой строки система ждет аналогичной посылки с противоположной стороны. Строки состоят из esc-последовательностей типа \ooo, где o – восьмеричная цифра. Например, посылка последовательности ^\021\023~ означает, что следует избегать символов xon и xoff. Блокировка использования символов из диапазона \040 - \176 запрещена. После указанного обмена включается стандартный i-протокол, но пакеты i-протокола вкладываются в j-пакеты. Заголовок j-пакетов содержит 7 байт. Формат заголовка пакета j-протокола показан на рис. 4.4.14.1.3.
Рис. 4.4.14.1.3. Формат заголовка j-пакета
Заголовок начинается с кода символа ^. Далее следует два байта поля длина (первый из них старший), которые характеризуют полную длину пакета в байтах. Запись в этом поле осуществляется в виде ascii-символов. Истинная длина пакета вычисляется согласно формуле: (l1 – 040)*0100 + (l2 – 040), где 040 Ј l1 < 0177 и 040 Ј l2 < 0140. После поля длина следует байт 075 (символ =), за которым следует два байта длины поля данных (равна размеру вложенного i-пакета в октетах). Заголовок завершается символом @ (восьмеричный код 0100). Все символы, запрещенные к использованию при инициализации, в случае их наличия в i-пакете подменяются печатными ASCII-символами. При этом для каждой такой подмены вводится два индексных байта (index-h и index_l). Индексные байты непосредственно следуют за байтами данных. В индексных байтах закодировано положение “запретного” символа в i-пакете. Преобразование запретных символов производится следующим образом. Если код символа больше или равно 0200, из него вычитается 0200, если при этом результат меньше 020 или равен 0177, над ним производится операция xor 020. Индексные байты представляют собой ASCII-символы. Истинное положение запретного символа вычисляется по формуле: (index-h – 040) * 040 + (index_l – 040). Значение index_l должно лежать в пределах 040 Ј index_l < 0100, а index-h – 040 Ј index-h < 0176.
x-протокол
. Протокол ориентирован на машины со встроенными картами Х.25 и предназначен для непосредственной пересылки 8-битовых данных без взаимодействия со слоями Х.28 или Х.29. Пересылка осуществляется 512 байтными пакетами.
y-протокол
. Протокол разработан Йоргом Квиком и используется в FX uucico. Протокол осуществляет контроль и коррекцию ошибок, он предназначен для передачи 8-битовых данных в поточном режиме. Здесь не предусмотрено подтверждения получения пакетов, по этой причине протокол удобен для полудуплексных каналов. Каждый пакет имеет 6-байтовый заголовок. Формат заголовка для y-пакетов показан на рис. 4.4.14.1.4.
Рис. 4.4.14.1.4. Формат заголовка для y-пакетов
Первое поле номер содержит два байта номера пакета, причем первый из байтов является младшей частью номера (это справедливо и для других полей заголовка). Нумерация начинается с нуля. Так как первый пакет всегда SYNC, информационные пакеты имеют номера, начиная с 1. Каждая из систем, участвующих в обмене, нумеруют пакеты независимо. Если старший бит 16-битового поля длины равен нулю, то в этом поле записано число байт в поле данных, следующем за заголовком. Если же старший бит равен 1, то данных в пакете нет, а сам он является управляющим пакетом. В этом случае поле длина определяет тип пакета. Содержимое двухбайтового поля контрольная сумма вычисляется по программе, приведенной в описании протокола f. Для пакетов, не содержащих данных, контрольная сумма равна нулю. Инициализация протокола начинается с того, что стороны обмениваются SYNC-пакетами. SYNC-пакет должен содержать по меньшей мере 4 байта данных. Первый из них содержит код версии протокола. Далее следует байт длины пакета, которая измеряется в блоках по 256 байт (максимальный размер поля данных 32768 байт, что соответствует коду длины 128). Завершается блок данных пакета SYNC двумя байтами флагов. В настоящее время их функции не определены и их следует обнулять. Определены следующие типы управляющих пакетов.
| 0хFFFE ‘YPKT_ACK’ | подтверждение корректного приема файла; |
| 0xFFFD ‘YPKT_ERR’ | указывает на ошибку в контрольной сумме; |
| 0xFFFC ‘YPKT_BAD’ | указывает на ошибку в порядковом номере, в поле длины или какую-либо еще ошибку. |
Существуют также d-, h- и v-протоколы UUCP, но они не имеют заметного применения.
