Это машинный перевод. Оригинал на английском здесь: Update 20 October, 2022
На этой неделе @joshuef сообщает новости о прогрессе в области связи (связь между узлами). Как известно терпеливым читателям, это уже какое-то время блокирует, но мы видим определенный свет в конце этого конкретного туннеля.
Общее обновление
Краткий обзор того, чем занимается команда.
@anselme расследует атаку с мошенническим ключом, которая влияет на некоторые другие реализации BLS. и обнаружил, что наш тоже уязвим. Он представил исправление для ящика blsttc. Он также изучает ошибку, которая не позволяет клиентам подключаться к сети во время тестов.
@chriso работает над подписанием чанков и регистров, когда данные (или их имя Xorname в случае чанка) подписываются старейшинами, чтобы сделать их действительными в сети.
В связи с этим @bochaco вносит изменения в клиентский API, связанные с командами и чанками, и устраняет связанные с ними ошибки в CI.
Мостафа занят тестами для нашего механизма консенсуса, а @bzee продолжает ковыряться в qp2p, где, как мы полагаем, есть глубоко укоренившийся недостаток, влияющий на возможность подключения.
Ход связи
Итак, одна вещь, над которой мы работаем, — это удаление нашего кода сокращения соединений и просто использование базового кода quinn для разрыва соединений после меньшего тайм-аута. Таким образом, мы предполагаем меньше и больше не гадаем, что открыто и когда.
В нашем тестировании это оказало положительное влияние на клиентские тесты, устранив вероятность того, что наши соединения будут закрыты на полпути.
Би-потоки
Параллельно мы также движемся к оптимизации связи между клиентом и узлом с помощью двунаправленных потоков. Это означает, что мы убираем некоторую сложность управления состоянием и будем просто ждать ответа от старших. Раньше (давным-давно в мире узлов) мы использовали такие потоки для связи с клиентами, но управление потоком ответов было сложным кошмаром. Но теперь нода намного проще (из-за работы, проделанной за последние полтора года или около того), и с ней намного легче справиться.
Сокращение повторных попыток
Мы также пытались удалить все, что скрывало эти проблемы (например, наши абстракции связи, как упоминалось выше), а также повторные попытки клиентского уровня. Теперь у нас есть сообщения ACK (подтверждение) (они были введены несколько месяцев назад) для клиента. Они помогают нам сказать нам, когда команда была замечена старейшинами. Но мы все еще просто запрашивали, пока кусок не был возвращен. @bochaco хотел быть здесь более строгим… не разрешая повторные попытки и просто говоря: «Мы видели ACK… так почему же мы не видим успеха в первый раз?». Это выявило некоторые ошибки при чтении/записи файлов. (Похоже, что десериализация команд хранилища может занять дольше, чем запросы… поэтому, даже если они отправляются после, мы обрабатываем их сначала).
Снижение нагрузки на узлы при обработке
Чтобы более правильно регулировать обработку команд узла, мы ранее добавили код, который должен организовывать входящие сообщения и упорядочивать их для обработки. На самом деле мы видели, что это не имело ожидаемого эффекта вообще (на самом деле это просто инициировало обработку всех сообщений одно за другим независимо от приоритета).
Удаление этого кода позволило значительно упростить узлы. Что наиболее важно, мы смогли переместить обработку узловых процессов вне потока без блокировки (после того, как наша однопоточная отправка удалила подавляющее большинство кода блокировки).
Влияние
Раньше мы могли отслеживать входящие сообщения, ставиться в очередь на обработку, обрабатываться, а затем ставиться в очередь на отправку. Этот процесс под нагрузкой может занять значительное время. Иногда это было относительно быстро, меньше секунды. Иногда, со всей обработкой команд и вводом-выводом сообщений… это могло занять 20 секунд.
Теперь мы видим, что сообщения регулярно поступают на узлы, обрабатываются немедленно, а сообщения отправляются менее чем за миллисекунду.
Это намного ближе к тому, что мы ожидали от наших сообщений ранее, и очень похоже на правильное направление.
Следующие шаги
Мы стремимся полностью интегрировать двунаправленные потоки в клиентов, избавившись от значительной части управления состоянием. И мы также будем стремиться к такому же потоку общения между пожилыми и взрослыми, где требуются ответы, что также должно еще больше упростить ситуацию. На самом деле это должно позволить нашим сообщениям «ACK» также отражать хранилище для взрослых, а не просто старейшины, говорящие, что они видели сообщение, что также должно помочь при неудачных проверках.
Полезные ссылки
Не стесняйтесь отвечать ниже со ссылками на переводы этого обновления для разработчиков, и модераторы добавят их сюда.
Как проект с открытым исходным кодом, мы всегда ждем отзывов, комментариев и предложений сообщества - так что не стесняйтесь, присоединяйтесь и давайте вместе создадим безопасную сеть!