Бага в binkp протоколе - ДУПЫ (не Котярские)

Nil A написал(а) к Vitaliy Aksyonov в Aug 24 07:45:20 по местному времени:

* Originally in pvt.luna.local
* Crossposted in ru.ftn.develop
Нello, Vitaliy!

Wednesday August 07 2024 22:19, from Vitaliy Aksyonov -> Nil A:

NA>> Кстати, в протоколе Бинкп есть бага, в спеках. Когда приходит
NA>> подтверждение принятия файла, то передающая сторона его удаляет. Пока
NA>> всё норм? Там как-то надо двух-фазный коммит чтоли сделать, потому
NA>> что если проеб@тся сигнал на успешное принятие файла, оно снова будет
NA>> передаваться в новой сессии, а это дупы.

VA> Я наталкивался на это иногда. Крайне редко, но это выряжается как
VA> дупы.

На столько плохой у тебя коннект по IP, чтобы воспроизводился этот дефект?

Можно на какой-нибудь виртуалке воспроизвести, где указывается процент дроп пакетов.

VA> Не факт, что двусторонний коммит поможет.

На two-phase commit protocol можно между разными серверами ACID гарантировать. Не то, чтобы подтвердить на подтверждение о приятии файла.

VA> Как вариант - не обрабатывать файл, пока он не удалён на
VA> другой стороне.

Про что и баг. Как ты об этом узнаешь?

В 90х было ещё смешнее с ББСками, с upload/download ratio. Чтобы на@бывать систему, был специальный хак, когда ты по zmodem не подтверждаешь последний фрейм, а значит файл не скачал.

К сожалению, аффторы fts-1026, хоть и жили в 90х, но хернёй с zmodem уже походу не страдали.

VA> Можно держать файлы во временном каталоге, пока сессия корректно не
VA> закроется.

Так то сессия же завершается корректно, и тебе говорят, что файл принят.
Ааа.. возьмём TCP какой-нибудь, зачем нужна эта пляска в кернеле с FINWAIT? Ухты, а там ещё и FIN_WAIT2 стейт есть.

VA> Но, подозреваю, что у такого подхода есть другие недостатки.

RTFM.

Best Regards, Nil
--- GoldED+/LNX 1.1.5-b20240306