= Сообщение: 408 из 1927 ========================================== RU.BINKD =
От : Pavel Gulchouck 2:463/68 28 Apr 15 17:51:50
Кому : Mithgol the Webmaster 28 Apr 15 17:51:50
Тема : Документы FTSC, поддерживаемые binkd
FGHI : area://RU.BINKD?msgid=2:463/68+553fa896
На : area://RU.BINKD?msgid=2:50/88+553f879a
= Кодировка сообщения определена как: CP866 ==================================
Ответ: area://RU.BINKD?msgid=2:50/88+55433609
==============================================================================
Hi Mithgol!
28 Apr 15, Mithgol the Webmaster ==> All:
MtW> В архиве FTSC по адресу http://ftsc.org/docs/ есть следующие документы
MtW> про binkp:
MtW> fts-1026.001 Binkp/1.0 Protocol specification
MtW> fts-1027.001 Binkp/1.0 optional protocol extension CRAM
MtW> fts-1028.001 Binkp protocol extension Non-reliable Mode
MtW> fts-1029.001 Binkp optional protocol extension Dataframe
MtW> fts-1030.001 Binkp optional protocol extension CRC Checksum.
MtW> fsp-1024.000 Binkp/1.1 Protocol specification
MtW> fsp-1027.001 Binkp extensions: No Dupes mode and No Dupes
MtW> fsp-1031.001 Binkp optional protocol extension Multiple One-Way Batch Mode
MtW> frl-1006.001 Binkp - a protocol for transferring FidoNet mail over . . .
MtW> frl-1013.001 Binkp optional protocol extension Multiple Password
MtW> frl-1018.001 Binkp/1.0 optional protocol extension Multiple Batch
MtW> frl-1022.001 Binkp optional protocol extension CRC Checksum.
MtW> frl-1032.001 Binkp optional protocol extension Dataframe
MtW> Понятно, что FRL-1006.001 представляет собою некоторый черновик стандарта
MtW> и оттого его поддержка заменена поддержкою более новых версий стандарта.
MtW> То же самое, вероятно, можно сказать о FRL-1022.001 по отношению к FTS-1030.001
MtW> и о FRL-1032.001 по отношению к FTS-1029.001.
MtW> А какова степень поддержки остальных документов?
Тут история такая.
Дима Малов написал binkd, и описание протокола binkp 1.0, выложив и то, и другое в открытый доступ.
Потом он же доработал binkd, сделав возможность обработки файл-реквестов и слегка улучшив работу на ненадёжных линиях, и сделал описание binkp 1.1 и Non-reliable mode.
Примерно в это время (не знаю, до выхода спецификации binkp/1.1 или после) появился мейлер Argus, а потом его клоны (Taurus, Radius).
И binkd, и Argus продолжали развиваться. В Argus вместо binkp/1.1 появилась MultiBatch mode в рамках binkp/1.0. В binkd появился NoDupe mode. Потом появилась NTLM-авторизация, криптование, компрессия и т.д. - я не помню точно, в каком порядке в каком из мейлеров это всё появлялось.
Так сложилось, что членами FTSC оказались авторы или соавторы Argus. По сложившейся фидошной традиции, члены FTSC не описывают сложившуюся в фидо практику, не являются объективными техническими экспертами, а зачастую являются разработчиками, которые используют свою должность для продвижения своего софта. В данном случае не было исключения, и появился сначала FSP, а потом и FTS, описывающий "аргусовую" версию binkp, в результате чего оказалось, что binkd (в отличие от Аргуса) не полностью совместим со стандартами на binkp. Я считаю это нонсенсом.
Разработчики binkd не особенно переживают из-за этой ситуации. Что ж, FTS отдельно, софт отдельно - не привыкать.
Пример: автор Радиуса сделал компрессию в binkp, когда данные каждого binkp-фрейма компрессировались независимо от соседних, а один из битов длины был выделен как признак, компрессирован ли этот фрейм или нет, таким образом максимальный размер фрейма сокращался вдвое, до 4096 байт, фреймы отправлялись разного (иногда небольшого) размера, и нужно было отдельно обрабатывать ситуацию, когда фрейм в результате компрессии увеличился. На мой взгляд, это явно неудачное решение, я об этом говорил автору Радиуса, когда он только собирался его реализовывать, и в binkd появилась другая реализация - когда компрессируется поток данных (передающийся файл), и после компрессии данные разбиваются на фреймы. Признак компрессии передаётся опцией в команде FILE. Автор Радиуса в то время был в FTSC, поэтому сейчас стандарт FTS-1029 описывает тот вариант компрессии, который был реализован в Радиусе. А binkd этот стандарт не поддерживает (и, надеюсь, не будет). И напротив, binkp/1.1, который реализован уже примерно 20 лет назад, стандартом так и не стал.
FTS-1030 - защита CRC. Мне неизвестен ни один tcp-based протокол, который проверяет crc. В http, ftp, smtp, pop3, imap, telnet и т.д. никакие дополнительные контрольные суммы не проверяются. Для того и используется tcp, чтобы возложить контроль целостности на транспортный уровень. Binkd не поддерживает этот FTS.
Поддержка multibatch (аналог binkp/1.1 в рамках binkp/1.0) в binkd вроде бы есть, но я бы не поручился за её работоспособность. Этот режим в binkd толком не тестировался.
Lucky carrier,
Паша
aka gul@gul.kiev.ua
--- GoldED+/LNX 1.1.5
* Origin: printf("%s", "How can I increase performance?\n"); (2:463/68)
|
