Safe мрежата е изградена около концепцията за опростяване на градивните елементи. Отделните елементи реагират на външни стимули по ограничен и предсказуем начин, но се комбинират, за да създадат едно цяло, което е способно да изпълнява сложни задачи в непредсказуем свят и да се защитава от врагове - аналогия с мравуняк.
Но за да работи това, са необходими фини механизми за обратна връзка. Отделните мравки трябва да могат да сигнализират, че са под натиск и не могат да носят повече, в противен случай системата става крехка и колонията се срива. @oetyng работи върху система за опашка от съобщения и обратна връзка, което е начин за възли да оповестят: „О, ще изчакаш ли? Ще стигна до теб след време, но имам само шест крака, две долни челюсти и малък мозък". Кодът все още не е завършен, но тестовете вече показват впечатляващи подобрения в стабилността и производителността.
Общ напредък
Екипът на MaidSafe се запознава с проекта на законопроекта за онлайн безопасността на Обединеното кралство, който беше публикуван миналата седмица, и как той може да повлияе на бизнеса ни, както и на Safe Network като проект. Нашите опасения относно законопроекта, който винаги се е опитвал да регулира интернет около Facebook, със сигурност не се успокоиха от новия проект; дори напротив - влошиха се. Така че ние работим, за да разберем какви позиции може да се наложи да заемем и какви дискусии може да се наложи да проведем, за да помогнем на правителството да разбере, че проекти като нашия не са Facebook, нито трябва да бъдем третирани като такива. За щастие, нашият мениджър по политика и управление @Heather_Burns се занимава с този законопроект повече от три години на предишните си работни места и го разбира, не по зле от всеки друг. В момента тя е заключена в тъмно мазе с над 500 страници от законовия текст на законопроекта и сандък с Irn Bru и скоро ще ни даде обратна връзка.
При работа върху DBC потоците @danda и @davidrusu стигнаха до осъзнаването, че монетният двор, както първоначално беше проектиран, вече не е необходим, тъй като функционалността - проверка и подписване на транзакции - вече беше вградена в разходната книга. Както забелязаха някои прозорливи членове на общността (здравей @happybeing!), това означава, че цели участъци код могат да бъдат премахнати, оставяйки по-малко работа както на клиента, така и на Старейшините. Сега обсъждаме дали да направим разходната книга отделен тип данни - и може би дали да я преименуваме на “монетна” книга, за да отговаря на конвенцията.
@Chriso проучва лицензирането на кодовата база, която с времето стана непоследователна. Идеята е да се лицензира основната мрежа под GPL3 с хранилища различни от тези на Сейф, лицензирани под MIT/BDS, за да не се ограничават клиентските приложения, които могат да бъдат изградени върху тях.
@joshuef също работи за интегриране на кода за проследяване на дисфункции, който разкри няколко грешки в обработката на заявките на възела. Преди тези корекции възлите може да не са върнали валидно парче данни към клиентите, ако друг възел е отговорил по-бързо с неуспех. Те може да не са поставили в опашката партньор, ако такъв вече съществува за същата част, и може да сме изпращали повторно заявки към възлите изобщо, ако оригиналните съобщения са били изпуснати при транзита поради някаква причина. Тези няколко поправки коригират този поток и изглежда имат разумно влияние върху резултатите от теста, което е хубаво.
Обратна връзка и опашка за съобщения
Поради ограничения в процесора и паметта, възлите не могат да обработват безкраен брой заявки. Към днешна дата, когато те се сриваха под напрежението, ние просто ги убивахме, което водеше до много премествания на данни, и още повече съобщения, летящи наоколо и евентуален отказ, но обратната връзка - позволява на възел да се оплаче, преди да е достигнал точката на счупване - е начин за изглаждане на кривата.
Така възлите вече могат да се отдръпнат и да кажат: „Хей, не мога да се справя, дайте ми почивка, изпратете ми само 10 съобщения в рамките на следващата секунда“. Мрежата ще гледа проактивно какво възлите казват, че са способни да направят в даден момент от време, и няма да ги залива със съобщения, ако са под стрес. Това ще им позволи да се възстановят, след като свършат задачата си.
Намаляването на съобщенията по този начин също ни дава време да приоритизираме съобщенията, така че ако има нещо, което е с основен приоритет, то все пак ще премине, докато по-малко важните съобщения могат да изчакат.
Всеки възел вече има опашка за съобщения, която съхранява неизпратени съобщения, докато възелът се счита за активен. Ако не, тогава съобщенията се премахват.
С тази система всички възли са наясно с броя на съобщенията в секунда, които другите партньори в тяхната секция могат да получат, като се изчислява от модула back_pressure, и съобщенията са с приоритет, така че важните инфраструктурни съобщения винаги се изпращат преди по-малко важните клиентски служебни съобщения.
Това все още не е интегрирано, но при тестването ни промените дадоха някои наистина впечатляващи резултати:
Съхраняването и четенето на 5 MB от много клиенти с 50 клиенти читатели даде следното в тестовия клон:
Време: 30 сек
CPU: ~40% (много за кратко над 50%)
Mem: ~60 MB / Старейшина (много за кратко до 125 MB)
в сравнение с резултатите на публичния тест:
Време: 704 сек
CPU: 100%, през цялото време
Mem: ~2 GB / Старейшина, през цялото време
Всичко това означава по-щастливи и по-здрави мравки. 
Преводи:
English 
Russian ; 
German ; 
Spanish ; 
French
- Официален сайт на Safe Network
- Обобщено представяне на Safe Network
- Safe Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
- Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България