cryptofoundry

Связаться с cryptofoundry

Расскажите, что вы хотите создать или автоматизировать.

Электронная почта
[email protected]
ADAMANT Messenger
Открыть в ADAMANT
Dev Guidelines & Docs

Алгоритм проверки работоспособности узлов и сервисов ADAMANT

Алгоритм проверки работоспособности направлен на то, чтобы сделать ADAMANT самым надёжным криптокошельком. Он применяется ко всем узлам, включая ADM и узлы монет, а также к сервисам, таким как info-service и IPFS. Алгоритм оценивает высоту узла, минимальную поддерживаемую версию и использует наиболее информативную доступную конечную точку, например /api/node/status для ADM. Исключаются узлы, отключённые пользователем, а список узлов хранится локально, независимо от настройки «Оставаться в системе».

Статусы узлов включают: Отключён пользователем, Не поддерживается (из-за версии или HTTP-узла через PWA-HTTPS) и Недоступен. Если узел недоступен, алгоритм сначала проверяет домен, а при его недоступности — alt_ip. Как только домен становится доступным, alt_ip больше не проверяется, чтобы избежать лишних запросов. Если оба недоступны, алгоритм повторит попытку при следующем запросе.

Определение статусов Доступен и Синхронизирован основано на пороговых значениях высоты узла (HEIGHT_EPSILON). Единственный откликнувшийся узел помечается как Доступен. Группа узлов, попадающих в порог, считаются Активными, а узлы за пределами порога — Синхронизированными (или «читерами»). Пороги различаются в зависимости от монеты: для ADM — 10, BTC — 2, ETH — 5, DOGE — 3, DASH — 3, LSK — 5. Например, узлы BTC с высотой 815 000 и 815 001 будут оба активными, а узел с высотой 815 010 будет считаться Синхронизированным.

Во время первоначальной проверки работоспособности или после потери соединения первый ответ от узла может быть помечен как Активный, а не Синхронизированный. Ожидание полной 10-секундной проверки заморозило бы приложение. Чтобы решить эту проблему, статусы обновляются до Активного или Синхронизированного только после того, как ответят 30% узлов; в противном случае сохраняются предыдущие статусы. Такая проверка помечается как Первоначальная. В последующих проверках статусы обновляются только после получения ответов от 100% узлов, чтобы предотвратить ошибочное присвоение статуса Синхронизированный узлам с устаревшими данными.

Чтобы не вводить пользователей в заблуждение, во время выполняющейся Первоначальной проверки для узлов со статусами Неопределённый или Недоступный отображается визуальный статус «Обновление…». Он отображается как серая точка с приглушённым текстом.

Discussion screenshot 1

Каждый запрос проверки работоспособности измеряет задержку (Ping), и узел с наименьшей задержкой считается самым быстрым. Настройка «Предпочитать самый быстрый узел» по умолчанию отключена для ADM и включена для узлов монет, работая отдельно для узлов монет и индексаторов.

Проверки работоспособности выполняются независимо от статуса интернет-соединения, поскольку сообщение ОС «Нет подключения к интернету» ненадёжно. При отсутствии соединения результатом будет просто отсутствие доступных узлов. Состояния hasEnabledNodes и hasAvailableNodes обновляются, когда отвечают как минимум три узла или когда проверка завершена, что улучшает UX при запуске, избегая 10-секундных задержек. Перекрывающиеся проверки предотвращаются; ранее ошибка, использующая setInterval() вместо setTimeout(), вызывала всплеск запросов при восстановлении приложения из фонового режима.

Проверки работоспособности запускаются при старте приложения, восстановлении соединения, открытии экрана узлов или обновлении списков узлов. Регулярные интервалы (normalUpdateInterval) зависят от типа узла и варьируются от 3 до 8 минут. Если все активные узлы падают, выполняется дополнительная проверка работоспособности.

При отправке HTTP-запросов алгоритм игнорирует статус «Нет подключения к интернету» и не ожидает завершения полной проверки работоспособности. Он выбирает самый быстрый или случайный активный узел. Если запрос завершается таймаутом, он пробует следующий узел и помечает неудавшийся как Недоступный. HTTP-ошибки, такие как 404, не считаются сбоем. Все ожидающие запросы всегда завершаются после восстановления соединения, обеспечивая, что операции, такие как сохранение списка контактов, не прерываются.