********************************************************************** FTSC FIDONET TECHNICAL STANDARDS COMMITTEE ********************************************************************** Publication: FSP-1027 Revision: Draft-1 Title: Binkp extensions: No Dupes mode and No Dupes Asymmetric mode (russian text) Author: Stas Degteff Revision Date: 2003-10-20 Expiry Date: ---------------------------------------------------------------------- Contents: 1. Введение 2. Определения 3. No Dupes mode 4. No Dupes Asymmetric mode 5. Glossary 6. Acknowledgements 7. References A. Contact information B. History ---------------------------------------------------------------------- Abstract -------- Этот документ описывает два расширения протокола binkp: "No Dupes mode" и "No Dupes asymmetric mode". ---------------------------------------------------------------------- 1. Введение ----------- Протокол binkp был разработан для использования на надежных каналах связи, защищенных от помех. На практике он был внедрен для передачи FTN-трафика по сетям с транспортным протоколом TCP (Internet и Intranet). При этом канал связи может оказаться недостаточно надежным, например при сеансовом доступе (dial-up) соединение на физическом уровне обрывается в непредсказуемые моменты времени, при этом в следующем сеансе связи возникал избыточный трафик. Чтобы избежать лишнего трафика на нестабильных каналах связи, Dmitry Maloff разработал расширение протокола под названием "Non-Reliable mode" (см. [NR]). Но при использовании этого расширения в некоторых ситуациях все же происходила повторная передача одного и того же файла (хотя и значительно реже, чем в чистом binkp). Чтобы исключить дублирование файлов, было разработано новое расширения протокола "No Dupes mode", при использовании которого полностью исключается повторная передача файла в binkp. К сожалению, применение No Dupes mode замедляет процесс передачи файлов. В дальнейшем, для повышения производительности на анизотропных каналах связи (например, исходящий поток по модему, а входящий - по спутниковому каналу), а также для удобства системных операторов было разработано расширение протокола "No Dupes Asymmetric mode", в котором каждая сторона может задать режим для приема файлов в свою сторону. ND mode впервые реализована в мэйлере binkd версии 0.9.3, NDA mode - в мэйлере binkd версии 0.9.5. 2. Определения -------------- Встречающиеся в тексте ключевые слова "МОЖЕТ" ("MAY"), "МОЖЕТ НЕ" ("MAY NOT"), "ДОЛЖЕН" ("SHOULD"), "НЕ ДОЛЖЕН" ("SHOULD NOT"), "ТРЕБУЕТСЯ" ("REQUIRED"), "ОБЯЗАТЕЛЬНО ДОЛЖЕН" ("MUST"), "ОБЯЗАТЕЛЬНО ДОЛЖЕН НЕ" ("MUST NOT"), "НЕ РЕКОМЕНДУЕТСЯ" ("NOT RECOMMENDED"), "РЕКОМЕНДУЕТСЯ" ("RECOMMENDED") должны быть интерпретированы так, как они описаны в документе [FTA-1006]. В тексте ключевые слова выделены верхним регистром букв. Остальные термины перечислены в Глоссарии. 3. No Dupes mode ---------------- Общие сведения -------------- Расширение протокола binkp "No Dupes mode" предотвращает повторную передачу файла после обрыва сеанса связи. Это достигается за счет увеличения продолжительности сеанса и сохранения статуса последнего сеанса на передающей стороне. Далее для "No Dupes mode" используется сокращение "ND mode" или "режим ND". ND mode подразумевает NR mode (см. [NR]). Разработчики строго РЕКОМЕНДУЮТ использовать ND mode только совместно с протоколом binkp 1.1 (см. [BINKP 1.1]) во избежание ошибок (ND mode использует дополнительный фрейм 'M_EOB' протокола binkp 1.1 для окончательного подтверждения). Индикация поддержки ND mode удаленному мэйлеру ---------------------------------------------- Мэйлер сообщает о поддержке ND mode, посылая фрейм 'M_NUL "OPT ND"' на стадии хэндшейка binkp. ND mode разрешен только если обе стороны предъявили поддержку. В противном случае мэйлер ОБЯЗАТЕЛЬНО ДОЛЖЕН считать, что удаленный мэйлер не поддерживает режим ND и ОБЯЗАТЕЛЬНО ДОЛЖЕН НЕ использовать это расширение протокола. Мэйлер на вызывающей стороне ОБЯЗАТЕЛЬНО ДОЛЖЕН отправить фрейм 'M_NUL "OPT NR ND"' (опция NR передается, поскольку ND mode подразумевает NR mode). Мэйлер на отвечающей стороне может не передавать опцию 'NR', ему достаточно отправить только 'M_NUL "OPT ND"' (ДОЛЖЕН отправить фрейм 'M_NUL "OPT ND"'). Изменения протокола и действия мэйлера в режиме ND -------------------------------------------------- Изменения в обмене файлами относительно NR mode: 1. Передатчик ожидает фрейм M_GOT (или M_SKIP), соответствующий только что переданному файлу, прежде чем начать передачу следующего файла из очереди. 2. Получатель сохраняет полученный файл во временном хранилище и ждет фрейм M_FILE или фрейм M_EOB. После чего считает файл окончательно принятым и перемещает (переименовывает) его в основной inbound-каталог. (Временное хранилище зависит от реализации: это может быть специальный каталог, либо неполностью принятый файл может иметь специальный атрибут если это позволяет файловая система, либо что-то другое.) 3. Отправитель сохраняет информацию о файле, для которого не получено подтверждение от принимающей стороны, в статусе сеанса (обычно это файл, формат которого зависит от реализации). Эта информация ОБЯЗАТЕЛЬНО ДОЛЖНА содержать адрес удаленной системы, имя файла, его размер и время модификации. В статусе сеанса также может сохраняться другая информация. Последовательность передачи файла в ND mode ------------------------------------------- Назовем одну сторону "Синей", вторую "Зеленой". Будем считать, что временное хранилище для принимаемых файлов - отдельный каталог и что статус сеанса хранится в файле на диске. 1. "Синий" мэйлер готов передавать файлы, "Зеленый" мэйлер готов принимать файлы. 1a. В статусе сеанса "Синего" хранится информация о файле file1 размером size1 и временем модификации time1, подтверждение о приеме которого он не получил от "Зеленого". Этот файл находится в очереди на отправку (в спуле на диске) с теми же параметрами (т.е. файл не изменен, например, тоссером). 1b. В спуле для "Зеленого" "Синий" видит файл file1 размером size1 и временем модификации time1. 2. "Синий передает фрейм 'M_FILE "file1 size1 time1 -1"' 3a. "Зеленый" принимает фрейм 'M_FILE "file1 size1 -1"' и передает фрейм 'M_GET "file1 size1 offset1"', где offset1 равен нулю в том случае, если файл не существует и равен размеру ранее принятой части файла если файл существует. 3b. "Зеленый" принимает фрейм 'M_FILE "file1 size1 -1"' и передает фрейм 'M_SKIP "file1 size"'. 4a. "Синий" принимает фрейм 'M_GET "file1 size1 time1 offset1"' и очищает в статусе сеанса запись о передаче файла file1 "Зеленому". (Переходим к шагу 5.) 4b. "Синий" принимает фрейм 'M_SKIP "file1 size1 time1"' и оставляет запись о файле file1 в статусе сеанса. (Переходим к шагу 10.) 4с. "Синий" принимает фрейм 'M_GOT "file1 size1 time1"' и очищает в статусе сеанса запись о передаче файла file1 "Зеленому". (Переходим к шагу 9.) 5. "Синий" передает фрейм 'M_FILE "file1 size1 time1 offset1"' и записывает в статусе сеанса информацию о передаче файла file1 "Зеленому". 6. "Синий" передает фреймы с данными файла file1. 7. "Зеленый" сохраняет принятые данные во временный файл пока их размер не достигнет заявенного во фрейме M_FILE. 8. "Зеленый" передает фрейм 'M_GOT "file1 size1 time1"' 9. (После приема фрейма 'M_GOT "file1 size1 time1"') "Синий" сохраняет статус сеанса на диск и удаляет переданный файл file1. 10. "Синий" передает фрейм 'M_FILE "file2 size2 time2 -1"' или фрейм M_EOB 11. "Зеленый" принимает фрейм M_FILE или M_EOB и перемещает файл file1 из временного хранилища в постоянное место. ... Если сеанс связи прерывается между шагами 8 и 11, "Зеленый" не перемещает файл "file1" до тех пор, пока не примет от "Синего" фрейм 'M_FILE "file1 size1 time1 size1"' или фрейм M_FILE для нового файла. Подробности реализации. ----------------------- Если удаленный мэйлер предъявил несколько AKA, локальный мэйлер ДОЛЖЕН проверить статус для всех предъявленных AKA, в том числе для тех AKA, работа с которыми заблокирована тоссером или иной программой. Это необходимо для предотвращения потери статуса сеанса и, как следствия, дублирования или потери файла для/от занятых на момент этого сеанса AKA удаленной стороны. Если удаленный мэйлер уже переместил принятый файл в инбаунд из временного хранилища, но этот файл присутствует в статусе сеанса локального мэйлера, локальный мэйлер отправляет запрос на передачу этого файла (фрейм M_FILE со смещением -1). Удаленный мэйлер воспринимает этот файл как новый и отвечает фреймом M_GET со смещением 0. Чтобы избежать повторной передачи файла, локальный мэйлер ДОЛЖЕН ответить фреймом M_FILE со смещением 0, но НЕ ДОЛЖЕН передавать данные. Следующим фреймом он ДОЛЖЕН передать запрос на отправку следующего файла из очереди (фрейм M_FILE "newfile size time -1") или сигнализировать о пустой очереди (фрейм M_EOB). Удаленный мэйлер при этом МОЖЕТ сгенерировать диагностику "file transfer interrupted" и ОБЯЗАТЕЛЬНО ДОЛЖЕН продолжить работу: если принял фрейм M_FILE - отправить фрейм M_GET "newfile size time offset", если принял фрейм M_GOT - действовать в зависмости от состояния очереди на отправку. Двойные фреймы M_EOB в конце сеанса, реализованные в binkp 1.1 (см. [BINKP 1.1]), гарантируют отправителю подтверждение переименования файла на принимающей стороне. РЕКОМЕНДУЕТСЯ, чтобы мэйлер сохранял для каждого принятого файла информацию об отправителе и проверял статус только тех файлов, которые приняты от текущего линка, чтобы избежать путаницы с файлами от разных линков, имеющими одинаковые имена. Фаза передачи файлов ОБЯЗАТЕЛЬНО ДОЛЖНА начинается с передачи статуса сеанса, независимо от того, включены ли режимы ND или NR, с целью предотвратить потерю принятого и сохраненного во временном хранилище, но не перемещенного в инбаунд файла. РЕКОМЕНДУЕТСЯ, чтобы мэйлер делал недеструктивный скип файла (используя binkp фрейм M_SKIP) в том случае, когда адрес, от которого этот файл был частично принят в предыдущем сеансе связи, занят другим процессом (например, при использовании BSO в аутбаунде обнаружен файл *.BSY, соответствующий предъявленному с противоположной стороны адресу). Для предотвращения потери информации о статусе сеанса при сбое (аварийном завершении мэйлера, пропадании электропитания и т.п.) разработчики рекомендуют сохранять статус сеанса на диск при каждом его изменении, а не только по завершении сеанса. Из соображений совместимости при использовании BSO, ASO и т.п. видов аутбаунда разработчики рекомендуют сохранять статус сеанса в виде строки в формате параметра ожидаемой для этого файла команды M_GOT в файле с именем вида .stc, где соответствует адресу удаленной стороны в формате используемого аутбаунда. Пример binkp-сессии в режиме ND ------------------------------- Следующий простой пример демонстрирует передачу файлов по протоколу binkp 1.1 (см. [BINKP 1.1]) с включенным расширением "ND mode". В примере файлы передаются только с одной стороны (на другой стороне очередь пуста). "Master" передает файлы, "slave" принимает файлы. ">>" обозначает отправку, "<<" обозначает прием. ------------------------------------------------------------------- master slave ------------------------------------------------------------------- ===== При наличии в сохраненном статусе информации о переданном ===== файле "X" (файл статуса линка "slave" у "master" содержит ===== строку "X sizeX timeX") >> M_FILE X -1 << M_FILE X -1 >> M_GET X >> M_FILE X << M_FILE X >> M_GOT X << M_GOT X ===== прием файла "X" завершен >> M_FILE A -1 << M_FILE A -1 <если X существует во временном хранилище, перемещаем его на постоянное место (в инбаунд)> >> M_GET A << M_GET A <устанавливаем статус в ""> >> M_FILE A >> DATA << M_FILE A << DATA >> M_GOT A << M_GOT A <устанавливаем статус в "A sizeA timeA"> <удаляем A из очереди> >> M_FILE B -1 << M_FILE B -1 <перемещаем A> >> M_GET B << M_GET B <устанавливаем статус в ""> >> M_FILE B >> DATA << M_FILE B << DATA >> M_GOT B << M_GOT B <устанавливаем статус в "B sizeB timeB"> <удаляем B> >> EOB << EOB <перемещаем B> ... >> EOB >> EOB << EOB << EOB <устанавливаем статус в ""> <завершаем сеанс> <завершаем сеанс> ------------------------------------------------------------------- 4. No Dupes Asymmetric mode --------------------------- Общие сведения -------------- Расширение протокола binkp "No Dupes Asymmetric mode" является развитием расширения "No Dupes mode". Оно бладает улучшенной производительностью на асимметричных каналах, когда скорость в одном направлении высокая, а в противоположном - низкая, либо в других случаях. Далее для "No Dupes Asymmetric mode" используется сокращение "NDA mode" или "режим NDA". NDA mode позволяет использовать ND mode в одном или обоих направлениях. NDA mode подразумевает ND mode (см. предыдущую главу) и NR mode (см. [NR]). Для работы NDA mode РЕКОМЕНДУЕТСЯ протокол binkp версии не ниже 1.1 во избежание ошибок (как и для ND mode). Индикация поддержки NDA mode удаленному мэйлеру ----------------------------------------------- Мэйлер сообщает о поддержке NDA mode, посылая фрейм 'M_NUL "OPT NDA"' на стадии хэндшейка binkp. NDA mode разрешен только если обе стороны предъявили поддержку. В противном случае мэйлер ОБЯЗАТЕЛЬНО ДОЛЖЕН считать, что удаленный мэйлер не поддерживает режим ND и ОБЯЗАТЕЛЬНО ДОЛЖЕН НЕ использовать это расширение протокола. В настройке мэйлера может быть разрешен режим NDA для приема файлов и задано пожелание работать в ND mode на передачу. Чтобы сообщить об этом удаленной стороне, мэйлер ДОЛЖЕН отправить binkp фрейм с указанием опций ND и NDA: 'M_NUL "OPT ND NDA"' (порядок следования опций не существенен). В настройке мэйлера может быть указан запрет на использование режима NDA при приема файлов и указано пожелание использовать режим NDA при отправке файлов. Об этом мэйлер сообщает фреймом 'M_NUL "OPT ND"', как и при поддержке только ND mode и отсутсвии поддержки NDA mode. Фаза хендшейка с учетом NDA mode -------------------------------- Следующая таблица содержит все варианты хэндшейка и состояния режимов ND и NDA с обоих сторон. ----------+-----------+--------------+-------------+-------------- Call side | Call side | Answer side | Answer side | ND/NDA state want/allow| transmits | want/allow | transmits | ----------+-----------+--------------+-------------+-------------- none | - | don't care | don't care | - ND only | ND | not support | - | - ND allow | NDA | not support | - | - ND/NDA | NDA ND | not support | - | - ND only | ND | ND allow | ND | Bi-directional NDA allow| NDA | ND allow | ND | - ND/NDA | NDA ND | ND allow | ND | Bi-directional ND only | ND | NDA allow | ND | Bi-directional ND only | ND | want NDA | ND | Bi-directional NDA allow| NDA | want NDA | NDA ND | Call to answer NDA allow| NDA | not want NDA | - | - ND/NDA | NDA ND | want NDA | NDA ND | Bi-directional ND/NDA | NDA ND | not want NDA | NDA | Answer to call "Not support" обозначает, что режимы ND и NDA не поддерживаются. "ND allow" обозначает, что ND mode поддерживается и разрешена для этого линка. "NDA allow" обозначает, что режим NDA поддерживается мэйлером, при этом несущественно, разрешен ли NDA для этого линка. "Want NDA" обозначает, что режим NDA поддерживается и разрешен для линка. "Not want NDA" обозначает, что режим NDA поддерживается и не разрешен для линка, но режим ND разрешен. "Don't care" обозначает любой вариант в колоке "want/allow" и передачу любого сочетания опций в колонке "transmits". 5. Glossary ----------- AKA Дополнительный адрес FTN-системы. Расшифровка аббревиатуры AKA: "Also Knowwn As". binkp Протокол, разработанный для передачи трафика FTN-совместимых сетей по надежным каналам связи. FTN FTN compatible network Сеть передачи данных, построенная на стандартах и технологии, разработанных для Fidonet. Расшифровка аббревиатуры FTN: "Fidonet Technology Network". Мэйлер Почтовая программа Fidonet и других FTN-совместимых сетей. Осуществляет прием и передачу файлов между FTN-системами. Надежнй канал связи Надежное соединение Канал связи и соединение, обеспечивающие целостность данных. При этом используются управление передачей и исправление ошибок Сеанс Сеанс связи Временное соединение между двумя точками, производимое в три фазы: установление соединения, обмен данными, завершение соединения. Транспортный протокол Протокол транспортного уровня Протокол четвертого уровня по классификации семиуровневой модели OSI. TCP Транспортный протокол семейства протоколов TCP/IP, используемых в Internet. Устанавливает виртуальный канал связи для обмена потоками данных между твумя точками. Обеспечивает контроль целостности данных. Расшифровка аббревиатуры TCP: "Transmittion Control Protocol". См. также [RFC 793]. 6. Acknowledgements ------------------- Этот документ основан на авторском описании ND mode на русском языке. Автор ND mode: Paul Gulchouck. Авторы NDA mode: Paul Gulchouck и Stas Degteff. Автор binkp: Dmitry Maloff. 7. References ------------- [NR] Описание расширения протокола binkp "Non-Reliable mode". На момент написания этого документа им является FSP-1023 [BINKP 1.1] Описание протокола binkp 1.1. На момент написания этого документа им является FSP-102? [FTA-1006] FTSC Administrative document "Key words to indicate requirement levels". [RFC 793] Transmission Control Protocol. Darpa Internet Program. Protocol Specification. September 1981. A. Contact information ---------------------- Paul Gulchouck: 2:463/68@fidonet, gul@gul.kiev.ua Stas Degteff: 2:5080/102@fidonet, g@grumbler.org B. History ---------- Rev. Draft-1, 20031020: First public draft