Чудесно е, че стигнахме до етапа, в който може да проверим във форума клиентската страна, като поискаме лог файлове, когато нещо не работи и да го поправим в движение. Примерен случай, проблемът с липсващи парчета при изтегляне на големи файлове. В този случай ставаше дума за групиране на парчета при изтегляне.
Всъщност седмицата беше добра за всички поправки, много от които са свързани с нашето вътрешно тестване и интеграция, но и някои по-видими. Една, която току-що излезе, се занимава с проблем, при който клиентите са надплащали за качвания. Всеки път, когато се изискваше изплащане, клиентът (в момента) изплаща на всички възли в близката група, вместо само на тази по-висока цена. Въпреки че трябва да подобрим това (за да не плащаме повече), възлите всъщност просто изхвърляха безплатните пари, които им бяха изпратени, ако вече притежаваха данните. Сега те вземат всички токени, изпратени до тях, преди да проверят дали наистина са достатъчни (прехвърлянето на токени не може да бъде обърнато така или иначе).
При проучване на клиентски лог от @Toivo, който показва, че клиентът се зацикля при качване на парчета, Qi откри причината за загубени мрежови връзки и таблици за маршрутизиране. Може би е най-добре просто да спрем клиента в този случай и да го накараме да започне отново.
Беше страхотна седмица и за външно сътрудничество. Имахме продуктивна среща с Макс Индън от IPFS, който е един от основните libp2p Rust момчета, обяснявайки как използваме Kademlia/Libp2p, което е доста различно от начина, по който го използва IPFS. В IPFS става дума за проследяване кой съхранява данните, а не за управление на самите данни. Като такъв той е предназначен за малки трансфери на данни, докато Safe е предназначен за големи, поради което имаме собствен механизъм за репликация. Както и да е, това беше добра среща на умовете и очакваме с нетърпение да продължим сътрудничеството и да видим как можем да допринесем нагоре по веригата, като AutoNat е основна цел.
Благодарим на всички, които забелязват аномалии и изпращат лог файлове. Оценяваме го. Понякога е трудно да възпроизведем грешки от наша страна, така че те могат да бъдат изключително полезни. Джош, Ци и Роланд ги преглеждаха и ни помогнаха да коригираме редица проблеми тази седмица.
Проследихме главната причина за изтичането на основна памет при възли, които „набират обратно“, когато забележат, че някой е изгубен или очевидно е зад NAT. Този процес не умира както трябва, така че премахнахме част от кода около него и видяхме приличен спад в паметта. Проследяваме ефекта от това сега, както и наблюдаваме дали има други области, които можем да подобрим тук.
Тест мрежата HeapNet2 се оказва здрав звяр. Оценяваме коментара на @neik: „тишината е оглушителна, означава, че намираме все по-малко поводи за стенене хаха ”
Сега, когато качванията и изтеглянията на парчета изглеждат стабилни, можем да се съсредоточим върху регистрите, плащането към Фондацията и оптимизирането на репликацията.
Надяваме се, че сте забелязали, че хората от екипа бяха във форума тази седмица. Ако видите нещо нередно, просто ни пишете. Следващата тестова мрежа трябва да е около плащанията на авторски права, в момента работим върху нова настройка, за да проверим нещата там.
Общ напредък
@anselme работи върху по-бързи и по-ефективни плащания, като превръща CashNotes (тежки) в преводи (леки) възможно най-скоро в кода, за да избегне работа с големи CashNotes, които трябва да се четат от диска. Това води до по-малък отпечатък върху паметта, тъй като трансферите са много по-леки от CashNotes и имат много по-малко писане върху диска.
Той също така поправи потенциален възможен двоен разход недостатък, като направи всяко разделяне да дава грешка, с изключение на регистрите, за които, като CRDT, се обработват от клиентската страна.
@roland отвори PR за разрешаване на потребителите да конфигурират Open Metrics порт на сървъра. Той също така разглежда самовъзстановяването чрез заявки и потенциални ъглови случаи при кеширане.
@chriso създаде нова щайга, наречена sn_releases, за да разкрие хранилище за изтегляне и извличане на инсталационни файлове. Той също така направи PR на rust щайга за управление на системни услуги. Тази работа ще отвори вратата към инструмент за управление на възли (за да позволи автоматизирани актуализации).
Веднага след победата си в справянето с мистерията на липсващите парчета при изтегляне и разбиването на главоблъсканицата Client Loop, @qi_ma сега проучва подобна енигма: Синдром на възел без парчета. Той има някои интересни следи около пристрастието на PeerId, което може да обясни някои неравномерни разпределения на възли / части / награди. 
@bochaco до голяма степен е завършил плащания на мрежови награди, включително валидиране на сумите, платени на адрес на възел. Това вече е готово поне като първа стъпка за плащане на нетни авторски права, извършено от клиенти, потвърдено от възли и известия, изпратени от възли чрез GossipSub. Всички възли са по подразбиране абонирани за темата GossipSub, но само известията за плащане на авторски права се изпращат по темата.
@joshuef разглежда на колко възли трябва да бъде платено за задържане на парче. На теория може да бъде само един, което има огромното предимство на простотата, но може да бъде рисковано, ако възелът падне, преди да може да се случи репликация. @bzee провежда тестове по този сценарий. Джош и @dirvine също работят върху това как да идентифицират и изхвърлят/игнорират лоши възли.
Преводи:
English 
Russian; 
German; 
Spanish; 
French
- Официален сайт на Safe Network
- Обобщено представяне на Safe Network
- Safe Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
- Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България