binkp EXTCMD

Alexey Khromov написал(а) к All в Apr 25 09:33:35 по местному времени:

Здраствуйте, All!

Подскажите, где найти описание режима/расширения EXTCMD протокола binkp. на ftsc.org по этому поводу - ни слова.


Alexey Khromov
--- GoldED+/LNX 1.1.5-b20250409

Konstantin Kuzov написал(а) к Alexey Khromov в Jun 25 23:11:34 по местному времени:

Нello Alexey!

22 Апреля 2025, Alexey Khromov wrote to All:

AK> Подскажите, где найти описание режима/расширения EXTCMD протокола
AK> binkp. на ftsc.org по этому поводу - ни слова.

Если ещё вдруг актуально, то это просто декларирование что мейлер поддерживает прием дополнительных параметров в командах протокола и его при их получении не перекосит. К примеру, если нет EXTCMD, то можно считать что передача с компрессией удаленной стороной не поддерживается, даже при предъявлении всяких BZ2 и т.п. Ибо указание алгоритма компрессии идёт дополнительным, пятым, аргументом в M_FILE что выходит за спеки binkp 1.0/1.1.

Best of luck, Konstantin.

... GoldED+/LNX 1.1.5 (Linux 6.12.24-1-lts CPU UNKNOWN)
--- #[EMail: Master.NoSFeRaTU[@]Gmail.com] [Team Nyaa]#

Alexey Khromov написал(а) к Konstantin Kuzov в Jun 25 10:31:30 по местному времени:


Здраствуйте, Konstantin!

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

Я так тоже подумал исходя из исходников binkd, но мало ли - какую-нибудь
спеку или описание кто придумал.

KK> алгоритма компрессии идёт дополнительным, пятым, аргументом в M_FILE
KK> что выходит за спеки binkp 1.0/1.1.

А вот за такую подробность огромнейшее спасибо. Есть мысль прикрутить
все-же компрессию к bforce, но логику обмена понять надо.


Alexey Khromov
--- GoldED+/LNX 1.1.5-b20250409

Konstantin Kuzov написал(а) к Alexey Khromov в Jun 25 13:16:02 по местному времени:

Нello Alexey!

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

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

Единственные однозначные спеки по binkp - это то что было от оригинального автора:
1) https://web.archive.org/web/20190910...kp.html.koi.ru - binkp/1.0
2) https://web.archive.org/web/20190913...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. Да и вообще может сложиться впечатление что пятый аргумент в MFILE - это расширение самого binkp/1.1, но это не так. В 1.1 для MFILE добавилось лишь смещение равное -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]#