Hello Alexey!
03 Июня 2025, Alexey Khromov wrote to Konstantin Kuzov:
Если ещё вдруг актуально, то это просто декларирование что мейлер
поддерживает прием дополнительных параметров в командах протокола
и его при их получении не перекосит. К примеру, если нет EXTCMD,
то можно считать что передача с компрессией удаленной стороной не
поддерживается, даже при предъявлении всяких BZ2 и т.п. Ибо
указание
Я так тоже подумал исходя из исходников binkd, но мало ли -
какую-нибудь спеку или описание кто придумал.
Единственные однозначные спеки по binkp - это то что было от оригинального автора:
1)
https://web.archive.org/web/20190910090353/http://binkd.grumbler.org/binkp/binkp.html.koi.ru - binkp/1.0
2)
https://web.archive.org/web/20190913093952/http://binkd.grumbler.org/binkp/binkp11.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.
алгоритма компрессии идёт дополнительным, пятым, аргументом в
M_FILE что выходит за спеки binkp 1.0/1.1.
А вот за такую подробность огромнейшее спасибо. Есть мысль прикрутить все-же компрессию к 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)