Safe Network новини 🇧🇬 19.8.2021

Тази седмица беше трудна в много отношения след тъжните новини от миналата седмица. Понякога не осъзнаваме колко близки сме всички по толкова различни начини, но всички искаме едно и също - по-добър свят. Хората се справят с новини като тази по различни начини. Отношението на екипа ни е да се съсредоточим върху работата доколкото можем и да се насочим към следващата тестова мрежа.

Неотдавнашните дискусии във форума демонстрираха силен интерес за това как ще работи икономиката на Safe мрежата. Неизбежно моделът се промени малко с приемането на DBC като средство за обмен. За да дадем на всички по-добър шанс да следят напредъка, скоро ще стартираме серия публикации, която ще започне с разглеждане на текущите промени в инфраструктурата на токените.

Междувременно…

Общ напредък

@lionel.faber и @chris.connelly имаха продуктивни разговори с екипа на quinn относно времето за изчакване и обработката на грешки. QUIC peer-to-peer (qp2p) използва библиотеката quinn за свързване на клиенти към мрежата и някои от проблемите с връзката, които видяхме, се дължат на начина, по който двете системи взаимодействат. Екипът на quinn е отзивчив на заявките ни и имаме напредък. В същото време опростяваме qp2p, като премахваме част от поведението при кеширане, което вече не ни е необходимо.

@yogesh проследява проблемите във времето за изчакване и грешките от изпускането на съобщения при клиента за маршрутизиране, където липсата на цикли на процесора изглежда влияе на потоците от връзки на qp2p, което в крайна сметка води до отпадане на съобщения, като по този начин влияе на потоците. Това, заедно с грешките на анти-ентропията (AE), са основните проблеми, които задържат следващата тестова мрежа. Анти-ентропията вече се прилага почти за всички съобщения, които променят данните, но все още има неща за оправяне. След като клиентът внедри AE парадигмата, SectionInfoMsgs стават излишни и се превръщат само в ненужно натоварване за процеса на зареждане, поради което сега също се премахват, като AE поема отговорността да поддържа Клиента актуален с мрежовата инфраструктура.

При опростяване на съобщенията @anselme премести PrefixMap, структура, която съответства на префиксите на секциите, от функционалността на възела към общ тип.

Освен това постигнахме опростяване и в контейнера за самокриптиране. @oetyng се справи с него, като го накара да обработва не повече от необходимото, както и (споменахме го миналата седмица) разпределяне на работата върху всички налични ядра. 459 % подобрение в скоростта на писане вече се увеличи до 1478 % по-бързо. (Отново, това са резултати измерени на 6-ядрена машина. Колкото повече ядра, толкова по-високо е процентното подобрение.) Четенията са “само” 290 % по-бързи.

Освен това работими върху по-голям клон от функции, както някои хора във форума забелязаха, като правим още една стъпка към сливането на „node“ и „routing“ папките в „safe_network“ хранилището. Това помогна за увеличаване на паралелността и допълнително опростихме маршрутизирането с промените в „AntiEntropy“.

Намалихме използването на паметта (което отново се увеличи след преструктурирането и AE), като премахнахме някои повтарящи се съобщения (намаляваме до използването на най-много няколко стотин mb памет по време на тежки тестове). И сега разглеждаме как можем да намалим и използването на процесора!

Всичко това върви добре, въпреки че все още не сме постигнали целта си да стабилизираме CI (което изисква ~ 40 възли, мрежа от две секции, преминаващи всички клиентски тестове на CI). Така че продължаваме да обединяваме корекции и отстраняваме грешки в този клон, преди да го обединим с основния.

Преводи:

:uk: English :ru: Russian ; :de: German ; :es: Spanish ; :fr: French


  • Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
  • Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
  • Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България