Тази седмица @joshuef ни носи някои новини за напредъка с комуникациите (комуникации между възли). Както търпеливите читатели ще знаят, това блокираше работата ни от известно време, но виждаме определена светлина в края на този конкретен тунел.
Общ напредък
Кратък преглед на това, което екипът прави.
@anselme разследва атака с фалшив ключ, която засяга някои други реализации на BLS и откри, че нашата също е уязвима. Той изпрати корекция към „blsttc хранилището“. Като също така разглежда грешка, която пречи на клиентите да се присъединят към мрежата при тестове.
@chriso работи върху подписването на блокове и регистри, което е мястото, където данните (или Xorname в случай на парче) се подписват от Старейшините, за да бъдат валидни в мрежата.
Във връзка с това, @bochaco прави промени в клиентския API, свързани с команди и парчета, и отстраняване на грешки, свързани с тях в CI.
Мостафа е зает с тестови случаи за нашия механизъм за консенсус, а @bzee продължава да се намесва в qp2p, където вярваме, че има дълбоко вкопан проблем, който засяга свързаността.
Напредък на комуникацията
Едно нещо, върху което работим, е да премахнем нашия код за намаляване на връзката и просто да разчитаме на основния код quinn за прекъсване на връзки след по-малко време на изчакване. По този начин правим по-малко предположения и вече не гадаем какво е отворено и кога.
При нашето тестване това имаше положително въздействие върху клиентските тестове, премахвайки вероятността връзките ни да бъдат затворени преди да си свършат работата.
Двупосочни потоци
Успоредно с това се придвижваме към рационализиране на комуникацията клиент/възел с помощта на двупосочни потоци. Това означава, че премахваме част от сложността на управлението на състоянието и просто ще чакаме отговор от Старейшините. Преди (преди много време в земята на възлите) използвахме този вид потоци за комуникация с клиенти, но управлението на потока от отговори беше сложен кошмар. Но сега възелът е много по-опростен (поради работата, извършена през последната година и половина или повече) и това е много по-управляемо.
Намалени повторни опити
Също така търсихме да премахнем всичко, което е прикривало тези проблеми (като нашите комуникационни абстракции, както е споменато по-горе), както и повторни опити на клиентския слой. Вече имаме ACK (потвърждение) съобщения (те бяха въведени преди няколко месеца) към клиента. Те ни помагат да разберем кога команда е била видяна от Старейшините. Но все още правехме заявки, докато не беше върнато парче. @bochaco се стреми да бъде по-стриктен тук… не позволява повторни опити и просто казва „видяхме „ACK“… така че защо не виждаме успех от първия път?“ Това разкри някои грешки при четене/запис на файлове. (Изглежда, че десериализацията на командите за съхранение може да отнеме по-дълго от заявките… така че дори и да бъдат изпратени след това, ние ги обработваме първо).
Намаляване на възловите натоварванията при обработка
В опит да регулираме по-правилно обработката на командите във възлите, бяхме добавили код, който трябваше да организира входящите съобщения и да ги подрежда за обработка. Всъщност видяхме, че това изобщо не е имало ефекта, който търсихме (всъщност то просто задейства всички съобщения да се обработват едно след друго, независимо от приоритета).
Премахването на този код позволи много опростяване на възела. Най-важното е, че успяхме да преместим обработката на процеса при възел извън нишката по начин без заключване (след като нашето еднонишково натискане премахна по-голямата част от заключващия код).
Въздействие
По-рано можехме да проследяваме съобщенията, които идват, поставят се на опашка за обработка, обработват се и след това се поставят на опашка за изпращане. Този процес при натоварване може да отнеме значително време. Понякога беше сравнително бързо, под секунда. Понякога, с цялата обработка на команди и IO за съобщения… можеше да отнеме 20 секунди.
Сега виждаме съобщения, които рутинно идват към възлите, обработват се незабавно и съобщенията излизат под милисекунда.
Това е много по-близко до това, което бихме очаквали от нашите съобщения преди, и го чувстваме като стъпка в правилната посока.
Следващи стъпки
Стремим се да включим напълно двупосочните потоци в клиентите, като премахнем много от управление на състоянието там. И също така ще се стремим да имаме същия поток в комуникациите за Старейшини → Възрастни, където се изискват отговори, което трябва допълнително да опрости нещата и там. Това всъщност трябва да позволи на нашите ACK съобщения да отразяват и съхранението за Възрастни, а не само Старейшините да казват, че са видели съобщение, което също трябва да помогне при неуспешни проверки.
Преводи:
English 
Russian ; 
German ; 
Spanish ; 
French
- Официален сайт на Safe Network
- Обобщено представяне на Safe Network
- Safe Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
- Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България