Safe Network новини 🇧🇬 1.10.2020

Новини
1

Накратко

Ето някои от основните неща тази седмица:

  • Файловата система за Safe мрежата направи голяма стъпка напред към публично представяне, като сега беше обединена към главния клон и преминава през последния етап на тестване.
  • Преименувахме хранилището Safe Client Libs / контейнера safe_core на sn_client.
  • Поставихме основите за тестване на хаоса в sn_node.
  • Благодарности към @Scorch за 2 асинхронни приноса в sn_node, PR1105 и PR1090, през последната седмица. :clap:
  • Система за непрекъсната доставка вече е въведена почти на всички наши Rust контейнери, което означава по-чести версии за вас!

4
4830×430 498 KB

CRDT

sn_fs

Тази седмица беше повдигната и обединена заявка за изтегляне, за да се добави прототипът на локалната файлова система в новото хранилище sn_fs. След като останалата част от екипа има време планираме да направим хранилището публично, така че членовете на общността, работещи под Linux, да могат да го изпробват, като се има предвид, че това е само доказателство за концепцията. Очакваме да представим подробностите следващата седмица.

Safe Клиент (досега наричан Safe Клиентски библиотеки/safe_core) Възли и qp2p

Safe Network Трансфери План на проекта
Safe Клиент План на проекта
Safe Network Възли План на проекта

Още една промяна на име контейнер и хранилище тази седмица - Safe Клиентски библиотеки вече е преименуван на sn_client. Тези „библиотеки“ преминаха през огромна трансформация през последните месеци с масивно преструктуриране и опростяване от екипа, както е документирано в седмичните новини, и ни остава само контейнера safe_core. Преименувахме както хранилището, така и контейнера на sn_client, за да го приведем в съответствие с това, което сега представлява, и с другите преименувани хранилища и контейнери. С това задачата за преименуване вече е повече или по-малко завършена, като единствените неизпълнени действия са да се публикуват няколко от преименуваните контейнери, а именно sn_routing, sn_client и sn_node, които задържаме, докато ги счетем за достатъчно стабилни за публикуване на нова версия.

Тази седмица напредваме повече в интеграцията на възел / клиент, премахвайки грешки, докато активираме e2e тестовете един по един, за да увеличим покритието на кода. Открихме няколко проблеми в Replica Management, които ни пречеха да накараме клиентите да плащат за запис на данни. Поради това се заехме да рационализираме AT2 тестовете за трансфер, като се фокусирахме главно върху операциите за прехвърляне и премахнахме всички и всякакви несъответствия в Секцията. След като оправим това, следващите стъпки ще бъдат да обхванат операциите на слоя данни и да въведат тестване на хаоса, за да засилят цялостта навсякъде. Положихме основите на същото в PR # 1124, който въвежда нов флаг за хаос в контейнера, за да позволи тестване на хаоса. Веднъж активиран, той отчита нивото на хаоса от променливата на средата SAFE_CHAOS_LEVEL, която диктува вероятността хаосът да бъде предизвикан в мрежата чрез произволно пускане на съобщения / неизпълнение на операции.

От друга страна работихме по добавянето на някои функции към qp2p, следвайки парадигмата async / await. По време на миграцията към използване на async / await във всички наши контейнери, мигрирахме само модулите, които бяха незабавно необходими. След като приключихме видяхме добри резултати и се интегрира добре с останалите слоеве. Сега, след като вече започнахме да тестваме системата от край до край, скоро ще ни трябват функции като използване на протокола IGD и ехо услуга за автоматично пренасочване на портове, което е важен компонент при стартиране на тестови мрежи. Тези функции са внедрени и тяхната интеграция в момента се тества с останалите слоеве.

Благодарности към @Scorch за PR1105, което не само оптимизира, но и кара модула за съхранение на парчета да следва асинхронната парадигма в sn_node. Освен това @Scorch също има PR, обединен през тази седмица, който прави заявения файл I / O async :clap:

Винаги е много мотивиращо за екипа, когато видим подобен принос и осъзнаем колко много означава този проект за всички нас :muscle:

Маршрутизиране

План на проекта

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

Наред с горното, продължава и работата по опростяване на кодовата база чрез пълното премахване на id.rs файла и въведем подръжкавъв възлите на Keypair и SocketAddr за възлите. Първият етап от това беше да се отървем от чертите на id в контейнера bls_dkg - това вече е обединено. Частта за маршрутизация на това преструктуриране продължава, като PR се очаква да бъде повдигнат скоро.

Усилията за преминаване към CRDT продължиха успоредно с всичко това, достигайки състояние, в което имаме много основно и изолирано изпълнение на концепцията. В тази първа стъпка се опитваме да проверим дали такова изпълнение може успешно да работи като контейнер за възел, за да съхранява цялата информация, която поддържа в синхрон с други възли в своята Секция, напр. списък на Възрастни и Старейшини, където тези операции за синхронизиране се третират като CRDT операции, поради което възлите не трябва да се притесняват от реда, в който са получени, тъй като всички те се сближават в едно и също състояние. Сега работим, за да създадем добър набор от тестове, които могат да докажат, че този подход е солиден, преди да започнем да се опитваме да го интегрираме в sn_routing.

Непрекъсната доставка

Още в края на юли внедрихме система за непрекъсната доставка (CD) в един от нашите Rust хранилища за първи път. След първоначалната настройка се убедихме, че системата е стабилна и носи голяма полза за проекта. Тази седмица завършихме разпространението на CD за всички, освен за едно от нашите Rust хранилища :tada:

Чудите се какво означава този процес на CD системата? Когато всяка заявка за изтегляне се обедини, за да се управлява в хранилище с активиран CD, нашата автоматизация на CD системата се включва. CD генерира дневник за промени, съдържащ всички валидни актуализации, добавени от последното издание, установява до коя версия трябва да се актуализира контейнера , и генерира PR актуализация до тази версия. Тя автоматично обединява този PR и създава съответстващ GitHub таг и издание на нова версия. И накрая, самия контейнер се публикува в crates.io. Всичко това автоматизирано, без да е необходима човешка намеса. Това означава, че ще започнете да виждате много по-чести издания, доближавайки този цикъл на обратна връзка с общността, доколкото е възможно.

sn_api е единственото изключение засега поради усложнението на множество контейнери в работното пространство, ще се върнем към него по късно.

Имайте предвид, че не сме обединили PR на CD системата за sn_routing, [ sn_client](https://github.com/maidsafe/ sn_client / pull / 1268) и sn_node все още, като ги задържаме, докато тези хранилища, които в момента са в период на промяна, се считат за стабилни и могат да започнат автоматизирани издания.

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