Это машинный перевод. Оригинал на английском здесь: Safe Network Dev Update - January 14, 2021
Резюме
Вот некоторые из основных моментов, которые следует выделить после последнего обновления для разработчиков:
- Мы продолжаем перемещать все определения клиентских сообщений и логику сериализации в новый ящик sn_messaging.
- Работа по удалению управления потоком в узлах, как упоминалось в обновлении на прошлой неделе, завершена и объединена
- Мы прорабатываем и исправляем проблемы, выявленные нашим новым инструментом стресс-тестирования маршрутизации.
-
Огромный привет и благодарность нескольким членам сообщества за PR на этой неделе - @mav и @tfa участвовали в нескольких PR в разных репозиториях, чтобы помочь и улучшить нашу работу. Всегда приятно видеть
- Мы все еще работаем над тестированием окончательного решения ошибки, которое, как мы надеемся, будет означать, что мы сможем выпустить следующую итерацию тестовой сети.
Безопасный клиент, узлы и qp2p
План проекта безопасных сетевых передач
План проекта безопасного клиента
План проекта безопасного сетевого узла
За последнюю неделю мы потратили немного времени на улучшение примеров qp2p, чтобы они лучше демонстрировали функции библиотеки по отдельности. Наряду с этим мы расширили пример эхо-службы для поддержки перенаправления портов вручную. В процессе реализации мы определили и внедрили небольшое расширение, которое проверяет конечную точку, предоставленную пользователем в качестве входных данных. Это позволяет нам вернуть ошибку намного раньше, вместо того, чтобы ждать, пока сеть идентифицирует и сообщит об узле как недоступном.
Мы также продолжили перенос всех определений клиентских сообщений и логики сериализации в новый ящик sn_messaging. Мы улучшили протокол и теперь используем Msgpack для сериализации всех сообщений, отправляемых клиентами узлам. Это постоянная задача, так как некоторые внутренние части клиентских сообщений все еще используют сериализацию двоичного кода, и поэтому нам необходимо перенести их, чтобы также использовать Msgpack.
Продолжалась работа с распределенными переходами акторов при смене старших, то есть передаче средств секции новым старшим созвездиям. Небольшая ошибка, препятствующая переходу (из-за неудачной проверки сигнатуры), потребовала некоторого времени для устранения, но была обнаружена только сейчас. Следующие шаги перехода сейчас должны быть протестированы.
Наконец, мы продолжаем обновлять клиент / узел для устранения проблем с клиентом и для повторного включения * правильного * подключения клиентов после работы по удалению управления потоком в узлах, как упоминалось в обновлении на прошлой неделе, был завершен и объединен. Это, в свою очередь, выявило некоторые потенциальные проблемы с получением или анализом клиентских сообщений, поэтому мы копаемся в этом.
API и CLI
На этой неделе мы смогли успешно сгенерировать сборки musl для CLI и authd в нашем CI, и поэтому все это настроено и готово к нашему следующему выпуску. Это означает, что и CLI, и приложения authd должны быть совместимы с любой платформой Linux прямо из коробки из пакета выпуска, нам понадобится сообщество, которое поможет нам проверить, что это действительно так, хотя, попробовав его на стольких разных платформах Linux. насколько возможно. Мы выпустим новые версии со временем.
BRB - Византийское надежное вещание
На этой неделе продолжалась работа по дальнейшей полировке ящиков BRB. API DataType был изменен, чтобы вызывающей стороне можно было возвращать сведения об ошибке проверки. Далее в этом направлении ящик rust-crdt был улучшен, так что теперь каждый тип CRDT, который мы используем, имеет метод validate (), который может быть вызван перед применением операции. Запросы на извлечение для CI / CD (непрерывная интеграция и непрерывное развертывание и доставка) были сделаны для каждого ящика BRB. У нас есть еще несколько изменений, которые нужно завершить на этой неделе, после чего мы планируем выпустить первый релиз на crates.io.
Маршрутизация
На прошлой неделе мы упоминали, как инструмент стресс-тестирования выявил некоторые скрытые проблемы в маршрутизации. На этой неделе мы решили их найти и исправить. Одна из проблем заключалась в том, что не старшие члены раздела не знали, что произошло разделение из-за ошибки в том, как были созданы сообщения «Sync». Это было исправлено и объединено. В настоящее время идет еще один PR, который устраняет еще пару из этих проблем. Остальные проблемы после этого, вероятно, связаны с тем, как мы обрабатываем изменения членства в разделе. Мы надеемся решить эту проблему путем интеграции нового алгоритма членства в BRB, о котором также упоминалось на прошлой неделе. Эта работа начнется очень скоро, возможноуже на следующей неделе, если все будет хорошо.
Подобно нашему недавнему переходу к тому, чтобы все определения клиентских сообщений и логика сериализации были помещены в отдельный ящик (sn_messaging), мы начали делать то же самое с сообщениями sn_routing. Цель состоит в том, чтобы иметь возможность отделить всю логику определения сообщений и сериализации от основной логики маршрутизации. Это должно позволить нам иметь четкое определение интерфейса, предоставляемого службами маршрутизации, и, следовательно, как любую реализацию (на любом языке программирования) можно сделать совместимой с нашей существующей реализацией sn_routing. Мы находимся на очень ранних стадиях этого процесса, но хотели бы поделиться здесь нашей целью.
Полезные ссылки
Не стесняйтесь отвечать ниже со ссылками на переводы этого обновления для разработчиков, и модераторы добавят их сюда.
Как проект с открытым исходным кодом, мы всегда ждем отзывов, комментариев и предложений сообщества - так что не стесняйтесь, присоединяйтесь и давайте вместе создадим безопасную сеть!