Билд 9b7c22414bc9190b286aaad72103a6099196236b -
- Исправлена проблема с многопоточной записью в storage
- Добавлена команда проверки целостности hbs2 fsck
- Добавлена команда удаления блока hbs2 del

При обнаружении невалидных блоков рекомендуется 1) удалить блок hbs2 del 2) перезалить блок или сделать hbs2-peer fetch хэш-блока

Настоятельно рекомендуется обновиться ☝️.

#hbs2 C одной стороны, подмывает сделать вебсокеты и просто пустить протокол через них. Вроде бы архитектура позволяет поднять n протоколов на разных портах, надо просто сделать транспорт, простой, как мотыга. Они будут неплохо протыкать не особо пронырливые файрволлы, но только до ноды с белым IP. конфигурация

серый ip|NAT| <— >| NAT|серый ip

в них особо не заработает. Но, будем честны, она и так так себе работает. Для ws надо будет добавить протокол скачивания блоков целиком, так как качать по чанку такое себе. с другой стороны, можно и не добавлять, а просто положить размер чанка = размер блока, или половину размера блока. С третьей строны, вебсокеты могут заработать настолько приемлемо, что потеряется мотивация допиливать UDP, а я очень за UDP в сетях с избыточными данными. Но да, понятно, почему все попытки работать через него обламываются на перекачке больших данных, хотя сигнализация на нём работает прям хорошо

Мне бы для тестирования научиться добывать ноды не у хостеров, пускай даже вьетнамских. А что-то реалистичное, за NAT и относительно большими latency. А то через мобилу через VPN работает довольно приемлемо, надо посмотреть какие-то пограничные случаи

Организм отказывается спать более семи часов хоть ты что с ним делай. Ну только что таблетками не обдалбывал, но оно того не стоит. Но есть и хорошие новости, с пяти утра до двенадцати дня самое продуктивное время. Поэтому поводу микро-опрос: я все-таки собираюсь немного сдаться и прикрутить TCP, потому, что надо что бы это всё заработало с удалёнными локациями. В конфигурации, когда ноут через опсоса + сингапурский VPN чот блок плохо качаются, и таймауты можно крутить бесконечно. Отсюда вопрос: делать ли свой протокол поверх TCP или же взять вебсокеты. Начнём, конечно, с фрейминга. Каждый раз, когда речь заходит про TCP, говорят, уууу - там ФРЕЙМИНГ реализован (подставьте любой протокол). TCP сука гарантирует порядок пакетов и их доставку. Что бы ФРЕЕЙМИНГ реализовать, надо перед блобом подпихнуть чиселко. А что бы не думать, в каком оно формате - можно либо слать cborn-ные пакеты (Размер, Пейлоад), либо число в текстовом виде, как в HTTP/chunked. Плюсы голого TCP+CBOR (уууу, фрейминг!) — меньше движущихся деталей, не надо будет http сервер поднимать с вебсокетами. Плюсы вебсокетов — это HTTP соединение, зачастую корпоративные файрволлы только его и пропускают. Что бы, кстати, пропускали - придётся всё равно на каких-то известных портах поднимать публичные ноды, что, впрочем, возможно. Минусы HTTP кроме большего количества деталей — это дополнительный оверхед по данным. Я вообще, планировал быть модным и актуальным, прицепить QUIC. Но вот гемор с ним огромен, а профит не так, что бы очень. Вездепролазность, наверное, важнее, чем лишних оверхед по TCP и даже HTTP. Что же лучше сделать: голый TCP? HTTP(WS) ? TCP c мимикрией под HTTP (слать рандомные HTTP хедеры в преамбуле, что бы конфузить прокси и DPI). Вообще, с TCP есть какая-то ирония: вот был протокол, ориентированный на датаграммы (UDP) - но без гарантий. Теперь мы по сути поверх него делаем протокол с гарантиями, но при этом теряем, почему-то тот самый фрейминг (абстрация - труба, сколько читать для одной датаграммы - непонятно) и надо его теперь явно делать (ууу, фрейминг) что бы вернуть себе возможность слать датаграммы. Хорошо, что это несложно

