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

Читать полностью…

Итак, текущий статус: гит в общем-то работает распределенно. Поскольку до этого был написан еще и багтрекер, который работает в гите - то нахаляву получили и распределенный багтрекер. Есть определенные проблемы с работой по 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 потянет и дня на четыре-пять работы, еще и с рефакторингом. Опять же, надо потенциально зерокопи рассматривать в дальнейшем...

Читать полностью…

Организм отказывается спать более семи часов хоть ты что с ним делай. Ну только что таблетками не обдалбывал, но оно того не стоит. Но есть и хорошие новости, с пяти утра до двенадцати дня самое продуктивное время. Поэтому поводу микро-опрос: я все-таки собираюсь немного сдаться и прикрутить 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) - но без гарантий. Теперь мы по сути поверх него делаем протокол с гарантиями, но при этом теряем, почему-то тот самый фрейминг (абстрация - труба, сколько читать для одной датаграммы - непонятно) и надо его теперь явно делать (ууу, фрейминг) что бы вернуть себе возможность слать датаграммы. Хорошо, что это несложно

Читать полностью…

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

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

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

Читать полностью…

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

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

Читать полностью…

Pull Request без гитхаба. Начало

Читать полностью…

Жутко неудобно, что для подписи и шифрования используются разные типы алгоритмов и разные ключи

Читать полностью…

hbs2

hbs2://2YNGdnDBnciF1Kgmx1EZTjKUp1h5pvYAjrHoApbArpeX

fixme

hbs2://D6xVrGwrjATM8u5v1NEbra2aneWaggPqbgbWj9MHXFqA

suckless-conf

hbs2://9z7wMp4YbF1DwP1ao5TUrm3QNTmqneEq5C9uvy75PjR8

#fixme #hbs2 #suckless-conf

Читать полностью…

git это первый широко известный среди меня CAS, хотя, кажется, до гита мы использовали bzr, но я не помню, был уже гит на тот момент или нет. интересно, кто до dvcs применял CAS-ы и есть ли по этому поводу какие-то пейперы. У них же очень прикольные свойства, интересно бы их знать все, а не обнаруживать в процессе работы

Читать полностью…

По поводу забора блоков по http. Их забор можно делать в общей очереди, тогда те ноды, которые поддерживают http будут по нему и отвечать (короткими блоками) и блоки эти будут запрашиваться у рандомных пиров. Это, типа, true. Сделать отдачу всей портянки одним вызовом - лехко, такая команда в cli уже есть - hbs2 cat хэш парсит объекты и отдаёт поток данных целиком. Но. Это ж нарушение децентрализации и способ абьюзить конкретного пира. Что же делать?

Читать полностью…

README добавил
https://github.com/voidlizard/hbs2/blob/master/README.md

Читать полностью…

фиг знает, стоит ли это постить сюда, но а куда еще, с другой стороны

Читать полностью…

#hbs2 @offgrid Удалось, кстати, это всё запустить на raspberri pi, что странно для хаскеля с TemplateHaskell. Видимо ноука шагнула за пять лет далеко вперёд. Неожиданно

Читать полностью…

Короче, для гита и случая, когда нода hbs2 в онлайне - всё работает с довольно общим механизмом. Теперь надо решить для случая, когда нода была в офлайне / стартует в начальный момент времени и ничего не знает про ссылку. Самое простое - попросить соседей переслать то, что у них есть. Конкретно это означает, что 1) рассылаем всем нодам запрос "проиграй свой лог транзакций 2) они плюют в ответ все транзы, которые у них есть - если есть сто, то сто. Если тысяча, то тысячу (UDP пакетов), если сто тысяч - то сто тысяч. Ну чот такое себе. Что же делать

Читать полностью…

Со ссылками не очень прикольная ситуация. Ссылка - это некая глобальная идентифицированная мутабельная переменная в распределенной системе, состояние которой определяется неким консенсусом. Ну, например, простой тип консенсуса - когда писатель только один и у ссылки есть версия. Тогда все участники сети просто сохраняют последнюю известную им версию ссылки и её же отдают, когда их попросят. Это один самый частный случай. В идеале, поскольку система просто представляет собой сетевой уровень, хочется, что бы состояние ссылки и тип консенсуса определялся внешним приложением. Для этого состояние ссылки надо просто пропихивать туда (во внешнее приложение), как есть. Если мы просто в онлайне просто слушаем и пересылаем эти самые ссылки, вернее, транзации об изменении их состояния - то всё просто работает — ссылку получили, пруфы (подпись, например) проверили, если ок - переслали. Вопрос, что делать если pull модель - т.е кто-то к нам приходит и говорит - дай лог для ссылки. Во первых, если ссылка нам не принадлежит - мы лог не можем подписать той же подписью — можем только переслать его как есть, т.е лог будет не содержимого транзакций, а самих (подписанных) транзакций. Неудобно, но, допустим, ок. Во вторых - лог может быть дюже здоровенный, а как-то фильтровать мы его не можем, мы же не знаем, что там внутри в транзах. Допустим, сделать запрос "дай N последних транз" - а что такое "последних" ? Последних принятных в хронологическом порядке? Последних N принятых в хронологическом порядке, упорядоченных по хэшам? Понятно, что можно сделать как-то. Но хочется сделать как-то логично и минимально, что бы несколько каких-то рандомных частных случаев на уровень протокола

Читать полностью…

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

Читать полностью…

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

Читать полностью…

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

Читать полностью…

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

Читать полностью…

