Бага в 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

Oleg Nazaroff написал(а) к Nil A в Aug 24 09:04:48 по местному времени:

Нello, Nil A.
On 08.08.2024 07:45 you wrote:

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

А я на jNode наблюдал такую же шнягу. Только жнодовская дуполовка их тут же и пристреливает благополучно. Но генерятся они исправно.


--
WBR, ON
--- ХотДог/2.14.5/Android

Nil A написал(а) к Oleg Nazaroff в Aug 24 09:18:54 по местному времени:

Нello, Oleg!

Thursday August 08 2024 09:04, from Oleg Nazaroff -> Nil A:

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

ON> А я на jNode наблюдал такую же шнягу. Только жнодовская дуполовка их
ON> тут же и пристреливает благополучно. Но генерятся они исправно.

Стрёмно, что транспорт бандлов может гарантировать только "at least once", но не "exactly once". Я тут сейчас терминологией MQTT протокола говорю, там там есть QoS 3х вариантов:

1. At most once - послал и забыл
2. At least once - то, что бинкп протокол обеспечивает
3. Exactly once - вот вам приходили когда-нибудь дупы емейлов, или может сообщений в телеграмме, воцапе, ещё чём-то?

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

Oleg Nazaroff написал(а) к Nil A в Aug 24 09:50:16 по местному времени:

Нello, Nil A.
On 08.08.2024 09:18 you wrote:

NA> Стрёмно, что транспорт бандлов может гарантировать только "at least once", но не "exactly
NA> once". Я тут сейчас терминологией MQTT протокола говорю, там там есть QoS 3х вариантов: 1. At
NA> most once - послал и забыл 2. At least once - то, что бинкп протокол обеспечивает 3. Exactly
NA> once - вот вам приходили когда-нибудь дупы емейлов, или может сообщений в телеграмме, воцапе,
NA> ещё чём-то?

Скажи спасибо что не 1-й вариант ;))

--
WBR, ON
--- ХотДог/2.14.5/Android