Что умеет SIGNAL

Система — это две независимые части: бэкенд и клиент. Они общаются только через REST API. Это не монолит — если упадёт сервер, лаунчер сохранит последний закэшированный конфиг и продолжит показывать серверы (без истории).

┌─────────────────────┐       HTTPS / REST       ┌──────────────────────────────┐
│  Avalonia Launcher  │ ◄────────────────────►   │       Node.js / Express      │
│    (.NET 10, Win)   │    (конфиг, онлайн,      │    Cluster (VPS, port 443)   │
└─────────────────────┘     история, auth)        └──────────────────────────────┘
                                                            │
                                                            │ UDP A2S (централизованный опрос)
                                                            ▼
                                          ┌──────────────────────────────────────┐
                                          │          DayZ серверы                │
                                          │         (любые IP:порт)              │
                                          └──────────────────────────────────────┘
                                                            │ read / write
                                                            ▼
                                          ┌──────────────────────────────────────┐
                                          │  users.db / history.db / reviews.db  │
                                          │            + JSON-конфиг             │
                                          └──────────────────────────────────────┘

Node.js однопоточный, но на VPS несколько ядер. Бэкенд работает в cluster-режиме: master-процесс поднимает по одному воркеру на каждое CPU-ядро, каждый воркер — полноценный Express-сервер. При падении воркера master автоматически поднимает новый — zero downtime при любом краше.

Последовательность при первом запуске и при каждом последующем:

• Проверка обновления — лаунчер сравнивает свою версию с launcher_version из конфига. Если есть новее — показывает уведомление, скачивает инсталлятор по updateUrl.
• Загрузка конфига — GET /api/config возвращает весь список серверов, premium-проекты, настройки. Кэшируется локально на случай офлайна.
• Получение онлайна — лаунчер запрашивает актуальный кэш онлайна с серверной инфраструктуры по REST. Данные уже готовы — кластер обновляет их в фоне каждые 10 минут, без нагрузки на клиента.
• Восстановление сессии — если в хранилище есть JWT-токен, лаунчер делает GET /api/me и проверяет его валидность. Если токен протух — просит залогиниться снова.

Это не случайность. У каждой базы свой паттерн нагрузки: пользовательская база читается при каждом логине, история — пишется пачками каждые 10 минут и редко читается, отзывы — случайные записи и частые чтения. Если держать всё в одной базе, WAL-журнал будет общим — пачки INSERT в историю будут блокировать чтение пользователей. Разделение устраняет это.

В системе два типа привилегированных пользователей. Ключевой момент: у них разные JWT-секреты и разные middleware для проверки. Это сделано намеренно — токен admin'а физически не пройдёт через middleware владельца и наоборот. Никакой логики "если есть role=admin, то пропустить везде" — нет.

Steam авторизация сделана через Passport.js + Steam OpenID. Важно: она используется только чтобы привязать отзыв к реальному Steam-аккаунту. Войти в личный кабинет через Steam нельзя — это другая система.

После коллбэка сессия содержит req.user.id (Steam ID64) и req.user.displayName. При следующем POST /api/reviews этот Steam ID привязывается к отзыву. Steam ID публичен сам по себе — мы не получаем ничего, что пользователь не мог бы узнать самостоятельно.

Лаунчер хранит JWT в защищённом локальном хранилище. При каждом запуске проверяет токен через GET /api/me. Если сервер вернул 401 — токен инвалидирован, показывает экран логина. Refresh-токенов нет — при истечении 30 дней просто снова логин. Это сделано намеренно: меньше сложности, меньше векторов атаки.

Весь A2S-опрос вынесен на централизованный Node.js кластер — и это не случайность. Во-первых, защита от DDoS: если бы каждый клиент сам слал UDP-пакеты, любой сервер мог бы оказаться под распределённым флудом от тысяч лаунчеров одновременно. Во-вторых, обход клиентских файрволов: многие провайдеры режут исходящий UDP-спам — пользователь просто не получил бы онлайн. Лаунчер избавлен от этих проблем: он запрашивает готовый кэш по HTTPS REST и получает данные всегда, независимо от настроек сети.

Steam Web API для этих задач не подходит — rate limit в несколько тысяч запросов в сутки при 50+ серверах с обновлением каждые минуты физически невозможен. Плюс задержка данных 1–5 минут делает его бесполезным для отображения живого онлайна.

A2S (Source Engine Query Protocol) — UDP-протокол, который поддерживает любой Source-движок, включая DayZ. Кластер отправляет запрос на query-порт сервера (игровой порт + 1, это стандарт Source Engine), получает ответ за <50ms и парсит бинарный ответ по спецификации протокола. Сервер может ответить challenge — это стандартная анти-спуф защита протокола, кластер обрабатывает её автоматически.

Если за 5 секунд ответа нет — сервер считается оффлайн. Весь цикл по всем серверам идёт параллельно через Promise.allSettled, что означает: падение одного сервера не задерживает опрос остальных.

Используется гибридная модель. Список активных модов сервера приходит с бэкенда в составе конфига — кластер извлекает его из A2S-ответа (DayZ кладёт Workshop ID модов в поле keywords/gametype, это официальное поведение игры). Локальная валидация кэша и путей идёт строго через нативный steam_api64.dll по интерфейсу SteamUGC — именно он отвечает за проверку установленных Workshop-предметов без лишних запросов к Steam Web API.

Плеер — это не веб-вью и не Electron-обёртка над YouTube. Это нативный компонент внутри Avalonia-приложения. Он использует внешний аудио API для поиска и стриминга треков, получая прямые аудио-потоки которые воспроизводит нативным декодером.