Рассмотрим другие плюсы и минусы TCP vs HTTP(WS) кроме у!фрейминга. с WS не надо будет самому реализовывать дисциплину работы с сокетами — это всё сделано уже за нас. Надо будет только понимать, что пир отгнил и повторно соединяться или выводить диагностику. Это огромный плюс, кроме того, зачем мимикрировать под HTTP, если HTTP сам под себя мимикрирует бесплатно. Далее, теоретически имея WS можно ноду прям в браузере запустить, примеры такого известны. Общий минус TCP: нам в принципе между двумя пирами нужна одна труба, а в TCP у нас получится две, если ничего не делать - от хоста A к хосту B и от хоста B к хосту A. В принципе это наверное, ничего страшнго и может, можно так и оставить.

Итак, текущий статус: гит в общем-то работает распределенно. Поскольку до этого был написан еще и багтрекер, который работает в гите - то нахаляву получили и распределенный багтрекер. Есть определенные проблемы с работой по UDP в каналах с большим латенси —- можно выкрутить таймауты, но при этом могут быть проблемы на быстрых сетях. Кроме того, протокол показывает приемлемую скорость работы на хороших сетях (низкие задержки), но по необъяснимой мне причине очень медленно передаёт данные в условиях больших задержек. В общем, в тесте "москва-мегафон-сидней-москва" потерпел унижение от magic-wormhole, который на порядок быстрее качал файлы, хотя в начале чот-там тупил и сетапил. То есть с одной стороны можно было бы сказать, что вроде бы в UDP мы делаем всё тоже самое, что делается в TCP только шлём меньше ACK-ов, но типа в TCP этим всем занимается ядро, а тут мы его дергаем сисколлами. Да, но. Тогда бы оно еще больше тормозило бы как раз на низких задержках. Отсюда у нас как раз развилка — или разобраться, что за чухня с UDP на больших задержках и допинать, или же плюнуть и сделать просто TCP. Поразмыслив над вопросом из предыдущего поста, пришёл к вывыводу, что особых профитов от WS не будет, а лишняя сложность - как раз будет. Так что можно его с задачей корпоративной пенетрации отложить, или же для туннелирования по WS использовать просто отдельную проксю, а пока сделать что попроще. В TCP, конечно же, всегда отталкивал менеджмент соединений и всё из него вытекающее — по сравнению с единственным UDP-шным сокетом очень неизящно. Но неспроста торренты прошли эту эволюцию, в итоге забив на UDP, вот и остальные на раёне (syncthing, magic-wormhole) используют TCP. Придётся всю эту шляпу с соединениями вкорячивать.

Один из законов IT: чем больше работы сделано, тем больше осталось. Не так страшны первые 90% процентов проекта, как его вторые 90%. А сделано руками 8K loc на х-ле, и вот сейчас TCP еще где-то на строк на 800 потянет и дня на четыре-пять работы, еще и с рефакторингом. Опять же, надо потенциально зерокопи рассматривать в дальнейшем...

Вообще у меня ощущение, что UDP тупо как-то тупо давят, режут ему битрейт. Иначе эти странности - работает, но медленно - я объяснить не могу. Потери пакетов я не вижу. Идут, но сука медленно, как будто между подряд идущими UDP пакетами просто образуются большие промежутки. WTF. Тупо взять тот же хецнер - если посмотреть на загрузку сети при прокачке на UDP - там ровная полоса, которая обрезается поверху в районе 2-3 мегабайт в секунду, при этом загрузка CPU в районе 0% и не похоже, что бы в диск упиралось.

Вообще, возникает идея для congestion control взять важные параметры - а эх там всего-то штуки три-четыре. Прогнать N тестов на разных конфигурациях. Померять на каждой конфигурации throughput. Обучить дерево - что бы для разных входных параметров (rtt, еще что-то) - выдавало параметры CC, ну или там аппроксимировало бы там как-то. Сгенерить блоб. Параметры CC брать запросом к этому блобу. Блоб регулярно переобучивать и выкладывать в ту же сеть, шоб ноды скачивали и параметры алгоритма аплейтили (зачеркнуто: защить диплом). На кандидатскую потянет? Типа олгоритм конжешн контрола на основе дип лёрнинга. Хотя кто-нибудь уже защитил, конечно же. А может и запатентовал

