Първото нещо, което трябва да кажем е, че сме много щастливи от това как ReplicationNet се справи. Беше малко хазартно изхвърляне на толкова много възли - нашата най-голяма тестова мрежа досега с известна разлика - и очаквахме някои големи колебания, но издържа всичко, което можахме да хвърлим срещу нея бързо и без оплаквания, докато пълните възли спряха да работят. Най-обнадеждаващо от всичко, тази стабилност беше въпреки някои грешки в съобщенията около репликацията на данни, които можеше да се очакват да я свалят. Вместо това ги разби на прах. Сърдечни благодарности още веднъж на всички, които взеха участие 
, и специално споменаване на @shu за неговата фантастична работа по таблото 
.
ReplicationNet - констатации и действия
Така че, след като прегледахме регистрационните файлове, любезно споделените от общността, така и нашите собствени, можем да съобщим следното.
-
Бавно нарастващият проблем с паметта почти сигурно се дължи на достигане на капацитета на възлите. Не виждаме това поведение, докато определен брой възли не се запълнят (1024 парчета в този случай). След като мрежата заработи, не трябва да виждаме това, тъй като нови възли ще бъдат стимулирани да се присъединят.
-
Проблемите с недостига на памет изглежда са причинени от твърде много данни, съхранявани в кеша, когато капацитетът на възела се приближава. (И за този случай изглежда, че имаме твърде много възли на твърде малка машина). Това не е грешка сама по себе си, libp2p трябва да разпръсне този кеш и данните ще се съхраняват, когато се присъединят повече възли.
-
Идентифицирахме и смачкахме грешка, при която репликацията на данни причиняваше затваряне на връзката и следователно много изпуснати съобщения около репликацията. Това е нещо, което вероятно ще доведе до гибел и е доказателство за основната стабилност на мрежата, че има толкова малко въздействие.
-
Друга корекция на грешка беше свързана с „Изходящате грешки“.
-
Разпределението на данните между възлите е доста равномерно. Отново, страхотни новини, защото можем да използваме процентното запълнено пространство, като задействащо условие за ценообразуване на наградите, както е планирано. Проблемът с това, че някои възли не се запълват, е грешка, вероятно имаща нещо общо с това, че новите възли не се рекламират достатъчно силно в таблиците за маршрутизиране на другите възли.
-
Има няколко аномалии в регистрационните файлове, при които заявките за поставяне и съхранените показатели на парчета изглежда не съвпадат. Трябва да работим върху изясняването им.
-
За да дадем повече контрол на потребителите с по-ниска интернет скорост, добавихме възможността клиентът да задава продължителността на изчакване за заявки и отговори от мрежата . Също така увеличихме продължителността на изчакване по подразбиране от 10 на 30 секунди.
-
Сега обмисляме потоци на плащания и награди за различните сценарии: нови данни, репликиране на данни и повторно публикуване на данни (където валидни данни са били загубени по някаква причина)
Следващата тестова мрежа ще ни помогне да тестваме тези предположения и корекции, както и да потвърдим някои действия около потребителското изживяване.
Общ напредък
Сега всички очи са насочени към DBC, като @bochaco и @Anselme работят върху осигуряването на проверка на процеса на плащане за съхраняване на парчета, включително проверка на родителите на DBC дали плащането се изразходва и се гарантира, че техният хеш „причина“ съвпада с информацията за доказателство за плащане, предоставена за всяка част. Anselme поправи грешка, при която кранът и портфейлът не маркираха DBC като изразходвани. Оказа се, че това е свързано със синхронна дейност от проверяващите възли, причиняващи заключване за четене и запис, докато то трябва да бъде асинхронно.
По подобен начин @roland елиминира заключване в операциите PUT и GET, за да гарантира, че те могат да бъдат изпълнени - и заплатени - едновременно. Паралелизирането е името на играта. Той също така гарантира, че валидациите на данни се извършват независимо от това кога данните идват в даден възел, предотвратявайки известно „странично зареждане“ на данни чрез протоколи libp2p/kad (което по същество би позволило безплатни данни).
@bzee все още се занимава с вътрешностите на libp2p, като в момента настройва първоначалното свързване на партньорите за стартиране.
@Joshuef и @qi_ma основно работят върху констатациите на последната тестова мрежа и поправят, докато вървят напред.
@chriso работи усилено за актуализиране на safeup, повече за това скоро.
И @aed900 приключи с инструмент за стартиране на тестова мрежа за автоматизиране на създаването на тестови мрежи в AWS и Digital Ocean.
Продължаваме напред!
Преводи:
English 
Russian; 
German; 
Spanish; 
French
- Официален сайт на Safe Network
- Обобщено представяне на Safe Network
- Safe Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
- Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България