По текущим вопросам по hbs2 - как ставить, конфиги, новые релизы и тп - группа /channel/+3kNcHQ0p68dlZmYy

Читать полностью…

Удивительное рядом - Bitkeeper всё еще жив. И поскольку он якобы больше подходит для больших проектов и "ориентирован на корпоративный сектор" - возможно, в него можно и монорепу засунуть. Вот это поворот!

Читать полностью…

Не погорячился ли я, положив, что один репозиторий = одна ссылка = одна ключевая пара? С одной стороны, это минимальное количество возможных сущностей (один репо = один ключ). С другой стороны все ключи получаются секретные и их надо менеджить. Когда их станет сто штук, такое себе будет. С третьей стороны, вроде можно, имея специального вида ключ ed25519 замутить сколько угодно произвольных ключей, как в биткойне (надо проверить). С третьей стороны, ну а сколько их надо? Кейринг сейчас это файл в котором 1 ключевая пара подписи - это идентити, и n ключей шифрования. показалось логичным сделать именно так. но по факту ничего не мешает сделать кейринги, в которые напихать 100500 ключей, тогда 100500 сущностей будут управляться одним кейрингом.

Читать полностью…

#fixme обновил fixme. теперь он учитывает все версии файла-лога транзакций. со всех веток со всех версий. Поэтому первый раз будет работать долго. но теперь, даже если кто-то меняет статус fixme на отдельной ветке - то все, кто эту ветку видят - видят обновление статуса. Теперь так же .fixme/log можно обнулять и писать в него только свои локальные изменения. Это не повлияет на историю, т.к. учитываются все его версии со всех известных веток. Порядок обновлений вычисляется из порядка коммитов по времени. В том порядке, в котором гит выводит. Ну то есть если вы поставили часы в прошлое и закоммитили - да, история испортится, вероятно. Но на то и гит. Можно выяснить, кто это сделал и принять меры

Читать полностью…

#fixme Сейчас в fixme собирает записи по всем известным объектам репозитория, а вот лог состояния берётся просто из файла. Раз появляется файл, то он может начинать меняться по бранчам, его надо мержить, периодически он ломается, у всех может быть разным. Короче, при большом количестве бранчей это будет неудобно, уже начало. Хотя и работает. Так вот. Его можно брать не из файла. Его можно брать из множества блобов для этого файла, упорядочивать по 1) id самого fixme 2) дате коммита - у нас получается линейная история для каждого fixme это раз, её можно хранить в merkle tree и не обрабататывать дважды это два 3) история становится глобальной это три и это удобно — теперь на каком бы ты бранче не поменял статус - у тебя и у всех, кто твой бранч стянул будет одинаковое состояние, и не надо никаких ограничений на формат накладывать - я хотел сделать fixme/log связным списком состояний, но пожалуй, это так себе была идея, можно лучше. Остаётся сам файл .fixme/log , конечно. Его хоть и можно обнулять время от времени, всё равно это будут забывать и будут писать туда разное, отчего в итоге будут мерж конфликты. Надо еще немного подумать, что с этим сделать. А кроме того, можно задействовать hbs2-core для меркл-деревьев, написать бэкенд для записи этих деревьев в sqlite и посмотреть, что из этого выйдет -- тут не критичное применение, больших блобов не будет, базу сильно не раздует

Читать полностью…

nix profile install github:voidlizard/hbs2/master

Читать полностью…

Не бывает такого, что бы какой-то кусок софта взлетел. Он всегда всполз. Но тем не менее. Перед текущей фазой разработки от протоколов была откручена криптография. Соответственно, хочется понять, как бы её туда грамотно вкрутить обратно. Поскольку система не привязана ни к каким "доменам", сертификаты тоже отпадают. Пиры общаются между собой, подтверждают владение своими публичными ключами (подписи) и на этом этапе можно согласовать ключи шифрования и весь дальнейший обмен шифровать. Блоки еще сами по себе могут шифроваться, это сейчас есть. Вопрос вот в чем — незашифрованный протокол обмена ключами не палево ли это. Что можно делать: 1) запоминать где-то ключ пира и дальше использовать его 2) забить и оставить протокол согласования ключей незашифрованным. Запоминать ключи пира это в принципе появляется какой-то стейт, который надо обрабатывать, там будет что-то теряться, что-то пртухать и т.п. Неизящно. Какой можно изящный ход придумать?

Читать полностью…

push в пустую (новую) ссылку

Читать полностью…

Как работает git clone hbs2://...

Читать полностью…

Конкретно для гита с одним писателем - стейт это просто транзация с максимальным номером и ссылкой на merkle дерево состояния (head репозитория [состояние всех бранчей + транзитивное замыкание коммитов]). Вопрос в том, что для разных приложений понимание стейта может быть разным, вопрос какие примитивы должны быть в самой системе

Читать полностью…

code review с fixme:
делай раз:

cat .fixme/config
...
fixme-prefix     REVIEW:    review
...

делай два

cat .fixme/config
...
[ fixme-report review json
  (render builtin:microstache report-wip.tpl)
  (post builtin:columns | 10 10 8 12 _)
  (query tag:REVIEW:)
]
...

делай три

  -- REVIEW: no-time-to-die
    просто удаляй пира из вайтлиста,
    если он в блэклисте

  unless (Set.disjoint blkeys wlkeys) do
    die "whitelist and blacklist intersect"

делай четыре:

[dmz@expert:~/w/hbs2]$ fixme report review
Da2nChoaL9 []         REVIEW:               no-time-to-die

Читать полностью…