Каким-то образом magic-wormhole унижает и scp тоже. То есть он не просто копирует между двумя хостами через свой релей, но каким-то образом делает это лучше, чем просто копирование файла с хоста на хост. Достойный соперник, одним словом

Квикфикс бага hbs2-git:

commit 343bfd607017f11ea48a752e19b7c0f51bc9c237 (HEAD -> master, hbs2/master)
Author: Dmitry Zuikov <dzuikov@gmail.com>
Date:   Sun Apr 2 09:50:02 2023 +0300

    hbs2-git db bugfix

рекомендуется обновиться

Экспортируем репо побольше. Работает медленновато, но это надо один раз. Можно ускорить

Над какими-то вещами редко задумываешься. Или там абстрактно знаешь, но не прочувствовал.
Например, почему вайфай шляпа:

[notice] peer 5.227.202.xxx:7351 burst: 2 burst-max:  errors: 0 down: 0 rtt: 210.00ms
[notice] peer 95.216.187.xxx:7351 burst: 2 burst-max:  errors: 0 down: 0 rtt: 19.00ms -- провод, Хельсинки
[notice] peer 213.141.129.xxx:7352 burst: 2 burst-max:  errors: 0 down: 0 rtt: 9.00ms -- где-то в Москве, провод
[notice] peer 192.168.1.49:7353 burst: 2 burst-max:  errors: 0 down: 0 rtt: 111.00ms -- вайфай, три метра от роутера

Гримасы распределённых систем: постишь транзакцию через свою ноду. Забываешь её сохранить. Твой кластер синхронизируется и ты получаешь транзу от других, стейт сходится, не замечаешь разницы. Другая сторонняя нода постит ссылку со своим ключом, транза не сохраняется, связь с той нодой пропадает, на собственную рассылку она не подписана. В итоге на ноде - источнике транзакций, ключ подписи которых есть только у неё — имеет меньше транзакций, чем все остальные ноды. А ты смотришь на это всё и сходишь с ума

Думаю, что немногие заказные проекты, что остались - перетащим в hbs2 тоже в течение месяца. Хрен с ним, что нет шифрования, хотя по факту оно есть, надо только прикрутить и дисциплину ключей продумать. Если не класть туда секреты, то и шифровать особо незачем, всё одно в Роспатент поедет.

К fixme вполне можно прикрутить фронт, а к всему вместе - (статическую?) вебморду для гражданских. И принципиально сделать её стейтлесс - т.е вся авторизация только приватным ключом на клиенте, каждая транза на апдейт им подписывается, то, что зашифровано - им расшифровывается. думаю, в течение нескольких месяцев такое можно.

Получится своего рода продукт - среда разработки для команды + фронт для гражданских (заказчиков), без какого-либо стейта на сервере, расшифровка блоков перед отображением в js на клиенте. Вполне себе конь-цепт

#haskell А не может внезапно выясниться, что

TVar [x]

- работает не хуже STM-ной очереди, при этом можно с ней хоть рингбуфер делать, хоть что. Или не выяснится ли там, что STM-ные очереди - это TVar + очереди Окасаки? неохота смотреть, кто-то разбирался?

Муахаха

Что-то от TCP мгновенного счасться не произошло. Когда работает UDP - он работает чуть лучше даже с самодельным congestion control, а когда не работает UDP - то и TCP тоже почему-то не работает. Что-то я надеялся, что подменю транспорт и сразу в дамки, но нет. Предвижу пару недель увлекательной отладки.

А подскажите кто-нибудь хостинг с локациями в ЮВА / Австралии? И желательно, что бы криптой можно было платить или еще как-то нормально, евпочя.

TCP+UDP, Сидней