@MSGID: 2:5019/40 683ed217
@REPLY: 2:5030/723 683ea5c8
@PID: GED+LNX 1.1.5-b20231008
@CHRS: CP866 2
@TID: hpt-nsf/linux a847f698b0 2025-02-28
Hello Alexey!

03 Июня 2025, Alexey Khromov wrote to Konstantin Kuzov:

 KK>> Если ещё вдруг актуально, то это просто декларирование что мейлер
 KK>> поддерживает прием дополнительных параметров в командах протокола
 KK>> и его при их получении не перекосит. К примеру, если нет EXTCMD,
 KK>> то можно считать что передача с компрессией удаленной стороной не
 KK>> поддерживается, даже при предъявлении всяких BZ2 и т.п. Ибо
 KK>> указание
 AK> Я так тоже подумал исходя из исходников binkd, но мало ли -
 AK> какую-нибудь спеку или описание кто придумал.

 Единственные однозначные спеки по binkp - это то что было от
оригинального автора:
https://web.archive.org/web/20190910090353/http://binkd.grumbler.org/binkp/binkp
.html.koi.ru - binkp/1.0
https://web.archive.org/web/20190913093952/http://binkd.grumbler.org/binkp/binkp
11.html.koi.ru - binkp/1.1
И суммарно с дополнениями в FSP-1011.03: https://www.ritlabs.com/binkp/
А также исходники binkd, как референсной имплементации. Всё.

 Остальное опубликованное в FTSC - это лишь интерпретации авторов
других реализаций типа MBSE и они могут содержать неточности. К примеру,
про ту же компрессию и EXTCMD: читая послесловие fsp-1024.000 (Binkp/1.1
Protocol specification) имеется утверждение что в чистой binkp/1.1 реализации
мейлер должен корректно проигнорировать доп.параметры, а не скажем послать по
азимуту с ошибкой или тупо разорвать сессию. Без упоминания что это завязано
именно на EXTCMD. Да и вообще может сложиться впечатление что пятый
аргумент в M_FILE - это расширение самого binkp/1.1, но это не так. В 1.1
для M_FILE добавилось лишь смещение равное -1 для NR-режима. Ибо
binkp/1.1 был реализован в binkd примерно в 1997 году ещё Маловым в районе
версии 0.9.0, тогда как компрессия была добавлена Хохловым и сверху
отполирована Гульчуком лишь в районе 2003 вкупе с добавлением EXTCMD.

 KK>> алгоритма компрессии идёт дополнительным, пятым, аргументом в
 KK>> M_FILE что выходит за спеки binkp 1.0/1.1.
 AK> А вот за такую подробность огромнейшее спасибо. Есть мысль прикрутить
 AK> все-же компрессию к bforce, но логику обмена понять надо.

 Там вроде в целом ничего сложного, если удаленная сторона не
поддерживает EXTCMD - отправлять на неё что либо с компрессией нельзя, но можно
от неё принимать. Если поддерживает EXTCMD, а также предъявляет OPT BZ2
и/или GZIP, то можно отправлять добавляя пятым параметром GZ для GZIP и
BZ2 для BZIP2 в M_FILE. Вроде MBCICO из MBSE ещё умеет PLZ в
дополнение к первым двум, а также CRC-расширение с отсылкой и проверкой
контрольной суммы файла (CRC32 алгоритм, фидошный вариант: стартовое значение
0xFFFFFFFF, полином 0xEDB88320 и битинверсия в конце), которое также использует
пятый аргумент и соответственно либо компрессия, либо проверка контрольной
суммы... Размер всё также отправляем несжатого файла. Далее поблоково
отправляем сжатый файл, а принимающая сторона на лету разжимает блоки и пишет
распакованное на диск по окончании файла сверяясь что присланный размер и итоговый
совпадают.

 Также стоит иметь в виду что в binkd до сих пор существует баг с
компрессией и скипом. Если удаленная сторона скипнет файл отсылаемый с
компрессией, то бинк пошлет следующий в очереди файл тоже с компрессией, даже
если этого не надо было делать. При этом к содержимому также скорее
всего присоединятся неотброшенные неотосланные сжатые остатки от предыдущего
файла из-за чего по-факту отошлется мусор и соединение сбросится на
удаленной стороне из-за несогласованности размера файла (rcvd XXX extra
bytes)...

Best of luck, Konstantin.

... GoldED+/LNX 1.1.5 (Linux 6.12.24-1-lts CPU UNKNOWN)
--- #[EMail: Master.NoSFeRaTU[@]Gmail.com] [Team Nyaa]#
 * Origin: GaNJaNET STaTi0N (2:5019/40)
SEEN-BY: 452/166 455/19 5001/100 5019/29 40 41 400
5020/101 545 715 848 1042
SEEN-BY: 5020/2992 4441 12000 5022/77 128 5029/32
5030/1081 1900 5060/900
SEEN-BY: 6055/7 6078/80
@PATH: 5019/40 5020/4441