Рассмотрим другие плюсы и минусы 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, Сидней

Вчера катнул tcp в "прод". Ради понта даже сделал обратную совместимость по протоколам, чисто, что бы отработать концепт. Как и предполагалось, cborg/serialise ADT-шные конструкторы скорее всего добавляет, как кортежи, где числом - номер конструктора. Таким образом, в ADT-шные типы можно в конец добавлять конструкторы, и более старые версии не сломаются. PEX для TCP получается более хитрый, надо сначала выяснить, что пир в принципе поддерживает TCP, потом попытаться открыть к нему клиентское соединение, в случае успеха - добавлять в PEX, которым делиться с миром. В процессе. На следующей неделе доделаю. Походу мучений с TCP - как всегда, всё упёрлось в off-by-one ошибку где-то в глубинах - перепилил и UDP, теперь таймауты не хардкоды, а пропорциональны измеряемому RTT + если один поток скачивания заткнулся в таймауте - другой не ждёт и стартует раньше. Качать начало люто, что через Австралию, что напрямую. UDP ведёт себя как ему положено - на хорошей связи уделывает TCP, на плохой - начинает мигать битрейтом - т.е ждать каких-то потерянных пакетов до таймаута. В любом случае, в итоге увидел цифры доселе невиданные - до 80 мегабайт в секунду, и наконец-то стало упираться в CPU, вероятно, пересчёт хэшей, как положено. В целом, доволен. Так победим

Большое количество мелких файлов - реально, источник проблем. Хотелось каждому блобу в гите сопоставить объект в системе и на метаинформацию тоже файл. Но что-то их становится овердофига, и они медленно качаются, как бы быстро не пытался. Ну и вообще видно, что это будуший источник проблем. Надо что-то переосмысливать, пока оно несильно распространилось

в гите есть фича fast-import/fast-export - это дамп в текстовом формате всего репо. если репо испортировать/экспортировать через это, то будет быстро с одной стороны, но не будет дедупликации

В общем, есть два стула. Скорость или дедупликация. Надо выбрать.

А ведь мошенники уже, наверное, ставят на поток обучение нейронок, которые будут разводить людей на деньги. В массовых масштабах. Потому, что развод людей на деньги по скрипту - это идеальная задача для таких нейронок, и с автоматизацией её можно прям массово запускать. Приделать ручки для звонков/чатов и т.п. Прямо завод по производству денег и прямая монетизация этих нейронок. Инвест-план простой и прямой, как палка. Опять же, спасибо виталику, продавшему свой планктон американским регуляторам, GPU для майнинга больше не нужны, а вот для обучения нейронок - могут и пригодиться. Как всегда, до меня доходит, как до жирафа, кто надо уже полтора года назад, поди, всё поняли