Накратко
- Продължаваме да преместваме всички дефиниции на клиентските съобщения и логиката на сериализацията към новия контейнер sn_messaging.
- Работата по премахването на управлението на „потока“ във възлите, както беше споменато в актуализацията от миналата седмица, е завършена и обединена
- Продължихме да решаваме проблемите, подчертани от новия ни инструмент за стрес тестване на маршрутизацията.
- Голямо благодаря към двама членове на общността за PR-ите тази седмица - @mav и @tfa се включиха с множество PR-и в различни хранилища, за да помогнат и подобрят нашата работа. Винаги е вдъхновяващо да получим помощ
- Все още работим по тестването и финалното отстраняване на грешки, което се надяваме да означава, че ще можем да пуснем следващата версия на тестовата мрежа скоро.
Safe клиент, възли и qp2p
Safe Network трансфери план на проекта
Safe клиент план на проекта
Safe Network възли план на проекта
През последната седмица отделихме още малко време за подобряване на qp2p примерите, така че те да демонстрират по-добре функциите на библиотеката поотделно. Заедно с това разширихме примера за ехо услугата, за да поддържаме ръчно пренасочване на портове. Докато изпълнявахме това идентифицирахме и внедрихме малко разширение, което потвърждава крайната точка, предоставена от потребителя като вход. Това ни позволява да върнем грешка много по-рано, вместо да чакаме мрежата да идентифицира и докладва възела като недостъпен.
Също така продължихме с преместването на всички дефиниции на клиентските съобщения и логиката на сериализацията към новия sn_messaging контейнер. Подобрихме протокола и сега използваме Msgpack за сериализиране на всички съобщения, изпратени от клиенти до възли. Обаче но остава още работа, тъй като някои вътрешни части на клиентските съобщения все още използват бинкод сериализация и затова трябва да ги мигрираме също да използват Msgpack.
Работата продължи с разпределените преходи на актьори при смяна на старейшина, т.е. прехвърляне на парите в секцията към нов старейшима. Малка грешка, възпрепятстваща прехода (поради неуспешна проверка на подписите) отне известно време, за да се изкорени, но току-що беше намерена. Остават да бъдат тествани следващите стъпки в прехода.
И накрая, напредваме с актуализирането на клиента / възела, за да премахнем клиентските предизвикателства и да активираме отново правилното включване на клиенти, след като работата по премахване на управлението на потока от възлите, както беше споменато в актуализацията от миналата седмица, беше завършена и обединена. Това от своя страна разкри някои потенциални проблеми при получаването или разбора на клиентски съобщения, така че се работим по тях.
API и CLI
Тази седмица успяхме да генерираме успешно „musl“ компилации за CLI и authd в нашия CI и затова всичко е настроено и готово за следващото ни издание. Това означава, че както CLI, така и authd приложенията трябва да са съвместими с която и да е Linux платформа без допълнителни настройки, ще ни е необходима помощ от общността, която да ни помогне да проверим дали това всъщност е така, като го изпробвате на толкова много различни Linux платформи колкото е възможно. Ще пуснем новите версии своевременно.
BRB: Византийско надеждно излъчване
Работата продължи и тази седмица за допълнително полиране на BRB контейнерите. Приложният програмен интерфейс (API) на DataType е променен, така че подробностите за грешка при проверка могат да бъдат върнати на повикващия. В тази връзка и rust-crdt контейнера беше подобрен, така че всеки тип CRDT, който използваме сега, има validate () метод, който може да бъде извикан преди прилагане на операция. За всеки BRB контейнер са направени заявки за изтегляне за CI / CD (Непрекъсната интеграция и Непрекъснато внедряване и доставка). Имаме още няколко промени, които трябва да завършим тази седмица, след което планираме да пуснем първото издание към crates.io.
Маршрутизиране
Миналата седмица споменахме как инструментът за стрес тест разкри някои скрити проблеми при маршрутизирането. Тази седмица се заехме да ги издирим и поправим. Един от проблемите беше, че членове на дадена секция, които не са Старейшини не разбират, че се е случило разделение на секцията поради грешка в начина на създаване на „Sync“ съобщенията. Това беше поправено и обединено. В момента работим по още един PR, който решава още няколко от тези проблеми. Останалите проблеми след това вероятно са свързани с начина, по който се справяме с промените в членството в секциите. Надяваме се да ги разрешим чрез интегриране на новия BRB алгоритъм за членство, който също беше споменат миналата седмица. Тази работа ще започне възможно най-скоро следващата седмица, ако всичко върви добре.
Подобно на скорошния ни ход за изваждане на всички дефиниции на клиентски съобщения и логика за сериализация в отделен контейнер (sn_messaging), започнахме да въвеждаме същото и за sn_routing съобщенията. Целта е да можем да разделим цялата логика на дефиницията на съобщенията и сериализацията от основната логика на маршрутизиране. Това трябва да ни позволи да имаме ясна дефиниция на интерфейса, изложен от услугите за маршрутизиране, и следователно как всяко изпълнение (на всеки език за програмиране) може да стане съвместимо със съществуващото ни sn_routing изпълнение. В най-ранните етапи на този процес сме, но искахме да споделим целта си тук.
Преводи:
Английски; 
Russian ; 
German ; 
Spanish ; 
French
- Официален сайт на Safe Network
- Обобщено представяне на Safe Network
- Safe Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
- Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България