binkp11-ru.txt

Binkp/1.1



  Предыдущие, binkp/1.0-совместимые, мэйлеры могли передавать с сообщение M_NUL
  вида "VER mailer-version binkp/1.0". Binkp/1.1 предполагает, что подобное
  сообщение (в формате "VER mailer-version binkp/1.1") будет формировать и
  парсить, после приема на другой стороне, любой совместимый с binkp версий 1.1
  и выше мэйлер.
  Это сообщение должно быть передано к тому времени, когда сервер и клиент
  обменяются паролем и подтверждением логина. Если это сообщение не было
  получено до этого момента, то мы можем считать версию протокола
  противоположной стороны равной 1.0
  Еще одно сообщение M_NUL, которое надо по возможности понимать: M_NUL "OPT XXX
  YYY ..." -- способ передачи произвольных опций (список имен опций
  case-sensitive, через пробел). Binkd/0.9 понимает опцию "NR": просьбу перейти
  в NR-mode (Пример запроса: M_NUL "OPT NR"). Вообще говоря, передав такую
  команду, мы не можем быть уверены, что remote обязательно последует нашей
  просьбе, и, в общем случае, у нас нет способа узнать ее решение (кроме как
  специально оговорить необходимость посылки ответного сигнала при виде опции
  XXX). В случае с NR, любое поведение remote не должно нас смутить (см. ниже)
  Для того, чтобы иметь возможность принимать запросы (FREQs, в частности) и
  отправлять их результаты назад за одну сессию, в случае, если с другой стороны
  binkp/1.1 и выше, binkd 9.0 следует следующему соглашению -- когда обе стороны
  обменялись EOB, сессия не завершается, а перезапускается сбросом binkp в
  состояние, которое он имел сразу после логина (то есть выполняется рескан и
  начинается отсылка найденных файлов). Сессия считается успешно завершенной,
  если между двумя последовательными обменами EOF стороны не передали и не
  приняли ни одной команды binkp.
  Hадо обязательно корректно реагировать на M_FILE "name size time -1": отвечать
  на него подходящим M_GET (см. ниже)
  Раньше binkd всегда начинал передавать каждый новый файл со смещения 0.
  Противоположная сторона, обнаружив у себя в inbound'е часть недопринятого
  файла, могла перезапросить этот файл с другого смещения. Проблема в том, что
  такая оптимизация делает линк совершенно неработоспособным в случае, если на
  нем часты таймауты: к моменту, когда передатчик получает M_GET, его буфера и
  окно TCP уже забито данными этого же файла, передаваемыми с 0, и они не
  успевают освободиться для данных с нового смещения до падения соединения.
  Теперь передатчики имеют возможность опционально, только на ненадежных линках,
  (ибо такое поведение, все-таки, реально неэффективно) перед посылкой каждого
  нового файла запрашивать действительно необходимое приемнику смещение в
  передаваемом файле с помощью M_FILE "name size time -1". Какой-то
  предварительной договоренности с противоположной стороной перед посылкой этой
  команды не требуется (кроме уверенности, что версия remote > 1.0).
  Я называю это "NR mode" (от "Not Reliable link"). Итак, мы можем в любой
  момент перейти в NR mode самостоятельно, мы можем в любой момент попросить
  перейти в NR mode remote командой M_NUL "OPT NR".


(c) Copyright 1997 by Dima Maloff
Id: binkp11.html,v 1.4 1998/10/08 07:32:21 maloff Exp