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

    From Nil A@2:5015/46 to Vitaliy Aksyonov on Thu Aug 8 07:45:20 2024
    * Originally in pvt.luna.local
    * Crossposted in ru.ftn.develop
    Hello, Vitaliy!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    RTFM.

    Best Regards, Nil
    --- GoldED+/LNX 1.1.5-b20240306
    * Origin: FidoNet member since 1995 (2:5015/46)
  • From Oleg Nazaroff@2:50/700.700 to Nil A on Thu Aug 8 09:04:48 2024
    Hello, Nil A.
    On 08.08.2024 07:45 you wrote:

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

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


    --
    WBR, ON
    --- ХотДог/2.14.5/Android
    * Origin: Somewhere at Russia, in the hut on chicken legs... (2:50/700.700)
  • From Nil A@2:5015/46 to Oleg Nazaroff on Thu Aug 8 09:18:54 2024
    Hello, Oleg!

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

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

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

    Стрёмно, что транспорт бандлов может гарантировать только "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
    * Origin: FidoNet member since 1995 (2:5015/46)
  • From Oleg Nazaroff@2:50/700.700 to Nil A on Thu Aug 8 09:50:16 2024
    Hello, Nil A.
    On 08.08.2024 09:18 you wrote:

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

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

    --
    WBR, ON
    --- ХотДог/2.14.5/Android
    * Origin: Somewhere at Russia, in the hut on chicken legs... (2:50/700.700)