Binkp/1.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

2. Еще одно сообщение M_NUL, которое надо по возможности понимать: M_NUL "OPT XXX YYY ..." -- способ передачи произвольных опций (список имен опций case-sensitive, через пробел). Binkd/0.9 понимает опцию "NR": просьбу перейти в NR-mode (Пример запроса: M_NUL "OPT NR"). Вообще говоря, передав такую команду, мы не можем быть уверены, что remote обязательно последует нашей просьбе, и, в общем случае, у нас нет способа узнать ее решение (кроме как специально оговорить необходимость посылки ответного сигнала при виде опции XXX). В случае с NR, любое поведение remote не должно нас смутить (см. ниже)

3. Для того, чтобы иметь возможность принимать запросы (FREQs, в частности) и отправлять их результаты назад за одну сессию, в случае, если с другой стороны binkp/1.1 и выше, binkd 9.0 следует следующему соглашению -- когда обе стороны обменялись EOB, сессия не завершается, а перезапускается сбросом binkp в состояние, которое он имел сразу после логина (то есть выполняется рескан и начинается отсылка найденных файлов). Сессия считается успешно завершенной, если между двумя последовательными обменами EOF стороны не передали и не приняли ни одной команды binkp.

4. Hадо обязательно корректно реагировать на M_FILE "name size time -1": отвечать на него подходящим M_GET (см. ниже)

5. Раньше 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".