Это машинный перевод. Оригинал на английском здесь: Update 19 October, 2023
Замечательно, что мы дошли до того, что, по крайней мере, на стороне клиента мы можем заходить на форум, запрашивать логи, когда что-то не работает, и исправлять это на лету. Например, проблема с отсутствием фрагментов при загрузке больших файлов. В этом случае речь шла о пакетировании кусков при загрузке.
На самом деле, это была хорошая неделя для исправлений, многие из которых были связаны с нашим внутренним тестированием и интеграцией, но есть и более заметные. Тот, который только что появился, касается проблемы, связанной с тем, что клиенты переплачивали за загрузку. Каждый раз, когда требовалось погашение, клиент (на данный момент) погашает все узлы в близкой группе, а не только тот, у которого более высокая ставка. Таким образом, хотя нам нужно улучшить это (чтобы не переплачивать), узлы на самом деле просто отбрасывали бесплатные деньги, которые им отправляли, если они уже хранили данные. Теперь они принимают все отправленные им токены, прежде чем проверять, достаточно ли их (передачу токенов все равно нельзя отменить).
Изучая журнал клиента @Toivo, в котором было показано, что клиент зацикливается при загрузке фрагментов, Ци обнаружил, что причиной являются потери сетевых подключений и таблиц маршрутизации. В этом случае лучше всего просто завершить работу клиента и запустить его заново.
Это также была отличная неделя для внешнего сотрудничества. У нас была продуктивная встреча с Максом Инденом из IPFS, одним из главных разработчиков libp2p в Rust, и мы объяснили, как мы используем Kademlia/Libp2p, что сильно отличается от того, как его использует IPFS. В IPFS речь идет об отслеживании тех, кто хранит данные, а не об управлении самими данными. Таким образом, он предназначен для передачи небольших объемов данных, тогда как Safe предназначен для передачи больших объемов данных, поэтому у нас есть собственный механизм репликации. В любом случае, это была хорошая встреча умов, и мы с нетерпением ждем продолжения сотрудничества и просмотра того, как мы можем внести свой вклад в разработку, причем AutoNat является основной целью.
Спасибо всем, кто выявлял аномалии и присылал логи. Очень признателен. Иногда сложно воспроизвести ошибки с нашей стороны, поэтому они могут быть очень полезны. Джош, Ци и Роланд просматривали их и помогли нам исправить ряд ошибок на этой неделе.
Мы отследили основную причину утечки основной памяти: узлы «перезванивают», когда замечают, что один из них потерян или, по-видимому, находится за NAT. Этот процесс не завершается должным образом, поэтому мы удалили часть кода, связанного с ним, и заметили приличное падение памяти. Сейчас мы отслеживаем эффект от этого, а также смотрим, есть ли еще области, которые мы могли бы здесь улучшить.
HeapNet2 оказался крепким зверем. Мы оценили комментарий @neik : «тишина в слухе оглушительная, значит, мы находим все меньше и меньше поводов для стонов, лол». »
Теперь, когда загрузка и скачивание фрагментов кажутся стабильными, мы можем сосредоточиться на регистрах, оплате Foundation и оптимизации репликации.
Мы надеемся, что вы заметили, что на этой неделе ребята были на форуме. Если вы заметите что-то неладное, просто свяжитесь с нами. Следующая тестовая сеть должна быть связана с выплатой роялти, мы просто работаем над новой настройкой, чтобы проверить ситуацию.
Общий прогресс
@anselme делает платежи быстрее и эффективнее, как можно скорее переключив CashNotes (тяжелый) на переводы (легкий) в коде, чтобы избежать работа с большими заметками CashNotes, которые необходимо читать с диска. Это приводит к меньшему использованию памяти, поскольку операции передачи намного легче, чем CashNotes, и гораздо меньше дисковых операций ввода-вывода.
Он также исправил потенциальную ошибку возможных двойных расходов, сделав любое разделение ошибкой, за исключением регистров, для которых, как CRDT, разделение обрабатывается. сторона клиента.
@roland открыл запрос на разрешение пользователям настраивать порт сервера Open Metrics. Он также рассматривает возможность самовосстановления с помощью запросов и потенциальных возможностей кэширования.
@chriso создал новый ящик под названием sn_releases, чтобы предоставить репозиторий для загрузки и извлечения двоичных файлов наших выпусков. Он также сделал пиар к ржавому ящику для управления системными службами. Эта работа откроет дверь к инструменту для управления узлами (чтобы обеспечить возможность автоматических обновлений).
Только что одержав победу в разгадке тайны недостающих кусков при загрузке и разгадав загадку клиентского цикла, @qi_ma теперь разгадывает похожую загадку: синдром бесблочного узла. У него есть несколько интересных предположений относительно предвзятости PeerId, которая вполне может объяснить неравномерное распределение узлов, фрагментов и вознаграждений. :мужской_детектив:
@bochaco в значительной степени завершил выплаты сетевых роялти, включая проверку сумм, выплачиваемых за адрес узла. Теперь это готово, по крайней мере, в качестве первого шага для того, чтобы чистые выплаты роялти осуществлялись клиентами, проверялись узлами и отправлялись уведомления узлами через GossipSub. Все узлы по умолчанию подписаны на тему GossipSub, но выплачиваются только гонорары.nt уведомления отправляются по теме.
@joshuef изучал, сколько узлов нужно заплатить за хранение фрагмента. Теоретически это может быть только один узел, который имеет огромное преимущество в простоте, но может быть рискованным, если узел выйдет из строя до того, как произойдет репликация. @bzee проводит тесты по этому сценарию. Джош и @dirvine также работают над тем, как идентифицировать и удалять/игнорировать плохие узлы.
Полезные ссылки
Не стесняйтесь отвечать ниже со ссылками на переводы этого обновления для разработчиков, и модераторы добавят их сюда.
Как проект с открытым исходным кодом, мы всегда ждем отзывов, комментариев и предложений сообщества - так что не стесняйтесь, присоединяйтесь и давайте вместе создадим безопасную сеть!