Каждый воркер держит несколько объектов в памяти — чтобы не лезть в файл или базу на каждый запрос:

let configCache           = null;  // конфиг серверов — читается с диска при первом запросе
let adminsConfig          = null;  // конфиг администраторов
let globalServerListCache = [];    // последний A2S-результат по всем серверам
let modUpdateCache        = {};    // { 'ip:port': { mods: [], ts: Date } }
let premiumModsCache      = {};    // то же для premium-серверов

globalServerListCache — это последний известный статус всех серверов (онлайн, слоты). Лаунчер получает его вместе с конфигом в одном ответе. Обновляется фоновым циклом — лаунчер никогда не ждёт свежего A2S от сервера, он всегда получает последний закэшированный результат.

• Берёт полный список серверов из configCache
• Параллельно опрашивает все серверы по UDP через Promise.allSettled
• Обновляет globalServerListCache актуальными данными
• Пишет снепшот в историю пачечным INSERT — одна транзакция на все серверы
• Если Super Premium сервер был онлайн → стал оффлайн → стреляет в Discord webhook

История не чистится автоматически — это намеренно. Старые данные (старше 90 дней) просто не показываются на графике, но хранятся. Можно добавить VACUUM по расписанию если база вырастет до неприемлемого размера.

Прямых рекуррентных списаний с карты нет. Владелец пополняет внутренний баланс (число в рублях в пользовательской БД), затем сам активирует или продлевает подписку — средства списываются с баланса. Плюсы этой модели:

• Не нужна согласованность платёжных систем на рекуррентные списания
• Возврат = просто увеличить баланс, не нужна операция возврата у провайдера
• Пользователь сам контролирует когда платит — нет неожиданных списаний
• Одна модель работает для всех способов оплаты (карта, крипта, ручное зачисление)

const PLAN_PRICES = {
  basic: 2000,  // ₽/мес
  super: 5000,  // ₽/мес
};
const EXTRA_SERVER_PRICE = 500; // ₽/мес за каждый сервер сверх первого

function calcPrice(plan, days, serverCount = 1) {
  const base    = PLAN_PRICES[plan] * days / 30;
  const extra   = Math.max(0, serverCount - 1) * EXTRA_SERVER_PRICE * days / 30;
  return Math.round(base + extra);
}

Платёжный провайдер присылает webhook при успешном платеже. Сервер:

• Проверяет HMAC-подпись запроса — без этого любой мог бы сфейкать пополнение
• Проверяет что платёж с таким ID ещё не обработан (идемпотентность)
• Добавляет сумму к балансу владельца в БД
• Логирует транзакцию с временной меткой и ID платежа

Когда пользователь скачивает и запускает .exe-файл, Windows SmartScreen проверяет его. Если файл не подписан или подписан дешёвым сертификатом — показывается красное окно "Неизвестный издатель". Кнопки "Запустить" нет — только "Больше сведений" и "Всё равно запустить". Большинство пользователей закроют и не вернутся.

Code Signing сертификат — это криптографическая подпись, встроенная в .exe. Windows проверяет её и видит: файл не изменялся с момента подписания, и мы знаем кем он подписан.

Каждый лаунчер при первом запуске генерирует UUID (device_id) и хранит его локально. Этот ID отправляется с каждым отзывом. Сервер проверяет: если device_id уже оставил отзыв на этот сервер — дубль отклоняется. Одно устройство = один голос.

Если пользователь авторизован через Steam — дополнительно проверяется Steam ID64. Смена device_id не помогает если Steam ID уже голосовал. Оба механизма работают параллельно.

На эндпоинтах логина и регистрации стоит rate limiter по IP. Это стандартная защита от брутфорса — после N попыток за окно времени IP получает 429. bcrypt с cost 12 добавляет ещё один барьер: даже при пропуске rate limit'а каждая проверка занимает ~250ms.

На публичных эндпоинтах (конфиг, отзывы) rate limiting мягче — защита от парсеров, не от пользователей.

Загрузка через multer с ограничениями: только изображения по MIME-типу, ограничение размера. Файлы сохраняются в директорию /uploads/ с рандомным именем — имя оригинального файла игнорируется, чтобы не было path traversal. Старый файл удаляется при загрузке нового.

• Не модифицирует и не читает файлы DayZ или Steam
• Не вмешивается в анти-чит (BattlEye и VAC работают независимо)
• Не хранит пароль Steam — авторизация через официальный OpenID, пароль до нас не доходит
• Не собирает данные об установленных программах или системе
• Не делает запросы в фоне когда лаунчер закрыт

S1 — это комплексный режим, который применяет несколько системных оптимизаций одновременно в момент запуска игры:

Плазма — это процедурно-анимированный фон на базе шейдера. Несколько слоёв синус-волн с разными частотами, фазами и скоростями складываются в органичное плавное движение. Цветовая схема и скорость — настраиваемые параметры.

Аудио поток → FFT (быстрое преобразование Фурье) → массив амплитуд по частотам
     ↓
Bass (20–200 Hz)   → скорость и масштаб волн плазмы
Mid (200–2000 Hz)  → интенсивность цвета и яркость
High (2000+ Hz)   → мелкие детали и частота пульсации

FFT вычисляется в отдельном потоке с частотой ~60 раз в секунду. Результат передаётся в рендерер как массив float-значений. Шейдер плазмы читает эти значения и модифицирует параметры волн в реальном времени — фон буквально "дышит" в такт музыке.

Когда музыка не играет — плазма работает в "idle" режиме с медленной спокойной анимацией. Когда пауза — плавно переходит в idle через интерполяцию, без резкого скачка.